Bug#208010: Require init.d scripts comply with LSB
Christoph Anton Mitterer <calestyo@scientia.net> writes:
> On Thu, 2010-07-29 at 15:58 -0700, Russ Allbery wrote:
>> I think LSB exit codes are by far the most controversial part of the LSB
>> proposal, are of dubious utility,
> What are the arguments against them?
Please see the bug log for this bug. It was the first thing that everyone
objected to.
Also, as Joy points out in:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208010#52
this is backwards. What are the arguments *in favor* of them? Our
default should be to not put requirements on packages in Policy; Policy is
already long and complicated. We should only be putting requirements in
packages when doing so solves a concrete interoperability or
standardization need.
Certainly, one argument in favor is "so that we comply with LSB." But I
don't think that is, by itself, sufficient justification to change all the
init scripts in Debian, particularly given that there's a reasonable
chance that we'll be moving away from init scripts, at least in part, to
some other system in the relatively near future given all the other
drawbacks and deficiencies of the init script system.
> That makes ever introducing such changes extremely difficult, even if
> the are worth it (as the dependency based booting proved ;) )
That's correct. It's very difficult, and requires a high bar, to
introduce change into Debian that requires all package maintainers of a
particular type of package, such as ones with init scripts, to change
their packages. I think this is a feature, not a bug. We would be asking
a lot of people to do a lot of work, and we need to be very clear that
it's worth it.
The LSB script headers solved a real problem and let us introduce a better
boot system, and the project considered that worth it. It's not at all
clear to me that the init script status codes have a similar compelling
use case.
I'm more of an advocate of status, since status is very useful for
configuration management tools such as Puppet and avoids duplicating init
script information to figure out whether a daemon is currently running.
> Is there a "mechanism" in Debian... e.g. something like a staging area,
> where one could specify such stuff (or things like the dependency based
> booting) in order to clearly tell everybody "this is the future,...
> start adopting it" but not making their packages immediately break the
> policy?
I think that's the goal of the DEP process:
http://dep.debian.net/
>> Do you have an example of a bug or user problem where the current
>> Debian Policy caused problems and would have been fixed by having a
>> different requirement? I suspect this is only a theoretical issue.
> No... see the example with cryptsetup I've described above, where
> following the policy would open a security problem.
I don't agree that your example has proven that. It looks theoretical to
me, and a stretch to call that a security issue in Debian (as opposed to a
misunderstanding by the user of what's required to maintain a consistent
system). If the user wants to have encrypted devices, they need to not
remove the packages that handle device encryption.
>> I'm personally strongly opposed to changing this design principle in
>> Debian. If the package is removed but not purged, the init script
>> should not report errors. This is a common case in Debian, and I think
>> it would be a significant regression to have init scripts start
>> producing errors in this situation.
> Well that was just a suggestion :) ... anyway... can you tell examples
> where this would really produce errors (I mean except some messages to
> that initscript foo has failed).
You're excepting something that I'm not willing to accept. If the package
is removed but not purged, the init scripts should not be producing
errors.
> My long term wish (and it will be a very very stony way) is to package
> dCache... this make use of different other daemons e.g. a database
> (postgresl, or others) and some message brokers (activeMQ, an internal
> system)... etc.
> Require-start or should-start is AFAIU not the solution to start them,
> because one wants to be able to select alternatives.
> And on needs to tell the actual deamon which is used. Therefore, testing
> with status could be a nice solution,... or at least I cannot think of
> any better right now ;)
I would prompt the user with debconf to ask them which backends they want
to use. Assuming that they want to use a backend just because a package
is installed and running on the system is a bad assumption, I think,
although it's a reasonable way to set the default for the debconf
question.
>> I can see how this is a problem for status in particular, since status
>> has different exit code requirements than normal init script actions.
>> The current Policy requirement:
>> These scripts should not fail obscurely when the configuration files
>> remain but the package has been removed, as configuration files remain
>> on the system after the package has been removed.
>> is still reasonable, but the specific recommendation:
>> Therefore, you should include a test statement at the top of the
>> script, like this:
>> test -f program-executed-later-in-script || exit 0
>> doesn't really make sense for status; it only makes sense for the init
>> script actions currently documented in Policy. If we standardize the
>> status action, we should at the same time alter that advice to not
>> recommend an 0 exit status for the status action if the package is
>> removed but not purged.
> Which would probably be 5 then :D
I personally don't see any compelling reason to say that. I don't object
to people using exit code 5, but I don't see any benefit to doing that
work personally.
>> Exiting with a non-zero status when the daemon isn't running isn't
>> "failing obscurely" and is fine under the current Policy requirement;
>> it just doesn't work with the Policy recommendation for how to
>> implement that requirement.
> Uhm... what exactly do you mean? :-O
I mean that your example doesn't violate the intent of the current policy,
just fails because Policy was written without considering a status action.
The intent of the Policy requirement is that actions like start and stop
not fail when the package is removed but not purged, not that status
always return success in that case.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: