[Discuss] SysVinit vs. systemd

[invalid at pizzashack.org (Derek Martin)]

On Fri, Sep 12, 2014 at 12:07:29PM -0400, Mike Small wrote:
> "systemd handles a lot of annoying infrastructure for you; for example,
> you do not have to arrange to daemonize programs you run."
> 
> I don't understand this at all. Aren't daemons written as daemons
> (giving up controlling terminal and whatever else within their own
> code).

An example of a daemon which you might well be using which can be run
without daemonizing, for very good effect, is imapd.  If the user has
a shell account, for example, some imapd implementations (WU IMAP, for
instance) let you speak IMAP on stdin/stdout, enabling you to connect
via ssh and run imapd on your terminal (which in that case would be
the SSH connection).  This allows for imapd to rely on the system to
do authentication for it (rather than hooking into PAM directly, or
implement its own form of auth), and enables the user to have
encrypted IMAP without having to deal with TLS, certs, and the like.
Though, using imapd this way also does NOT require inetd, or systemd,
or anything of the sort, since it just uses stdin/stdout.  It only
requires a method of remote access, of which your system probably
already has at least one. :)

For most modern servers, you probably don't want this.  You want a
single server that uses some sort of event-based/asynch I/O to more
efficiently handle many connections in a single process (probably
using a handful threads for concurrency).  This reduces memory
footprint and context switching drastically, enabling you to handle
one or even two orders of magnitude more connections than the same
server implemented with the one-connection-per-process model.  Search
for C10K if this interests you...

> Question: Here...
> http://0pointer.de/blog/projects/systemd-for-admins-2.html 
> ... as he works up to how he uses cgroups identifying child processes he
> never mentions process groups as an option, only the parent id. Why
> don't multi-process daemons always keep the same process group and use
> that in scripts that kill/restart? 

That's actually a good question.  While it's quite usual for a daemon
to create its own process group (via setsid()) at initialization, I'm
not aware of any daemons that make their children start their own
session/process groups, nor of any good reason to do that (and I'm not
saying that they don't exist--I'm simply admitting that I do not know
everything).  If someone does know I certainly would be interested to
hear what and why...

Actually, I can think of one reason: if you had a "service" that was
comprised of multiple daemons.  Each of them would most likely
daemonize separately, resulting in each of them having different
process groups.  You could, of course, have a single control program
that sets up the session for all of your component daemons, and not
have them individually daemonize, but only if the author(s) considered
this problem, and designed all of the components to be started by a
common ancestor for this purpose.  Possible, but I'm aware of no such
software.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.