Another daemon for managing control groups
Another daemon for managing control groups
Posted Dec 14, 2013 13:42 UTC (Sat) by kleptog (subscriber, #1183)In reply to: Another daemon for managing control groups by cas
Parent article: Another daemon for managing control groups
init doesn't let you specify a user to start as. cron can in /etc/crontab, but not in /etc/cron.d. cron and at capture output and send it via email, the others don't have a proviso for log output. cron allows configuration of environment variables, init doesn't.
None of them support ulimits, none of them support cgroups, There are no moves in that direction either.
And most importantly, none of them actually *manage* the processes they start. For example, you find the list of currently running cronjobs using ps, why? sysvint doesn't notice if a process dies or fails to start. For an actual production system you end up using something like daemontools, which despite having a lot less code than init actually ends up being more useful (especially the helper programs setuigid, envuidgid, setlock, envdir, softlimit which really should be standard stuff). ISTM people praising the Unix-way should be using daemontools as init, since it's modularity is much better than init's.
So in my opinion it's good that someone has picked up the ball and replaced all these mutually incompatible programs with a uniform system that allows me to configure everything about starting a process uniformly and manage them in a uniform way. Now if support for containers/umask/ulimits/chroots/etc is added it works for all kinds of processes, not just for the init/inetd/cron/at daemon that happens to have gotten support for it.
As for the journal, in daemontools you use multilog to replace syslog and logrotate in one go. All systemd has to do is something better than multilog (which isn't hard) and I think you have a winner.
So as far as I can see, systemd is a win for people who want to use their systems to do real work.
