Public
Jan 22, 2013
Here's a pretty interesting post about systemd from an admin's perspective. It compares systemd with Upstart and SMF in a number of ways, written by somebody who actually did his research homework and apparently played around with this stuff.
I wish we could have more of these well written postings!
I wish we could have more of these well written postings!
View 24 previous comments
+Matthias Urlichs Nah, not true. Socket activation does not interfere at all with current monitoring daemons. Lazy activation does, but socket activation makes sense even if you start your daemon right at boot anyway (see above).
That all said, we expose a ton of information on the bus about all services/sockets, precisely for the consumption by monitoring tools. I hope they will pick this up eventually.Jan 23, 2013
+Lennart Poettering For those cases ( where socket activation is local socket/ would already start anyhow ) I can most certainly agree that it'll be an improvement in the ordering and stability. What I'm more concerned about is the network-level of socket activation, which xinetd somewhat effectively proved was broken in many but the most simplistic casesJan 23, 2013
+D.Spindel Ljungmark network-level doesn't have to be lazyJan 23, 2013
+D.Spindel Ljungmark The thing is, I don't want rsync to be running all the time, only when there's work to be done---I'd ordinarily hook it into xinetd, which means I need to monitor that xinetd is running all the time (obviously I have alarms on the client-side). With systemd, I can trust that systemd is always there and running, because if it's not, the host is dead and I'd get a dozen other pages about that box.Jan 24, 2013- +James Cape I see what you mean there. That's the lazy loading that +Lennart Poettering talks about. What I would need is for monitoring tools to be firmly aware that it's still lazy and not having trouble starting. If it's so, it might just need them to query status over dbus rather than monitor process + open ports.Jan 24, 2013
+Lennart Poettering, I'll try to write something coherent about the problems I see but it'll probably take a bit of time since I want to do a good job of it. I didn't find anything big that struck me as a real mistake; all of the stuff that I ran across were more in the way of relatively modest irritations or rough spots.
Unfortunately I don't really have anything to say about SMF. Although we run Solaris 10 machines we have assiduously ignored SMF as much as possible (and have been able to get away with it). My SMF experiences are of being irritated with it in various ways.
One thing about SMF: although I don't like its long hierarchical names, they and wildcard support do allow you to ask for the status and so on of subsets of services. You can do eg 'svcs network/*' to see the status of every network related service. (You can do more general wildcards, but that can already be more or less duplicated by grep'ing systemctl's output.)Jan 24, 2013
