[systemd-devel] Automount units: intermittent failure when the real mount triggers another mount first
Malte Starostik
lists at malte.homeip.net
Sun Jun 3 12:35:38 PDT 2012
Hi,
I stumbled accross this issue when trying to get this construct working:
mnt-portage.automount is an enabled unit
mnt-portage.mount mounts an nfs4 export and depends, via Requires=, and After=
on some other units that in turn depend on var-lib-nfs-rpc_pipefs.mount
The result is that the very first access to /mnt/portage fails with -ENODEV
while any subsequent access works just fine and all units in the whole
dependency chain have been started successfully.
To get any weird NFS-interaction out of the way, I reduced the whole thing to
a minimal testcase:
===== tmp-test.automout, enable this one
[Unit]
Description=automount test automount point
After=local-fs.target
[Automount]
Where=/tmp/test
[Install]
WantedBy=multi-user.target
===== tmp-test.mount
[Unit]
Description=automount test mount point
Requires=tmp-dummy.mount
After=tmp-dummy.mount
[Mount]
What=/
Where=/tmp/test
Options=bind
===== tmp-dummy.mount
[Unit]
Description=automount test secondary mount point
[Mount]
What=none
Where=/tmp/dummy
Type=tmpfs
First access to /tmp/test results in "no such device", next access will
succeed. To test things further, I changed tmp-test.mount to Requires=,
After= tmp-dummy.service instead of tmp-dummy.mount:
===== tmp-dummy.service
[Unit]
Description=automount test secondary mount point as a service
[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=/bin/mkdir -p /tmp/dummy
ExecStart=/bin/mount -t tmpfs none /tmp/dummy
ExecStop=/bin/umount /tmp/dummy
This has the same effect.
The correspondin log entry:
Jun 03 21:26:30 test systemd[1]: Sending failure: No such device
This comes from here:
#0 mount_notify_automount (m=0x1076a90, status=-19) at src/core/mount.c:616
#1 0x0000000000422133 in mount_set_state (m=0x1076a90, state=MOUNT_DEAD) at
src/core/mount.c:659
#2 0x0000000000424f05 in mount_fd_event (m=0x10413d0, events=10) at
src/core/mount.c:1613
#3 0x0000000000410a80 in process_event (ev=0x7fffa4d2ba10, m=0x10413d0) at
src/core/manager.c:1392
#4 manager_loop (m=0x10413d0) at src/core/manager.c:1497
#5 0x000000000040b2f3 in main (argc=1, argv=0x7fffa4d2c238) at
src/core/main.c:1619
The BP on mount.c:616 is hit like this six times in a row.
Misc info:
Distro: Gentoo
Kernel: 3.4.0
systemd: 7ff5404be1bad93cb8facbcae0bc78f77f9e067d
Dunno if this is Gentoo-specific or triggered by some broken kernel
configuration I used, but I'll gladly help figure this out if maybe someone
could push me into the right direction.
Thanks,
Malte
More information about the systemd-devel
mailing list