4 ms·

I don't understand. If I write a server app that listens for client connections, why not daemonize that? Is systemd doing all of the listening then invoking the

by snorkel 11y ago

I don't understand. If I write a server app that listens for client connections, why not daemonize that? Is systemd doing all of the listening then invoking the server app if a client connects?

ninkendo 11y ago
Run in the foreground and systemd will do the right thing. Your app is still the one listening for connections, systemd just calls wait() until you exit, then launches you again. There's no need for you to do a fork() or setsid() or whatever, that was a relic of the "just run all these init files as scripts" nature of sysv init.
- eropple 11y ago
  Definitely. Also, when you're in non-systemd environments, runit or supervisord will happily manage your undaemons.
  - cgag 11y ago
    I just started using runit and really like how simple it is. I feel like nows a good time to plug void linux http://www.voidlinux.eu/ http://www.voidlinux.eu/ which I think is pretty cool, it's the only OS/distro I know that uses runit as the init system.
- joevandyk 11y ago
  How does that work with nginx or haproxy, which support zero-downtime restarts?
  - otterley 11y ago
    If nginx and haproxy switch over to SO_REUSEPORT (and the SO_REUSEPORT semantics are fixed in Linux to work like FreeBSD's) it should no longer be an issue: its own worker supervisor need not fork itself, and it can simply manage the children.
  - ninkendo 11y ago
    That's a really interesting question, actually. (This was posted a day ago so I'm not sure anyone will read this any more, but...) If the job of a process "supervisor" is to launch you, wait(2), launch you again, repeat... who has the role of doing zero-downtime restarts? I'll define a zero-downtime restart in this instance as: a new process must be launched while the old process is still running, so it can negotiate a handoff of responsibility (via migrating who owns the port and draining connections in the case of nginx or haproxy), and the old process only dies once the handoff is complete. If you wanted this behavior with systemd/upstart/etc as a supervisor (where processes are foregrounded and monitored), the supervisor would require a special case for "restart" which would just start a new process and monitor that one instead, and not bother with killing the old one. I have no idea if systemd can accommodate for this without switching to a non-supervised process management mode (which is definitely possible.) I don't have much familiarity with advanced systemd or upstart, although I have plenty of familiarity with mesos schedulers, which can be kind of a datacenter-level version of systemd, and in this instance we do "rolling restarts" where new instances are launched, we wait for them to pass health checks, and then we drain the old ones, while a load balancer is responsible for routing incoming connections to the healthy instances. It's an interesting notion for what a single machine's process supervisor should do in this case.
- joevandyk 11y ago
  How does that work with nginx or haproxy, which support zero-downtime restarts?
yrro 11y ago
http://www.freedesktop.org/software/systemd/man/daemon.html http://www.freedesktop.org/software/systemd/man/daemon.html
chimeracoder 11y ago
> If I write a server app that listens for client connections, why not daemonize that? Because writing a daemon is almost always more work than writing an application that runs in the foreground. And systemd is capable of taking applications that run in the foreground and running them as daemons instead. Put another way - if something else is doing all of the hard work for you, why would you want to write a daemon yourself, except possibly as a learning exercise?
- vezzy-fnord 11y ago
  Stated more accurately, services running under a supervision suite yield their daemon instantiation to the underlying process manager, for which enforcing a consistent daemon control framework is its purpose. So has been the case since IBM AIX in 1992.
rodgerd 11y ago
> why not daemonize that Double-fork-detach was arguably only ever a hack to get around the limitations of the traditional Unix paradigm (using inetd to handle incoming connections and invoking a standard program to hand the connection off to).

by snorkel 11y ago

I don't understand. If I write a server app that listens for client connections, why not daemonize that? Is systemd doing all of the listening then invoking the server app if a client connects?

ninkendo 11y ago

Run in the foreground and systemd will do the right thing. Your app is still the one listening for connections, systemd just calls wait() until you exit, then launches you again. There's no need for you to do a fork() or setsid() or whatever, that was a relic of the "just run all these init files as scripts" nature of sysv init.

eropple 11y ago
Definitely. Also, when you're in non-systemd environments, runit or supervisord will happily manage your undaemons.
- cgag 11y ago
  I just started using runit and really like how simple it is. I feel like nows a good time to plug void linux http://www.voidlinux.eu/ http://www.voidlinux.eu/ which I think is pretty cool, it's the only OS/distro I know that uses runit as the init system.
joevandyk 11y ago
How does that work with nginx or haproxy, which support zero-downtime restarts?
- otterley 11y ago
  If nginx and haproxy switch over to SO_REUSEPORT (and the SO_REUSEPORT semantics are fixed in Linux to work like FreeBSD's) it should no longer be an issue: its own worker supervisor need not fork itself, and it can simply manage the children.
- ninkendo 11y ago
  That's a really interesting question, actually. (This was posted a day ago so I'm not sure anyone will read this any more, but...) If the job of a process "supervisor" is to launch you, wait(2), launch you again, repeat... who has the role of doing zero-downtime restarts? I'll define a zero-downtime restart in this instance as: a new process must be launched while the old process is still running, so it can negotiate a handoff of responsibility (via migrating who owns the port and draining connections in the case of nginx or haproxy), and the old process only dies once the handoff is complete. If you wanted this behavior with systemd/upstart/etc as a supervisor (where processes are foregrounded and monitored), the supervisor would require a special case for "restart" which would just start a new process and monitor that one instead, and not bother with killing the old one. I have no idea if systemd can accommodate for this without switching to a non-supervised process management mode (which is definitely possible.) I don't have much familiarity with advanced systemd or upstart, although I have plenty of familiarity with mesos schedulers, which can be kind of a datacenter-level version of systemd, and in this instance we do "rolling restarts" where new instances are launched, we wait for them to pass health checks, and then we drain the old ones, while a load balancer is responsible for routing incoming connections to the healthy instances. It's an interesting notion for what a single machine's process supervisor should do in this case.
joevandyk 11y ago
How does that work with nginx or haproxy, which support zero-downtime restarts?

yrro 11y ago

http://www.freedesktop.org/software/systemd/man/daemon.html http://www.freedesktop.org/software/systemd/man/daemon.html

chimeracoder 11y ago

> If I write a server app that listens for client connections, why not daemonize that? Because writing a daemon is almost always more work than writing an application that runs in the foreground. And systemd is capable of taking applications that run in the foreground and running them as daemons instead. Put another way - if something else is doing all of the hard work for you, why would you want to write a daemon yourself, except possibly as a learning exercise?

vezzy-fnord 11y ago
Stated more accurately, services running under a supervision suite yield their daemon instantiation to the underlying process manager, for which enforcing a consistent daemon control framework is its purpose. So has been the case since IBM AIX in 1992.

rodgerd 11y ago

> why not daemonize that Double-fork-detach was arguably only ever a hack to get around the limitations of the traditional Unix paradigm (using inetd to handle incoming connections and invoking a standard program to hand the connection off to).