Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
Control: severity -1 important Hi, On Thu, May 18, 2017 at 10:32:02AM +0200, Christoph Biedl wrote: > Michael Biebl wrote... > > > To mark as mountpoint as network mount, there is the _netdev mount > > option. > > While I can confirm this provides a sane and safe shutdown for a mounted > AoE-device, this works only if the device was initially mounted using > that extra option. A later "mount -o remount,_netdev" exits zero but > does not change /proc/mounts, hence resulting in havoc. If you could > shed some light on this? Is there still a bug against ifupdown that needs to stay open? For the issues in the individual packages (aoe-tools, nbd and the kernel), the cloned bugs exist. In any case, I downgraded it, as it seems that things work fine with the _netdev mount option. Cheers, Ivo
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
Am 18.05.2017 um 10:32 schrieb Christoph Biedl: > Michael Biebl wrote... > >> To mark as mountpoint as network mount, there is the _netdev mount >> option. > > While I can confirm this provides a sane and safe shutdown for a mounted > AoE-device, this works only if the device was initially mounted using > that extra option. A later "mount -o remount,_netdev" exits zero but > does not change /proc/mounts, hence resulting in havoc. If you could > shed some light on this? > >> See man systemd.mount. systemd tries to autodetect that for >> various network file systems >> >> https://github.com/systemd/systemd/blob/master/src/fstab-generator/fstab-generator.c#L164 >> >> https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c#L516 > > As a suggestion (probably too late for stretch), an extension of that > check could inspect the device name as well, to detect AoE, NBD and even > iSCSI devices - the latter probably needs some extra magic. That sounds like a reasonable request if those mount points can be detected reliably. Would you mind filing an upstream bug report that at https://github.com/systemd/systemd/issues I personally have no experience with AoE Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
Michael Biebl wrote... > To mark as mountpoint as network mount, there is the _netdev mount > option. While I can confirm this provides a sane and safe shutdown for a mounted AoE-device, this works only if the device was initially mounted using that extra option. A later "mount -o remount,_netdev" exits zero but does not change /proc/mounts, hence resulting in havoc. If you could shed some light on this? > See man systemd.mount. systemd tries to autodetect that for > various network file systems > > https://github.com/systemd/systemd/blob/master/src/fstab-generator/fstab-generator.c#L164 > > https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c#L516 As a suggestion (probably too late for stretch), an extension of that check could inspect the device name as well, to detect AoE, NBD and even iSCSI devices - the latter probably needs some extra magic. Christoph signature.asc Description: Digital signature
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
Am 14.05.2017 um 11:36 schrieb Guus Sliepen: > Another option is to explicitly add a dependency on the network for a > given mount point in /etc/fstab, see the systemd.mount manpage. > Basically, the following should work: > > /dev/etherd/... /mountpoint ext4 x-systemd.requires=network-online.target > 0 2 To mark as mountpoint as network mount, there is the _netdev mount option. See man systemd.mount. systemd tries to autodetect that for various network file systems https://github.com/systemd/systemd/blob/master/src/fstab-generator/fstab-generator.c#L164 https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c#L516 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
On Sun, May 14, 2017 at 12:49:12PM +0200, Christoph Biedl wrote: > > Maybe this bug should be reassigned to aoetools to provide a > > proper systemd.service file? > > Wearing the aoetools maintainer's hat, I'll be happy to provide that but > will need help on it. Ok. I'll try to create one and send it to you. > > Another option is to explicitly add a dependency on the network for a > > given mount point in /etc/fstab, see the systemd.mount manpage. > > Basically, the following should work: > > > > /dev/etherd/... /mountpoint ext4 x-systemd.requires=network-online.target > > 0 2 > > How about block devices that were mounted manually i.e. are not listed > in /etc/fstag? I doubt they will handled in a sane way during shutdown. Then I would say it's the responsibility of the user to unmount it manually at the appropriate time. If aoetools can detect such mounts and unmount them at shutdown, that would be nice. But only if it's very easy to do. Having ifupdown keep network interfaces alive is not guaranteed to help either. What if you mount an NBD or AoE device via VPN? At some point the VPN daemon will be killed. Is that before or after the kernel unmounts things? > > With a proper aoetools.service, perhaps it should become > > x-systemd.requires=aoetools.service. I see nbd-client has a > > nbd@.service, but it requires you to write your own dev-%i.device > > script. I will duplicate this bug and reassign to aoetools and > > nbd-client. I'll also create a bug report for the kernel bug found. > > My gut feeling warns me about a dependency loop in case of more complex > mount setups like local block device mounted somewhere inside a mounted > AoE block device. A check of that situation will be part of the tests. Well, if all dependencies were correct when booting, then systemd should shut down everything in reverse order, right? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
Guus Sliepen wrote... > I understand the gravity of this bug, the problem is that it's not > ifupdown's fault. That it was ifupdown itself that kept a network > interface up when it detected a network filesystem still being mounted > was a *hack*. Agreed, but at least it worked quite well for the past years for the cases it covered - and as I mentioned there were some more where it did not, so I'll be glad if there's a way to handle this in a saner way. Currently however, it's breakage. > Maybe this bug should be reassigned to aoetools to provide a > proper systemd.service file? Wearing the aoetools maintainer's hat, I'll be happy to provide that but will need help on it. > Another option is to explicitly add a dependency on the network for a > given mount point in /etc/fstab, see the systemd.mount manpage. > Basically, the following should work: > > /dev/etherd/... /mountpoint ext4 x-systemd.requires=network-online.target > 0 2 How about block devices that were mounted manually i.e. are not listed in /etc/fstag? I doubt they will handled in a sane way during shutdown. > With a proper aoetools.service, perhaps it should become > x-systemd.requires=aoetools.service. I see nbd-client has a > nbd@.service, but it requires you to write your own dev-%i.device > script. I will duplicate this bug and reassign to aoetools and > nbd-client. I'll also create a bug report for the kernel bug found. My gut feeling warns me about a dependency loop in case of more complex mount setups like local block device mounted somewhere inside a mounted AoE block device. A check of that situation will be part of the tests. Regards, Christoph signature.asc Description: Digital signature
Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot
Hello Biedl & Biebl, > > retitle 857573 No longer umounts AoE/NBD-based file systems, causing data > > loss > Bug #857573 [ifupdown] systemd: Raise network interfaces fails to stop > cleanly on shutdown/reboot > Changed Bug title to 'No longer umounts AoE/NBD-based file systems, causing > data loss' from 'systemd: Raise network interfaces fails to stop cleanly on > shutdown/reboot'. > > severity 857573 grave > Bug #857573 [ifupdown] No longer umounts AoE/NBD-based file systems, causing > data loss > Severity set to 'grave' from 'important' I understand the gravity of this bug, the problem is that it's not ifupdown's fault. That it was ifupdown itself that kept a network interface up when it detected a network filesystem still being mounted was a *hack*. It's not ifupdown's job to patch over dependency issues in other packages, especially not now that we have systemd with its promise of being able to do this correctly. There are three components here: 1. ifupdown 2. AoE/NBD 3. the mounted filesystem Ideally, the filesystem mount should depend on AoE/NBD, and AoE/NBD should depend on the network being up. Looking at aoetools, if run under systemd, its service is masked, so /etc/init.d/aoetools is not called at boot or shutdown time. Under sysvinit, it would actually unmount filesystems mounted from AoE servers. Maybe this bug should be reassigned to aoetools to provide a proper systemd.service file? Another option is to explicitly add a dependency on the network for a given mount point in /etc/fstab, see the systemd.mount manpage. Basically, the following should work: /dev/etherd/... /mountpoint ext4 x-systemd.requires=network-online.target 0 2 With a proper aoetools.service, perhaps it should become x-systemd.requires=aoetools.service. I see nbd-client has a nbd@.service, but it requires you to write your own dev-%i.device script. I will duplicate this bug and reassign to aoetools and nbd-client. I'll also create a bug report for the kernel bug found. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature