Mike Edwards wrote... > The stop job for 'Raise network interfaces' fails to complete when > shutting down or rebooting a fresh stretch install when certain > conditions are met: > > * ATA-over-Ethernet (aoe) kernel module is loaded, and AOE devices are > listed in /dev/etherd > * Interface bridging via brctl is used > > If either one of these conditions are not satisfied, reboot or shutdown > will proceed without issue. If both are present, 'Raise network > interfaces' will repeatedly try to stop, raising the timeout on > occasion, but will never complete. This means an easy workaround is > ensuring the 'aoe' kernel module is removed before shutting down or > rebooting, if no aoe disks are in use at that time, but that can't be > guaranteed in all situations.
The issues here are pretty similar so I guess it's the same thing: Up to
and including jessie(sic!), networking wasn't brought down if there is
something mounted using AoE.
If I understand correctly, this was done by a check in
/etc/init.d/networking:
case $DEV in
/dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*|curlftpfs*)
log_warning_msg "not deconfiguring network interfaces: network
devices still mounted."
exit 0
It seems this script, while still present in stretch, is just no longer
being run, at least on installations that use systemd.
Also, "no-auto-down" does *not* work for me, shutdown hangs for some
time since umount tries to access a device that is no longer available
as networking is already down, resulting in a kernel stack trace for
"umount:<pid> blocked for more than 120 seconds" and a file system not
cleanly umounted.
Things are worse if there's another layer on top of AoE like
LVM-over-AoE, something I do quite often. Up to and including jessie I
could manually add an "exit 0" into /etc/init.d/networking near that
check above, this is no longer an option. Shutdown just hangs
completely.
Please investigate as I consider this feature loss a grave bug, making
ifupdown unfit for release.
Suggestions: As the old check was rather limited, restoring that feature
isn't the best thing to do. I'd rather, very simple, introduce a
configuration variable (in /etc/default/ifupdown?) that allows the
administrator to disable netdown deconfiguration entirely. This also
requires a mentioning in the release notes.
The smart approach was to auto-detect such a situation and disable
network shutdown only if this would cause havoc. Straight-forward
detection was parsing the lsblk output which however does not present
iSCSI devices.
Christoph
signature.asc
Description: Digital signature
