On 05/11/14 20:54, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Nov 05, 2014 at 08:12:39PM +0000, Ximin Luo wrote: >> All I care is that "service x start" works. It does not. This is >> correctly called "systemd breaks existing software" - it is breaking >> the sysvinit behaviour. > > Let's look what LSB says: > > http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html > >> For all other > [meaning everything apart from 'status'] >> init-script actions, the init script shall return an exit status of >> zero if the action was successful. Otherwise, the exit status shall >> be non-zero > [...] >> 6 program is not configured > > Esentially, your scripts tells systemd "action was sucessful", and > systemd has no reason (or way) to doubt that. >
Sure, I get that my script doesn't work perfectly in this area. I will fix all of this stuff. However, systemd is *also* at fault for not being able to deal with this. With sysvinit, a "start" action is executed regardless of any external considerations - it's just a shell script with a "start" clause. This behaviour should be preserved by systemd; however what actually happens is that this behaviour is overridden quite obnoxiously. Nowhere does the LSB mention "scripts should not expect to work in the future, if they output a non-standard return code previously". This is what systemd does to my script (and other scripts that use dh_installinit). So there is still a bug in /lib/lsb/init-functions.d/40-systemd. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
