[Tfug] systemd

[Bexley Hall]

Hi Jude,

On 5/1/2014 3:59 PM, Jude Nelson wrote:
> My Debian machines will run systemd once they've pried sysvinit from my
> cold, dead fingers.  The systemd developers have done a great job at
> getting their program adopted by means of "tactical coding"--as in,
> coupling together previously uncoupled programs (for questionable
> benefit) so that it in order to run one, you need most/all of systemd to do
> so.  I do not trust such people to have my best interests at heart.

<frown>  Not running Linux, I had to do some digging to understand
the role of this "new" daemon.  Frankly, I don't really see the need
for it.  I guess if you run a service/daemon that isn't well behaved
and wants to ignore signals, etc., then it gives you a more reliable
way of ensuring that you *can* kill those services at shutdown.

But, init(8) could *also* ensure their prompt demise!  I guess I
don't see the problem that it is trying to "fix" -- at the expense that
it is adding  :(

> The only "good" things about systemd that I can see are that it offers a
> declarative way to describe services, and that it uses cgroups to offer a
> reliable "service stop" command.  However, Debian already has a
> systemd-unit-to-init-script compiler that gets me the first benefit, and I
> can put processes into cgroups myself to get the second benefit if it is
> needed (i.e. using the cgroups tools, or LXC).  So, why use systemd at all?
>
> A lot of users like to tout its fast boot/shutdown times, but honestly how
> often do you reboot?  I regularly go ~3 months between laptop reboots, and
> my servers regularly run for about a year between reboots.  I'm not going
> to miss the 40 seconds savings per shutdown/startup.
>
> One of these days I'm going to fork the start-stop-daemon binary to make it
> put a daemon into its own cgroup to start it, and destroy the cgroup (and
> all of its processes) to stop it.  Bam!  Automatic and reliable "service
> stop" without systemd.
>
> Maybe while I'm at it, I'll make start-stop-daemon accept systemd unit
> files by having it use the Debian systemd-unit-to-init-script compiler to
> generate the initscript, and then run the initscript (and the daemon it
> spawns) in its own cgroup.  Then, you can replace your initscripts with a
> bunch of unit files that compile to initscripts, and replace your old
> initscripts with a BSD-style initscript that just runs starts-stop-daemon a
> bunch of times for each unit file.

In *BSD, the rc.d system gives the user a flexible and extensible
way of controlling daemons/servers.  Perhaps the toughest part is
specifying any dependencies so rcorder(8) can ensure the scripts get
invoked in the correct order (instead of the old S##service names that
you had to *manually* maintain/order under SysV)

IMO, this is a no-brainer especially when it comes to adding new
"non-mainstream" services to a system!  (e.g., adding support for
the X font server took me a few minutes to clone a similar rc.d
script and "install" that service).

Linux seems to be headed down the MS path:  tie stuff together
instead of letting it remain a set of "blocks" that the *user*
ties together.

--don