6 ms·

"these days it's somewhat controversial and sometimes considered undesirable" By whom and for what reason? Every non-trivial OS has some form of "daemon" conc

"these days it's somewhat controversial and sometimes considered undesirable" By whom and for what reason? Every non-trivial OS has some form of "daemon" concept, regardless of what name it's given. What alternative is proposed? All I get from this statement is discussion about the deficiencies of how demonization is performed. [edit] I get it. Don't deamonize yourself. That's fine, and a good idea: it's frequently done wrong and even when it's done right things change and otherwise correct software is suddenly wrong again.

aeldidi 2y ago
They just mean service managers like SystemD and OpenRC prefer to handle daemonizing themselves, and thus would prefer that your program stay in the foreground and let them put it in the background. From OpenRC’s docs[0]: Daemons must not fork. Any daemon that you would like to have monitored by supervise-daemon must not fork. Instead, it must stay in the foreground. If the daemon forks, the supervisor will be unable to monitor it. If the daemon can be configured to not fork, this should be done in the daemon's configuration file, or by adding a command line option that instructs it not to fork to the command_args_foreground variable shown below. The “undesired” or “controversial” part is whether programs should do it themselves or not. [0]: https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md https://github.com/OpenRC/openrc/blob/master/supervise-daemo...
- mrweasel 2y ago
  deamontools was the first supervisor service I used that required that programs not background themselves, it even included a tool for preventing "legacy" daemons from doing so. It made a lot of sense to me at the time and honestly felt easier. Going back to init.d or upstart just felt like a step backward and so much more complicated that it needed to be. Then SystemdD comes along an have the same expectation and things makes sense again and writing "startup scripts became as easy almost as it was with daemontools.
  - wahern 2y ago
    inetd, the "super server" from 4.3BSD, supported this in addition to handling the listening socket. For reasons I don't fully understand, inetd fell out of favor despite having been installed and running by default on pretty much every *BSD and Linux server for decades.
    - hibbelig 2y ago
      I recall that inetd started a new instance of the demon for every incoming connection, and this caused lots of processes when lots of connections happened. I don’t recall whether you could tell inetd not to do that.
      - wahern 2y ago
        inetd could pass the listening socket to the process. That was the `wait|nowait` field in /etc/inetd.conf. The typical config for TCP used with services like finger was `nowait`, which meant inetd would listen on a socket and spawn a new process for every incoming connection, without waiting for a previously spawned process to exit. But in `wait` mode it would spawn the process when it detected a connection, pass the listening socket (not connected socket) as fd 0, then wait for the server to exit before polling the listening socket again. inetd was (remains?) a perfectly useful solution in this space. It just maybe needs some love to add some convenience features. Off the top of my head: 1) ability to split /etc/inetd.conf into, e.g., /etc/inetd.conf.d; 2) ability to trigger a restart of a specific service, rather than restarting the entirety of inetd.
    - whartung 2y ago
      Couple things come to mind. One, is that HTTP took over the role of a lot of simple servers, thus something like Apache and CGI-BIN was used in place of inetd. Second, with the rise of interpreted languages (i.e. Perl et al), forking became more expensive. With binary programs, forking tends to be cheap (in a multi-use case) since the executable page are shared across processes. While the interpreter runtime itself is shared (being compiled), the actual script is not (having to be loaded for each instance). The HTTP servers managed that better (through modules, FastCGI, etc.), so that space didn't really advance under the guise of inetd. Make no mistake, an inetd service is "fast enough" for a wide array of use cases today, both compiled and interpreted, simply because the hardware is much better today. But, still, when folks think "ad hoc" service today, they're likely turning to HTTP today anyway.
masklinn 2y ago
> By whom and for what reason? By everyone and for the reason that service managers lose track of the process, so it increases program complexity for a net negative in usability. > Every non-trivial OS has some form of "daemon" concept, regardless of what name it's given. And none of that is relevant, TFA is about the unix self-daemonization pattern, that is what's undesirable.
- JackSlateur 2y ago
  If your service manager cannot track forked process, that would be quite an issue anyway "Daemonization" is nothing but fork + exec (and exit from the parent) From the service manager, there should be few distinctions between this and, say, pgsql forking to handle connections. In both cases, I expect all child processes to be tracked. And please do not tell me the "health check" part : having the main process alive is a broken health check, just like having a server powered-on is a far from enough
  - kbolino 2y ago
    There is one very important distinction. If pgsql forks to handle connections, the PPID of the child processes points back to the "main" pgsql process, which is still around. Whereas, traditionally, if a wannabe daemon forks and exits, the PPID of its now orphaned child reverts to 1.
    - zokier 2y ago
      afaik you need cgroups if you want to accurately track a process tree regardless of what silly tricks the processes might be try to escape
      - thwarted 2y ago
        Or prctl and PR_SET_CHILD_SUBREAPER are potentially useful for that.
        2y ago
lotharcable 2y ago
Deamonizing means double forking processes to break away from the terminal executing it. This sort of behavior makes writing proper systemd unit files and containers a pain. It is a lot nicer to keep them 'attached' so that you can do things like capture stdout for logging and all that fun stuff. That is what they are talking about when "daemonizing is considered undesirable".

aeldidi 2y ago

They just mean service managers like SystemD and OpenRC prefer to handle daemonizing themselves, and thus would prefer that your program stay in the foreground and let them put it in the background. From OpenRC’s docs[0]: Daemons must not fork. Any daemon that you would like to have monitored by supervise-daemon must not fork. Instead, it must stay in the foreground. If the daemon forks, the supervisor will be unable to monitor it. If the daemon can be configured to not fork, this should be done in the daemon's configuration file, or by adding a command line option that instructs it not to fork to the command_args_foreground variable shown below. The “undesired” or “controversial” part is whether programs should do it themselves or not. [0]: https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md https://github.com/OpenRC/openrc/blob/master/supervise-daemo...

mrweasel 2y ago
deamontools was the first supervisor service I used that required that programs not background themselves, it even included a tool for preventing "legacy" daemons from doing so. It made a lot of sense to me at the time and honestly felt easier. Going back to init.d or upstart just felt like a step backward and so much more complicated that it needed to be. Then SystemdD comes along an have the same expectation and things makes sense again and writing "startup scripts became as easy almost as it was with daemontools.
- wahern 2y ago
  inetd, the "super server" from 4.3BSD, supported this in addition to handling the listening socket. For reasons I don't fully understand, inetd fell out of favor despite having been installed and running by default on pretty much every *BSD and Linux server for decades.
  - hibbelig 2y ago
    I recall that inetd started a new instance of the demon for every incoming connection, and this caused lots of processes when lots of connections happened. I don’t recall whether you could tell inetd not to do that.
    - wahern 2y ago
      inetd could pass the listening socket to the process. That was the `wait|nowait` field in /etc/inetd.conf. The typical config for TCP used with services like finger was `nowait`, which meant inetd would listen on a socket and spawn a new process for every incoming connection, without waiting for a previously spawned process to exit. But in `wait` mode it would spawn the process when it detected a connection, pass the listening socket (not connected socket) as fd 0, then wait for the server to exit before polling the listening socket again. inetd was (remains?) a perfectly useful solution in this space. It just maybe needs some love to add some convenience features. Off the top of my head: 1) ability to split /etc/inetd.conf into, e.g., /etc/inetd.conf.d; 2) ability to trigger a restart of a specific service, rather than restarting the entirety of inetd.
  - whartung 2y ago
    Couple things come to mind. One, is that HTTP took over the role of a lot of simple servers, thus something like Apache and CGI-BIN was used in place of inetd. Second, with the rise of interpreted languages (i.e. Perl et al), forking became more expensive. With binary programs, forking tends to be cheap (in a multi-use case) since the executable page are shared across processes. While the interpreter runtime itself is shared (being compiled), the actual script is not (having to be loaded for each instance). The HTTP servers managed that better (through modules, FastCGI, etc.), so that space didn't really advance under the guise of inetd. Make no mistake, an inetd service is "fast enough" for a wide array of use cases today, both compiled and interpreted, simply because the hardware is much better today. But, still, when folks think "ad hoc" service today, they're likely turning to HTTP today anyway.

masklinn 2y ago

> By whom and for what reason? By everyone and for the reason that service managers lose track of the process, so it increases program complexity for a net negative in usability. > Every non-trivial OS has some form of "daemon" concept, regardless of what name it's given. And none of that is relevant, TFA is about the unix self-daemonization pattern, that is what's undesirable.

JackSlateur 2y ago
If your service manager cannot track forked process, that would be quite an issue anyway "Daemonization" is nothing but fork + exec (and exit from the parent) From the service manager, there should be few distinctions between this and, say, pgsql forking to handle connections. In both cases, I expect all child processes to be tracked. And please do not tell me the "health check" part : having the main process alive is a broken health check, just like having a server powered-on is a far from enough
- kbolino 2y ago
  There is one very important distinction. If pgsql forks to handle connections, the PPID of the child processes points back to the "main" pgsql process, which is still around. Whereas, traditionally, if a wannabe daemon forks and exits, the PPID of its now orphaned child reverts to 1.
  - zokier 2y ago
    afaik you need cgroups if you want to accurately track a process tree regardless of what silly tricks the processes might be try to escape
    - thwarted 2y ago
      Or prctl and PR_SET_CHILD_SUBREAPER are potentially useful for that.
      - 2y ago

lotharcable 2y ago

Deamonizing means double forking processes to break away from the terminal executing it. This sort of behavior makes writing proper systemd unit files and containers a pain. It is a lot nicer to keep them 'attached' so that you can do things like capture stdout for logging and all that fun stuff. That is what they are talking about when "daemonizing is considered undesirable".