Systemd as tragedy [LWN.net]

Systemd as tragedy

Posted Jan 29, 2019 4:24 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I'd call a service an API surface. This may be implemented by multiple processes or even none at all (e.g., I have "services" which just set environment variables in my user session). It is best to handle these logical units together (e.g., using cgroups) and handle their interdependencies properly. Since the other systems mentioned here really only deal with processes (i.e., daemons), I think they miss some important use cases that, I at least, find very useful.

Systemd as tragedy

Posted Jan 29, 2019 15:05 UTC (Tue) by nettings (subscriber, #429) [Link] (4 responses)

Consider a mail server, maybe postfix, with spam filters attached. There is your outgoing smtp daemon, an incoming one which passes the mails to the spam filter daemon, and of course a daemon to periodically update the spam filter criteria. Systemd provices quite nice semantics to deal with the interdependencies of all those individual parts.

Systemd as tragedy

Posted Jun 4, 2019 19:25 UTC (Tue) by mikebabcock (guest, #132457) [Link] (3 responses)

Yes, it provides some interfaces for doing what you described but they're hardly nice nor complete. Trust me, I run mail servers and I really wanted the systemd way to be better but its simply not. As a simple example, clamd and spamd are running in their own way because they manage their own processes but that wouldn't matter, and smtpd is being launched per-connection to then filter messages through spamd and clamd -- which, if they aren't available, simply fails, because smtpd doesn't know if they're not available once it launches.

This is not a well-integrated system (it almost can't be) and is redundant. There are good ways to handle inter-process communication and it doesn't belong in systemd.

Systemd as tragedy

Posted Jun 4, 2019 20:41 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (2 responses)

Simple, contribute code to clamd and spamd to make them socket-activable. That would make them "always available", barring configuration errors. Which are beyond systemd's jurisdiction.

Systemd as tragedy

Posted Jun 24, 2019 14:54 UTC (Mon) by nix (subscriber, #2304) [Link]

spamd in particular (and I believe clamd too) run that way because they are very expensive to start up, and consume lots of memory: they in effect use what Chromium calls a zygote process to share most of that memory across processes via forking. You don't want to restart them whenever a new message comes in, or even every N seconds, and you want their immediate parent to be something that has the same set of pages.

Systemd as tragedy

Posted Sep 5, 2019 19:25 UTC (Thu) by soes (guest, #134247) [Link]

Someone else explained the problem with regards to spamd/clamav.

I uses cfengine, which has its own rather dependable solution to authorizing/authentication access to the
policy distribution process (or the policy activation on a client.)
Writing a systemd aware version of cf-serverd (which distributes policy and also
is used to activate the installed policy) would require a fork of the software ie cfengine due to:

the rule languages itself has constructs to authorize policy users ie hosts with only particular
IP addresses will get an open socket at all, other hosts will not get anything ie connects at all

cf-serverd uses a private-public private key pair to authenticate the connection including authenticating itself !

The authentication is done in C(C++) code, and has had basically no security holes the last 10 years.

Systemd as tragedy

Posted Feb 1, 2019 4:21 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

A service specification includes specifications for execution environment, setting priority, UID, GID, security settings, process namespace, filesystem access, cgroup controls, and other things. It has a number of static lifecycle models (run as daemon, run as simple process, start automatically on a socket connection, etc) and monitoring schemes (waitpid, pid file, keepalive pings, auto restart on failure, various protocols for detecting failure). All the child processes created by a service are part of the service, and the service lifecycle controls the entire group of processes. Services have names and dependencies so you can throw them all at systemd in a big jumble and it calculates some order to start them up and take them down. In addition to daemons, there are also units for scheduling execution of other units, mounting filesystems, running dbus services, asking users for passwords, and assorted other tasks more specialized than "run a daemon". There are also unit generators which automatically create instances of services from a template (e.g. each incoming ssh connection can run as a separate unit, each LVM or mdadm device gets its own unit). There's a management interface to control them all, and various tools to record and analyze their interactions.

The lifecycle management, scheduling, dependency management, and external triggers (sockets / mount points / etc) are all jumbled together in systemd, whereas they were traditionally managed by separate specialized daemons and command-line tools.