Distributors ponder a systemd change

Posted Jun 19, 2016 3:53 UTC (Sun) by zblaxell (subscriber, #26385)
In reply to: Distributors ponder a systemd change by pizza
Parent article: Distributors ponder a systemd change

My first (and last) encounter with systemd three years ago revolved around this behavior. Some Yocto distribution or other had decided to turn this on by default, and it ruined my day.

Since then I've copied the behavior for myself, in the form of a half dozen five-line shell scripts that replicate systemd's cgroup behavior. Every aspect of the cgroups' lives--how much RAM, CPU, and IO they can use, and making sure processes run, live, and die when they're told to--can be handled this way. It's _awesome_, and it's definitely one of the better ideas coming out of the systemd project.

The other thing I realized was that sysvinit had been ruining my days for years, and systemd was going to continue that pattern. To isolate myself from upstreams that should know better, but make breaking behavior changes anyway, I replaced init with a shell script. It's a little longer than five lines--ranging from 55 to 155 lines of code depending on whether it's a desktop, embedded, or server workload--but I haven't looked back since.

It was a painful transition with a bit of learning curve, but it needs much less attention than before. Apparently the best tools for the task at hand were the Unix shell, the & operator, and some small syscall wrapper programs.

Distributors ponder a systemd change

Posted Jun 20, 2016 7:56 UTC (Mon) by zlynx (guest, #2285) [Link] (1 responses)

I'd have to double check but I am pretty sure the shells don't do init's job properly. Signal handing and child reaping, if I recall correctly.

You can get away with it for system rescue, but long term?

Distributors ponder a systemd change

Posted Jun 20, 2016 14:01 UTC (Mon) by zblaxell (subscriber, #26385) [Link]

To be clear, this was never intended to be a rescue system. We did a pilot project and the results were so successful (QA particularly enjoyed having a much more repeatable testing experience) that we promoted it to production and formally terminated plans to switch to anything else. We deploy everything this way now.

I'm not sure if _any_ shell works, but bash and dash do. Any shell that can trap signals (i.e. all of them) and that uses PID 0 as the argument to waitpid (all of them written after 1987) do this just fine. The kernel blocks most of the fatal signals anyway. If /bin/sh is segfaulting you have big problems and you should probably panic the kernel to stop them from getting worse.