[Pkg-sysvinit-devel] Bug#632091: Please add an interface to disable use of the '-i' option.

[Wouter Verhelst]

On Thu, Sep 01, 2011 at 07:45:48AM +0200, Petter Reinholdtsen wrote:
> [Wouter Verhelst]
> > This is because halt is passed '-i' option these days, which (if I'm
> > not mistaken) it did not do originally; and while it is possible to
> > disable this by setting the NETDOWN variable in /etc/init.d/halt to
> > 'no', that isn't something I can do from the nbd-client initscript
> > (which is where I'm currently creating
> > /lib/init/rw/sendsigs.omit.d/nbd-client).
> 
> I'm not quite sure, but suspect this is related to wake-on-lan, which
> is a topic I do not really understand.
> 
> If I am not mistaken, for wake-on-lan to work the interfaces need to
> be up or down, depending on the interface drivers, and there is no way
> to know which is which.  Any default and change in default setting for
> the network during shutdown will then break some existing working
> wake-on-lan setup.

That's a decent argument for not changing the current default.

However, my mail did give three suggestions: changing the default,
providing an interface that can be used from another initscript (similar
to sendsigs.omit.d), and having the halt initscript not use -i if it
detects that it's running root off the network. This final option is
possible, since the networking script does this already, and does it
correctly (it detects this by searching for either nfs, or filesystems
with the _netdev option in their mount options).

Bringing down the network when the root filesystem is on a network
resource is *always* wrong, no matter what wake-on-lan wants. When this
happens, the kernel will panic, because it can no longer access its root
filesystem. If halt does this, it is mostly harmless, since the root
filesystem has been mounted read-only at that point already; but it
still looks very bad to have a system panic rather than power off. I'd
be happy to touch a file so that the -i argument isn't used, but I can't
start modifying other packages' configuration files from init scripts,
obviously (I could do it from the installer, but I'm not sure that's the
best way).

Having said all that, I absolutely doubt whether changing the default is
even going to have any effect. When a system has a configured network
interface, *and the system is not running off the network*, the
networking initscript will bring it down. In that case, 'halt -i' has no
effect.

If, on the other hand, the networking script did not bring the interface
down, then there are two options: either it is not configured (in which
case the interface is most likely not in use and therefore has no
network cable, in which case using or not using 'halt -i' makes no
difference), or it is configured but the networking init script detected
that it should not be brought down for some reason (in which case using
'halt -i' is *wrong*)

So I can see three scenarios; and in none of these three scenarios do I
see a case where using 'halt -i' is the correct and desired way forward.
But perhaps I'm missing something?

Additionally, if a user wants to use wake-on-lan, finds that it doesn't
work, and figures out through documentation or similar that his network
interface needs to be up, not down, would it be their first reflex to
change /etc/networking/interfaces, or /etc/default/halt? I suspect the
former, and I suspect the user will be extremely confused if that does
not have the desired effect. Indeed, I myself did not know about the
'-i' option to halt until I started investigating why root-on-NBD did
not shutdown properly.

Anyway, I'd be happy to provide patches, but then please tell me how
you'd like it to happen.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110901/b091a0b5/attachment.pgp>