3 ms·

in the bad old times, every linux distro implemented its init scripts in a slightly different way, often with distro specific tooling and commands for accomplis

• westurner 2y ago
  systemd unit files require minimal modification by distro repackagers. With SysV-init, it was/is necessary to modify /etc/init.d/servicenamed shell scripts to get consistent logging and respawning behavior. With SysV init it's not possible to add edges between things to say that networkd must be started before apached; there are 6 numeric runlevels and filenames like S86apache, which you then can't diff or debsums against because the package default is S80apache and Apache starts with A which alphabetically sorts before the N in networkd. And then add cgroups and namespaces to everything in /etc/init.d please
  • michaelmrose 2y ago
    There were and are other options other than systemd and SysV years prior in fact. OpenRC and upstart predate it and s6 was not much later.
    • westurner 2y ago
      It's possible to pipe stdout to syslog through logger by modifying the exec args. But I'd rather take journald's word for it. Supervisord (and supervisorctl) are like s6. I don't think any of these support a config file syntax for namespaces, cgroups, seccomp, or SyscallFilter. Though it's possible to use process isolation with any init system by modifying the init script or config file to call the process with systemd-nspawn (which is like chroot, which most SysV-init scripts also fail to do at all, though a process can drop privs and chroot at init regardless of init system). systemd works in containers now without weird setup. Though is it better to run a 'sidecar' container (for e.g. certbot) than to run multiple processes in a container?