Bugzilla – Bug 114363
subdomain init scripts don't seem to follow current version of LSB spec
Last modified: 2007-01-29 22:21:48 UTC
K47:~ # rcsubdomain Usage: /sbin/rcsubdomain {start|stop|restart|debug|kill} looks like rcsubdomain doesn't follow the current LSB specs (http://refspecs. freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html). This might affect the distro as some functions might be expected by other apps like yast which aren't provided by rcsubdomain as with beta3. Including our LSB guru (kukuk@suse.de) to comment on this.
Actually, the initscript in beta 4 also supports 'status' and 'reload', the usage statement just doesn't reflect that. Based on my reading of the LSB document, force-reload is an equivalent operation for us as 'reload'. rcsubdomain is kind of weird in that it's not starting a daemon, but rather configuring a kernel service. The other thing to note is that we had difficulties with insserv placing subdomain later in the init sequence than we desired, so we have a fix (which didn't make it in time for the beta 4 submission, alas) to make a boot time initscript (boot.subdomain). We do intend to keep the /sbin/rcsubdomain symlink in place, unless that violates SuSE's packaging guidelines for boot scripts. I did notice while glancing over some of the other boot.d/ scripts in beta3 that not all of them implement all of the arguments required in the LSB document referenced, even though the LSB explicitly makes no exceptions for boot and shutdown scripts. Thanks for the bug report.
The LSB does not handle initial boot scripts at all, LSB only specifies the init scripts for LSB conform applications. We only decided to use the LSB init script specification and enhance them for the need of a distribution (LSB clearly says this their spec in this form is unseable for it). But for boot.*, which should never be called later again with rcsomething by an admin, it doesn make sense to follow the full LSB spec. So, boot scripts normally only need to support start and stop on SuSE Linux and should not have a rc link to it.
Users seem to really enjoy the rcsubdomain/rcapparmor convenience link, to save from typing /etc/init.d/boot.apparmor when reloading policy; if we really want to remove the rcapparmor convenience link, it'll only get harder with time. However, I'd like to suggest we keep the convenience link in place, and close the bug -- the gist of the initial report was that the usage message wasn't correct, and this has since been addressed. Thanks
We should add the rc link and let the script as it is, since it is a "boot" and no "init" script.
With the exception of the issue in bug #157373, the issues here have been addressed. I *think* the fixes made it into the 10.0 release; if not, definitely in 10.1.