> The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing uni

> The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art. I call bullshit on that. We removed few thousand lines of SysV init scripts from our configuration management that were basically fixed by us for subtle errors when we migrated to systemd. There is very little cases that aren't handled by very simple systemd units, in fact I'd dare you to give example that would be easy in SysV and hard in systemd. Few fun cases: Process after doing /etc/init.d/servicename start -> status immediately returned service stopped. That confused service managers like Pacemaker that thought the service failed to start. Why? The app did start -> save pid file. Java app so it took a second. The script just forked the app into background. So if you run status after start the pidfile was not there and it showed it is stopped. Not the problem in systemd Another (IIRC) MySQL init script put pid file in /var/run/, like everything else. Bit old install so /var/run wasn't a separate partition or tmpfs. MySQL init script also didn't try to start if it found the PID existing in system. It didn't check what* was running tho. So in crash scenario, server started, MySQL init script went "oh, there is apache daemon using that PID I had last reboot, clearly that means mysql is working" and exited. MySQL status returned MySQL working. Not a problem in systemd Another: Script just... sent signal and exited on stop. App could took some minutes to shut down. stop -> start failed, pid was lost coz script removed file with it after sending signal.... similar problem with multi-process app scripts not killing all childs. Systemd "just have a cgroup and mark service as stopped once everything dies" fixes that. YOu can ask for that behaviour if you tell systemd to not kill processes on stop but that's pretty much "purposefully using non-default settings" so can't be really done on accident. IIRC all or most of that is how SysV init script by standard should not work but were simply bugged Those scripts were in popular packages in "enterprise" linux distros. If even those maintainers can't make "simple SysV script" then maybe sysv scripts aren't as "simple" as some people claim they are.