[edwintorok]

I don't think they would complain if things became easier. All I hear about is problems with systemd, and having to solve problems (and learn how systemd and all its components interact so you can debug it) is not easier.

[general_failure]

Yeahz they all spend like 20 mins and come out crying without spending at least a week understanding it.

Which software stack do you know that you instantly get in 20 mins. I for one cannot understand the sysvinit or upstart in 20 mins (ie) to develop and debug. How do you debug sysvinit anyway? Echo's I place in the code do not appear on the screen. Can i claim 'Oh shit this is so broken...'?

[edwintorok]

You can start the daemon manually to check why it fails, or check logs, or put echo in the code like you say, or run the script with -x, there are many possibilities. sysvinit is quite easy to get, because you just apply what you already know (running shell scripts, running shell scripts with -x, read (log) files, etc.) and there isn't a layer in front of you that you don't know how to debug or trace.

And yes LSB init scripts are broken under systemd, exactly because of what you describe (placing echo doesn't show) because it redirects the execution through systemd, and stores the output in journald. Try writing (or debugging) an init script on a non-systemd system and see how much easier it is.

systemd also tries to act "smart" and remember the last state a service was in which makes developing LSB init scripts on a systemd system ... complicated. If an init scripts exits with success (perhaps because the deamon wasn't configured yet) then systemd will remember that and the next time you issue a 'start' it'll be a noop, and claim it was successful. Which leads to countless hours wasted until you figure out what really happened: systemd never even run your script again. So then you run 'restart' on the init script and all is well again.