9 ms·

> processes that daemonize themselves for good reason (like nginx or Unicorn) Is there a good reason? I assume you're thinking of the ability to fork and exec

> processes that daemonize themselves for good reason (like nginx or Unicorn) Is there a good reason? I assume you're thinking of the ability to fork and exec a new master process, running, e.g. a new version of nginx, then handing control to that new master without dropping any connections, possibly even waiting around a bit in case the new master dies and the original master needs to take over again. I suspect with something like s6-fdholder-daemon [1] could be used to orchestrate a similar process, though I'm not enough of an expert to know. Instead of inheriting file descriptors through forking, an entirely separate, supervised nginx-newversion could be started, get the file descriptors from fdholder, then coordinate with nginx-oldversion about who's going to accept new connections. Certainly depending on such a service is arguably more complex then just having the functionality built-in. On the other hand, just as every service should not implement its own daemonization, one can argue each service should not implement its own hot restarting. If the technique was more common, the argument to not duplicate such code would be stronger. [1] http://www.skarnet.org/software/s6/s6-fdholder-daemon.html http://www.skarnet.org/software/s6/s6-fdholder-daemon.html

daurnimator 11y ago
> I suspect with something like s6-fdholder-daemon [1] could be used to orchestrate a similar process, systemd has the ability to hold fds for you. You need to enable it for each service with http://www.freedesktop.org/software/systemd/man/systemd.service.html#FileDescriptorStoreMax= http://www.freedesktop.org/software/systemd/man/systemd.serv... and the service needs to know hot to actually do it.
skarnet 11y ago
Yes, that was exactly the idea behind s6-fdholder-daemon: set up a central server to keep fds open when you need to restart a process. The old process stores the fd into the fdholder, then dies; the supervisor starts the new process, that retrieves the fd from the fdholder, and starts serving. And if you don't want to use a supervisor or a fdholder, you don't even need to coordinate, and you never need to fork: simply re-exec your executable with your serving socket in a conventional place (stdin is good). Daemons should be able to take a preopened listening socket and serve on it; hot-restarting is then a simple matter of one execve(). There's really no reason to make it more complicated.

daurnimator 11y ago

> I suspect with something like s6-fdholder-daemon [1] could be used to orchestrate a similar process, systemd has the ability to hold fds for you. You need to enable it for each service with http://www.freedesktop.org/software/systemd/man/systemd.service.html#FileDescriptorStoreMax= http://www.freedesktop.org/software/systemd/man/systemd.serv... and the service needs to know hot to actually do it.

skarnet 11y ago

Yes, that was exactly the idea behind s6-fdholder-daemon: set up a central server to keep fds open when you need to restart a process. The old process stores the fd into the fdholder, then dies; the supervisor starts the new process, that retrieves the fd from the fdholder, and starts serving. And if you don't want to use a supervisor or a fdholder, you don't even need to coordinate, and you never need to fork: simply re-exec your executable with your serving socket in a conventional place (stdin is good). Daemons should be able to take a preopened listening socket and serve on it; hot-restarting is then a simple matter of one execve(). There's really no reason to make it more complicated.