4 ms·

Daemonization in Unix programs is probably about restarting programs

86 points by ingve 2y ago

sophacles 2y ago
Is there an archive link for this by any chance? I got a 403 error trying to load it with this message: "You appear to be trying to break this web server. Goodbye."
- cpach 2y ago
  Yep! You can find copies of the article both on Wayback Machine and on archive.ph https://archive.ph/ https://archive.ph/
  - deleted 2y ago
    [deleted]
cpach 2y ago
I love that Siebenmann is taking the time to document the nitty-gritty details of the evolution of Unix. Systems like 4.2BSD are long gone from the market, but we still see their influence all over the place.
amelius 2y ago
Daemons suck if you're not in the microservices camp.
- _hyn3 2y ago
  Can you explain further? daemons are OS-level and predate microservices by like a half-century, so how are they relevant to microservices?
  - Alupis 2y ago
    It's just yet another example of someone spouting off about microservices with near-zero understanding of microservices.
- MathMonkeyMan 2y ago
  If you're administering a server, what else is there? There are service managers like systemd and shepherd, which use daemonization under the hood. Then there's container orchestration like docker compose, kubernetes, etc. For my toy servers at home I just use screen and have it set up automatically at boot. What do you use outside of the microservices camp?
  - tommiegannert 2y ago
    We've had init and inittab for decades. Daemonization was never a necessity. Service managers don't daemonize anything, because they never have to release control to their parent. Just like init always did. The only thing that's changed with systemd is that inittab now has a dependency management, and richer syntax.
topspin 2y ago
"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.
gargalatas 2y ago
daemonization is the process of running a process in the background and without being attached to a terminal. Many applications exit when they are detached from the terminal they starter even when they yield no output. Maybe that is why it's still there. Of course back in the day fork() was all about creating background processes that were running quietly in the background were screen didn't exist yet and terminals were actual machines, not just one more window. Today System D doesn't like daemonization. IT prefers a process that can be attached somewhere.
- jeffbee 2y ago
  > without being attached to a terminal Isn't that more the job of `nohup`?
  - thwarted 2y ago
    No, nohup, as the name says, is about filtering/ignoring signals, specifically HUP, that are sent when the parent process shell exits.
  - kazinator 2y ago
    No. While nohup redirects standard input and output and block the SIGHUP signal, it does not actually detach the process from the TTY session.
- internet101010 2y ago
  And this is why God invented tmux.
renewiltord 2y ago
I prefer non-daemon things that I can use systemd to manage with Unit files Type=Simple. Very easy, sends things to journal for logging. All very nice and clean. Self-daemonization is anti-pattern for new software. Non-UNIX DOTW.
Joel_Mckay 2y ago
"these days it's somewhat controversial and sometimes considered undesirable" I respectfully disagree. It it fundamentally related to your use-cases, execution times, and design paradigms. If your team comes from a *nix background, than having dozens of processes interfacing over various pipes/network-sockets/fifo/mem-share is normal. In a cluster environment, having the ability to spin up processes on any host, yet remain functional over middle-ware can be very robust from a maintenance perspective. A periodic self-restart trigger feature is only a small part of these feature sets. Containerization on the other hand was necessitated out of poor OS design consistency, and rotten permission handling. It added overhead, complexity, and costs. However, it also solved a very real user requirement of keeping many things operational at the same time. Daemons are almost certainly still required if you have software that must remain running for >6 months outside a users session. Also, periodic processes do not necessarily have to remain resident in all use cases if that was a concern. Best of luck, =3
- zokier 2y ago
  practically every system is running service manager of some sort (supervisord, daemontools, runit, or infamously systemd etc), and with a service manager daemonization is something between completely useless and actively harmful. as cks explains in the post, daemonization is truly relevant only if you are starting your daemons directly somehow somewhere, and that went out of fashion somewhere in the turn of the century.
  - kazinator 2y ago
    Programs that deamonize should have a way (e.g. command line option) to opt-out of it, or opt-in. Unconditional daemonizing interferes with debugging, for instance. That's bad. But don't forget that the service managers themselves have to daemonize. :) The programs which they launch don't have to daemonize only because their parent did that already.
  - Joel_Mckay 2y ago
    Interesting, I think we treat system services differently than utilities. A given host assigned capabilities should not require manual intervention, but should allow manual interaction for testing and debugging. Insisting one method is superior, is often from people that have never hit the terminal spawn limit on a host. Best of luck, =3
kazinator 2y ago
> the newly started program could inherit all sorts of things from your login session. It might have some random current directory, it might have stray file descriptors that were inherited from your shell or login environment, its standard input, output, and error would be connected to your terminal, and it would have a controlling terminal, leaving it exposed to various bad things happening to it when, for example, you logged out (which often would deliver a SIGHUP to it). These things still matter when the program is run from a boot script or init daemon, rather than a login session!
dekhn 2y ago
I would be totally fine if Unix programs never detached themselves from their invoking terminal/process and that restart was handled by an external system. Honestly, that seems much more consistent with the unix philosophy than having a billion different services all with their own daemonization code. This belief is mainly because after many years of debugging services, the very first thing I do is run the service outside of the daemon manager, with debugging enabled, so I can strace the process from its beginning.
- lgas 2y ago
  `inetd` was an early attempt at avoiding every process having to write their own daemonization code.
  - PaulDavisThe1st 2y ago
    not really. inetd was an early attempt at avoiding every process dealing with the basics of waiting on a socket for a connection, forking off some process to deal with it and managing the socket and the connection. inetd waited on "all" the sockets; when a connection came in, it started the configured application to deal with it. daemonization didn't really figure into it, AFAIR.
    - erik_seaberg 2y ago
      I thought inetd let you conserve memory because rarely-used daemons don't need to run continually.
- matheusmoreira 2y ago
  This is the process advocated in this wiki: https://mywiki.wooledge.org/ProcessManagement https://mywiki.wooledge.org/ProcessManagement Seems reasonable to me. Restarting processes is just something like this: #!/bin/sh # service.sh while :; do /my/service >> /var/log/service 2>&1 done service.sh & The service is just a normal program. If run directly, the inputs and outputs are attached to the terminal. If not, they're redirected to log files. Programs shouldn't care much what their outputs are connected to. Maybe they should turn off terminal escape codes in the outputs if they're not terminals but that's about it.
a-dub 2y ago
i always thought it was "do the collection of things to mitigate the problems that have been learned over the years that cause problems with long running processes" changing the cwd so it doesn't cause problems with mounting/unmounting comes to mind.
r3trohack3r 2y ago
> various bad things happening to it when, for example, you logged out (which often would deliver a SIGHUP to it) And thus, `nohup`. Quite a few of my self hosted things are spawned using `nohup ./foobar &` and happily run for months at a time. -- Edit: TIL `daemonize`, I have a new go to! https://software.clapper.org/daemonize/ https://software.clapper.org/daemonize/
- klysm 2y ago
  I just bang out a quick systemd service and let it do all the lifting
  - guestbest 2y ago
    Would you give a short explanation of how you would try that?
    - pjmlp 2y ago
      You configure it as a service, https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html https://www.freedesktop.org/software/systemd/man/latest/syst... A random tutorial, https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6 https://medium.com/@benmorel/creating-a-linux-service-with-s...
      - guestbest 2y ago
        Thanks. I’ll look it over
  - fasa99 2y ago
    I'll do a system d but a problem is (1) system environment, and (2) machine specs. To normalize machine specs I will run it in a VM on the cloud. To normalize system environment I run in docker. I also like to run on Java for code safety and consistency. So what I have is a VM (Java) running on a VM (Docker) running a VM, running a VM (cloud compute), running on system D. I don't think it's abstracted enough though so I'm looking to find ways to add more VMs to the equation, so as to ensure consistency. Figure if I add a few more VMs, good luck hacking that!
sweeter 2y ago
systemd has kind of "killed" daemons and the need to write custom daemon code other than IPC stuff. Which is both good and bad. I really like that a lot of user space tools just create a secondary binary and an easy interface to communicate to that process using the main binary, you can either run it by itself, use it as a systemd/sysvinit service, or one-off it. for example I use my WM to start `swww-daemon` and then running `swww <path/to/wallpaper>` just sends a message over a Unix socket to the daemon process which handles everything else. Its sooo much better than internally forking off and all of that, it becomes messy quick and its pretty unnecessary in the present. All that really matters is how robust your IPC and stop-start process is. Sometimes its massively fragile, and it shows. side note, when I first started Unix I was fascinated with daemons. I still think they are one of the coolest things ever.
thayne 2y ago
There is another reason for a service to daemonize itself: you can have the parent process wait for the child to be fully ready before exiting. Modern init systems often have a better way to communicate readiness (for example systemd-notify, or writing a pidfile when ready) but older systems often didn't have a way for a process to directory tell the init process it was ready.

86 points by ingve 2y ago

Is there an archive link for this by any chance? I got a 403 error trying to load it with this message: "You appear to be trying to break this web server. Goodbye."

cpach 2y ago
Yep! You can find copies of the article both on Wayback Machine and on archive.ph https://archive.ph/ https://archive.ph/
- deleted 2y ago
  [deleted]

cpach 2y ago

I love that Siebenmann is taking the time to document the nitty-gritty details of the evolution of Unix. Systems like 4.2BSD are long gone from the market, but we still see their influence all over the place.

amelius 2y ago

Daemons suck if you're not in the microservices camp.

_hyn3 2y ago
Can you explain further? daemons are OS-level and predate microservices by like a half-century, so how are they relevant to microservices?
- Alupis 2y ago
  It's just yet another example of someone spouting off about microservices with near-zero understanding of microservices.
MathMonkeyMan 2y ago
If you're administering a server, what else is there? There are service managers like systemd and shepherd, which use daemonization under the hood. Then there's container orchestration like docker compose, kubernetes, etc. For my toy servers at home I just use screen and have it set up automatically at boot. What do you use outside of the microservices camp?
- tommiegannert 2y ago
  We've had init and inittab for decades. Daemonization was never a necessity. Service managers don't daemonize anything, because they never have to release control to their parent. Just like init always did. The only thing that's changed with systemd is that inittab now has a dependency management, and richer syntax.

topspin 2y ago

"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.

gargalatas 2y ago

daemonization is the process of running a process in the background and without being attached to a terminal. Many applications exit when they are detached from the terminal they starter even when they yield no output. Maybe that is why it's still there. Of course back in the day fork() was all about creating background processes that were running quietly in the background were screen didn't exist yet and terminals were actual machines, not just one more window. Today System D doesn't like daemonization. IT prefers a process that can be attached somewhere.

jeffbee 2y ago
> without being attached to a terminal Isn't that more the job of `nohup`?
- thwarted 2y ago
  No, nohup, as the name says, is about filtering/ignoring signals, specifically HUP, that are sent when the parent process shell exits.
- kazinator 2y ago
  No. While nohup redirects standard input and output and block the SIGHUP signal, it does not actually detach the process from the TTY session.
internet101010 2y ago
And this is why God invented tmux.

renewiltord 2y ago

I prefer non-daemon things that I can use systemd to manage with Unit files Type=Simple. Very easy, sends things to journal for logging. All very nice and clean. Self-daemonization is anti-pattern for new software. Non-UNIX DOTW.

Joel_Mckay 2y ago

"these days it's somewhat controversial and sometimes considered undesirable" I respectfully disagree. It it fundamentally related to your use-cases, execution times, and design paradigms. If your team comes from a *nix background, than having dozens of processes interfacing over various pipes/network-sockets/fifo/mem-share is normal. In a cluster environment, having the ability to spin up processes on any host, yet remain functional over middle-ware can be very robust from a maintenance perspective. A periodic self-restart trigger feature is only a small part of these feature sets. Containerization on the other hand was necessitated out of poor OS design consistency, and rotten permission handling. It added overhead, complexity, and costs. However, it also solved a very real user requirement of keeping many things operational at the same time. Daemons are almost certainly still required if you have software that must remain running for >6 months outside a users session. Also, periodic processes do not necessarily have to remain resident in all use cases if that was a concern. Best of luck, =3

zokier 2y ago
practically every system is running service manager of some sort (supervisord, daemontools, runit, or infamously systemd etc), and with a service manager daemonization is something between completely useless and actively harmful. as cks explains in the post, daemonization is truly relevant only if you are starting your daemons directly somehow somewhere, and that went out of fashion somewhere in the turn of the century.
- kazinator 2y ago
  Programs that deamonize should have a way (e.g. command line option) to opt-out of it, or opt-in. Unconditional daemonizing interferes with debugging, for instance. That's bad. But don't forget that the service managers themselves have to daemonize. :) The programs which they launch don't have to daemonize only because their parent did that already.
- Joel_Mckay 2y ago
  Interesting, I think we treat system services differently than utilities. A given host assigned capabilities should not require manual intervention, but should allow manual interaction for testing and debugging. Insisting one method is superior, is often from people that have never hit the terminal spawn limit on a host. Best of luck, =3

kazinator 2y ago

> the newly started program could inherit all sorts of things from your login session. It might have some random current directory, it might have stray file descriptors that were inherited from your shell or login environment, its standard input, output, and error would be connected to your terminal, and it would have a controlling terminal, leaving it exposed to various bad things happening to it when, for example, you logged out (which often would deliver a SIGHUP to it). These things still matter when the program is run from a boot script or init daemon, rather than a login session!

dekhn 2y ago

I would be totally fine if Unix programs never detached themselves from their invoking terminal/process and that restart was handled by an external system. Honestly, that seems much more consistent with the unix philosophy than having a billion different services all with their own daemonization code. This belief is mainly because after many years of debugging services, the very first thing I do is run the service outside of the daemon manager, with debugging enabled, so I can strace the process from its beginning.

lgas 2y ago
`inetd` was an early attempt at avoiding every process having to write their own daemonization code.
- PaulDavisThe1st 2y ago
  not really. inetd was an early attempt at avoiding every process dealing with the basics of waiting on a socket for a connection, forking off some process to deal with it and managing the socket and the connection. inetd waited on "all" the sockets; when a connection came in, it started the configured application to deal with it. daemonization didn't really figure into it, AFAIR.
  - erik_seaberg 2y ago
    I thought inetd let you conserve memory because rarely-used daemons don't need to run continually.
matheusmoreira 2y ago
This is the process advocated in this wiki: https://mywiki.wooledge.org/ProcessManagement https://mywiki.wooledge.org/ProcessManagement Seems reasonable to me. Restarting processes is just something like this: #!/bin/sh # service.sh while :; do /my/service >> /var/log/service 2>&1 done service.sh & The service is just a normal program. If run directly, the inputs and outputs are attached to the terminal. If not, they're redirected to log files. Programs shouldn't care much what their outputs are connected to. Maybe they should turn off terminal escape codes in the outputs if they're not terminals but that's about it.

a-dub 2y ago

i always thought it was "do the collection of things to mitigate the problems that have been learned over the years that cause problems with long running processes" changing the cwd so it doesn't cause problems with mounting/unmounting comes to mind.

r3trohack3r 2y ago

> various bad things happening to it when, for example, you logged out (which often would deliver a SIGHUP to it) And thus, `nohup`. Quite a few of my self hosted things are spawned using `nohup ./foobar &` and happily run for months at a time. -- Edit: TIL `daemonize`, I have a new go to! https://software.clapper.org/daemonize/ https://software.clapper.org/daemonize/

klysm 2y ago
I just bang out a quick systemd service and let it do all the lifting
- guestbest 2y ago
  Would you give a short explanation of how you would try that?
  - pjmlp 2y ago
    You configure it as a service, https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html https://www.freedesktop.org/software/systemd/man/latest/syst... A random tutorial, https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6 https://medium.com/@benmorel/creating-a-linux-service-with-s...
    - guestbest 2y ago
      Thanks. I’ll look it over
- fasa99 2y ago
  I'll do a system d but a problem is (1) system environment, and (2) machine specs. To normalize machine specs I will run it in a VM on the cloud. To normalize system environment I run in docker. I also like to run on Java for code safety and consistency. So what I have is a VM (Java) running on a VM (Docker) running a VM, running a VM (cloud compute), running on system D. I don't think it's abstracted enough though so I'm looking to find ways to add more VMs to the equation, so as to ensure consistency. Figure if I add a few more VMs, good luck hacking that!

sweeter 2y ago

systemd has kind of "killed" daemons and the need to write custom daemon code other than IPC stuff. Which is both good and bad. I really like that a lot of user space tools just create a secondary binary and an easy interface to communicate to that process using the main binary, you can either run it by itself, use it as a systemd/sysvinit service, or one-off it. for example I use my WM to start `swww-daemon` and then running `swww <path/to/wallpaper>` just sends a message over a Unix socket to the daemon process which handles everything else. Its sooo much better than internally forking off and all of that, it becomes messy quick and its pretty unnecessary in the present. All that really matters is how robust your IPC and stop-start process is. Sometimes its massively fragile, and it shows. side note, when I first started Unix I was fascinated with daemons. I still think they are one of the coolest things ever.

thayne 2y ago

There is another reason for a service to daemonize itself: you can have the parent process wait for the child to be fully ready before exiting. Modern init systems often have a better way to communicate readiness (for example systemd-notify, or writing a pidfile when ready) but older systems often didn't have a way for a process to directory tell the init process it was ready.