Hi, I was hoping someone could help me make sure I'm not overlooking
something with trying to manage mounts on iSCSI disks.

I have an iscsi.service which starts and stops sessions to iSCSI
targets.  It's set with Before=remote-fs-pre.target and
Wants=remote-fs-pre.target to ensure that remote fs ordering is enabled.
Unfortunately mount points only get configured as remote if there is a
record in /etc/fstab at the time fstab-generator is run.

At boot fstab-generator is picking up on the _netdev option in fstab,
and the generated mount units are ordered against remote-fs properly.
If I leave a filesystem mounted at shutdown, it will be unmounted before
the iSCSI session is destroyed or the network is shut down and
everything works as expected.

But there are two cases that are problematic, adding entries to fstab at
runtime and manually mounting without adding to fstab (while still using
the _netdev option, some hint is needed).  The first case actually ends
up being the second, with the possible work-around of always remembering
to run a daemon-reload after editing fstab to run fstab-generator again.

If there's no matching mount unit from fstab-generator, one gets created
dynamically when the fs is mounted by monitoring /proc/self/mountinfo.
While the core mount unit code checks for _netdev, it's never present in
mountinfo.  Back in the days of a userspace managed mtab, the _netdev
flag was stashed there and could be looked for later, but not so any

So for any mounts to remote block devices (unlike remote file system
protocols which are detected by the fs name), unless there is an fstab
entry at the time fstab-generator is run they get treated like local fs
mounts and connectivity to the storage target may be disrupted before
unmounting (possibly resulting in file system errors).

I'm currently at a loss for how to handle this, other than to claim that
if filesystems are going to be left mounted they should be added to
fstab and a daemon-reload is required.

Thanks in advance for any ideas,

- Chris
systemd-devel mailing list

Reply via email to