Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot

2018-08-24 Thread Ivo De Decker
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



Processed: Re: Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot

2018-08-24 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 important
Bug #857573 [ifupdown] No longer umounts AoE/NBD-based file systems, causing 
data loss
Severity set to 'important' from 'grave'

-- 
857573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot

2017-05-18 Thread Michael Biebl
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

2017-05-18 Thread 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.

Christoph


signature.asc
Description: Digital signature


Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot

2017-05-14 Thread Michael Biebl
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

2017-05-14 Thread Guus Sliepen
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

2017-05-14 Thread Christoph Biedl
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

2017-05-14 Thread Guus Sliepen
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