[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