[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#546743: openssh-server - init script fails on EIO



On Thu, Feb 23, 2012 at 02:18:42PM +0100, Didier 'OdyX' Raboud wrote:
> Okay, I think I begin to get the whole picture. With my "LSB maintainer
> wannabe" (ITA: #616131) hat on, let's reassign this to openssh-server
> while keeping a trace of this on the lsb-base package.

Agreed.

> Le 23.02.2012 14:00, Bastian Blank a écrit :
> >> As for the CTTE, do we have a maintainer decision to override or a
> >> technical disagreement? Or would it be mostly to get a piece of advice?
> > 
> > The maintainer of openssh-server refused to fix it, so it is a
> > maintainer override.

Bastian, the way it works is that you *try to reach consensus*.  You
don't post one bare appeal to authority which at the time was strongly
contraindicated by the normative text in policy (see below), then make
no attempt to follow up for nearly two and a half years during which
time the normative text changes, and then declare that it's time for the
TC to override the maintainer.  Some degree of common sense is supposed
to apply here.

    6. Technical Committee makes decisions only as last resort.
       The Technical Committee does not make a technical decision until
       efforts to resolve it via consensus have been tried and failed,
       unless it has been asked to make a decision by the person or body
       who would normally be responsible for it.

Please take notes on how Didier handled this for future reference:
actually engaging with the problem in some depth was so much more likely
to be persuasive.

> As far as I understand it, the policy now recommends not to use "set -e"
> in init scripts. `openssh-server` puts unreasonable (and not
> policy-backed) requirement on /lib/lsb/init-functions and can therefor
> fail.

Indeed, policy was changed after my previous comments in this bug
report.  Previously, policy's principal statement on error handling in
shell scripts was:

          Shell scripts (<prgn>sh</prgn> and <prgn>bash</prgn>)
          should almost certainly start with <tt>set -e</tt> so that
          errors are detected.  Every script should use
          <tt>set -e</tt> or check the exit status of <em>every</em>
          command.

In that context I think my "obvious nonsense" response wasn't too far
out of line, but clearly the project's consensus has changed a bit since
then.

I'm not entirely happy with the new state of affairs.  Shell is a
fragile language in a number of ways, and 'set -e' is one of the tools
available to make it less fragile (even if it isn't perfect, as noted in
comments on #562506).  Reverting to 'set +e' amounts to changing the
error-handling policy for an entire program for the sake of a small
number of failing commands.  As such, it seems to me to be quite unwise
for a shell library to make it impossible to use 'set -e' reliably,
regardless of what some people think the error-handling policy in
callers ought to be.

However, Russ makes a not totally unreasonable argument about the
general requirements of init scripts in #562506, so I don't feel the
need to push for the policy question to be revisited; and I'm not
unhappy enough with things to refuse to change openssh at all, since I
understand that there is a practical problem here.

So, I'll amend the ssh init script to at least avoid failing if LSB
init-functions fail, which is a safe change independent of anything
else.  I'm not sure as yet whether I'll do this by putting '|| true'
after the function calls in question, or by changing the error handling
throughout; it will depend on which results in clearer code.  Bearing in
mind that I'm currently on vacation (see debian-private), it may take a
little while, but I will get round to this comfortably in time for
wheezy.

> So as far as the lsb-base package is concerned, this should either be
> fixed in policy (then in lsb-base) or in openssh-server.
> 
> Fixing /lib/lsb/init-functions to work with "set -e" init scripts might
> be doable, but needs more work, hence tagging as +help.

I would say that the first step is to fix init-functions to work with
'set -e', and that this would be a good idea independent of any other
change.

Current policy is considerably more measured than the skeleton init
script.  It says:

     Be careful of using `set -e' in `init.d' scripts.  Writing correct
     `init.d' scripts requires accepting various error exit statuses when
     daemons are already running or already stopped without aborting the
     `init.d' script, and common `init.d' function libraries are not safe
     to call with `set -e' in effect[1].  For `init.d' scripts, it's often
     easier to not use `set -e' and instead check the result of each
     command separately.

I would remind Bastian that /etc/init.d/skeleton is merely an example.
It might be worth the initscripts maintainer toning down the comment
there, which is considerably fiercer than the normative text in policy.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]



Reply to: