Re: s6 as a systemd alternative

From: Casper Ti. Vector <>
Date: Tue, 27 Jun 2017 10:53:52 +0800

(Normally Jonathan would be replying to this point, but I still do not
see him in this thread, so I rashly take this job ;)

On Mon, Jun 26, 2017 at 05:05:15PM +0200, Istvan Szukacs wrote:
> I understand that service files are much better that shell scripts

Actually they are not. This statement might appear logical when you see
[1] or some similar comparisons made by systemd proponents; however,
there are some problems with such comparisons, and here are the ones
that come to my mind at this time:
* The script on the left is a script for sysv-rc; sysv-rc is,
  admittedly, a terrible system. rc scripts for some other traditional
  rc systems are much cleaner, eg. that for openbsd [2], or that for
  openrc [3].
* Traditional rc systems still deal with double-forking daemons, using
  pid-files, which is an awkward mechanism [4]. By abandoning double
  fork, process state handling (and daemon logging) would be much more
  straightforward [5].
* systemd unit files may seem a little more descriptive (and verbose ;)
  than the scripts in [5]. However, by chainloading, you can use
  noncommutative operator combinations (like passing some information in
  some environment variables and then cleaning up the environment after
  use of this information in some initialisation), which is difficult to
  achieve with systemd unit files. Implementing the ordering of
  operators by ordering of lines in the unit file would probably result
  in reinventing execline / nosh, in an ugly way (actually they already
  partially reinvented the shell: note the `ExecStart*' fields in the
  unit file specification).
* systemd implements the mechanism for process state manipulation in
  pid-1, which leads to considerable safety/security implications. By
  chainloading, all of these can be factored into the run script,
  without increasing complexity of the user interface.

[1] <>.
[2] <>.
[3] <>.
[4] <>.
[5] <>.

My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Tue Jun 27 2017 - 02:53:52 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC