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 <g...@debian.org>

Attachment: signature.asc
Description: Digital signature

Reply via email to