On Sun, Apr 09, 2017 at 09:30:20AM +0100, J Martin Rushton wrote: > For those of us with (in my case) over 30 years in the industry, reading > init scripts is trivial and at least we can see what is going on and fix > problems quickly. As someone who has both debugged and written many init scripts, I'm a big fan of the way systemd does things. Every distro provided their own shell functions, so you ended up with a debian init script, a redhat init script, and usually some weird "kinda works everywhere" init script that used neither and reinvented the wheel. Quite often, what was going wrong was *NOT* apparent by glancing at the init script. How do you enforce limits on the service? Run ulimits in the script? The service starts fine if you run '/etc/rc.d/init.d/myservice start', but then if you run 'service myservice start', it fails. On top of that, there's no journal so you can't even *SEE* why it is failing during boot unless it is kind enough to write an error to the console. Hope you have a crash cart! Also, how configurable is the init script? You had to hope that upstream was smart enough to use environment variables that were sourced from /etc/sysconfig/servicename. Sometimes I had to do evil things like put executable code into /etc/sysconfig/servicename which fixed problems with the init script. Also, that reminds me, there's no simple way to override some or all of a packaged init script, except to provide your own alternative init script that had a different name. And don't get me started on the terrible startup sequence rules. I've seen several people who have edited the init script itself and then had it replaced by a yum update, breaking their service. The RPMs don't mark the init script as a config file. > Some vague, poorly documented, data file which is > interpreted by a black box is the sort of joy one expects from the > murkier regions of Redmond not the sunnier climes of Carolina. I don't know... I find the unit syntax pretty simple to read. It says what processes are going to be run, what user it'll run under, you can see what order it wants to be run, etc. There are dozens of man pages for systemd, each with examples. Don't get me wrong, I have a lot of anger about some of the stuff that systemd does. But lets not reminisce about SysVinit as if it was anything but a horrible mess. systemd's best feature is that it finally makes managing services better. -- Jonathan Billings <billings at negate.org>