Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Automount hangs file operations when device is not present. Ignores timeout. #2181

Closed
beanaroo opened this issue Dec 16, 2015 · 4 comments
Closed

Automount hangs file operations when device is not present. Ignores timeout. #2181

beanaroo opened this issue Dec 16, 2015 · 4 comments
Labels
bug 🐛 Programming errors, that need preferential fixing pid1
Milestone
v230

Comments

@beanaroo
Copy link

I have external drives that are automounted on demand and unmounted on idle nicely. Problem is, when a drive is not present, operations (like when the above directory is accessed) hang for 90sec. The x-systemd.device-timeout fstab option works nicely for nofail cases but seems to be of no use for systemd.automount cases.

I have noted, according to systemd.mount(5), that device-timeout is only valid in fstab and not Options=.

If I understand correctly, this is why the fstab entry:

UUID=12345  /home/user/Media/Backup     ext4    noauto,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.idle-timeout=10min     0 0

...is not reflected in systemctl show -a home-user-Media-Backup.mount (generated):

Where=/home/user/Media/Backup
What=/dev/disk/by-uuid/12345
Options=noauto,x-systemd.automount,x-systemd.idle-timeout=10min
Type=ext4
TimeoutUSec=1min 30s

Is this by design or a limitation or just unimplemented? I have come across others with the same problem.
@arvidjaar
Copy link
Contributor

x-systemd.device-timeout should be translated to JobTimeoutSec; do you have it defined?

@beanaroo
Copy link
Author

JobTimeoutUSec = 0, so undefined?

@poettering
Copy link
Member

its more complicated... the device timeout is actually set on the .device unit, not the mount. Hence, to achieve the same effect from unit files, you'd have to add a .device drop-in, not make a .mount change...

@poettering poettering added this to the v230 milestone Apr 18, 2016
@poettering poettering added the bug 🐛 Programming errors, that need preferential fixing label Apr 18, 2016
@poettering poettering mentioned this issue Apr 18, 2016
Closed
1 task
@poettering poettering mentioned this issue May 2, 2016
Merged
@poettering
Copy link
Member

Fix waiting in #3170.

Werkov pushed a commit to Werkov/systemd that referenced this issue Jun 22, 2017
@poettering @fbuihuu
automount: rework propagation between automount and mount units
96ff1f2 
Port the progagation logic to the generic Unit->trigger_notify() callback logic
in the unit vtable, that is called for a unit not only when the triggered unit
of it changes state but also when a job for that unit finishes. This, firstly
allows us to make the code a bit cleaner and more generic, but more
importantly, allows us to notice correctly when a mount job fails, and
propagate that back to autofs client processes.

Fixes: systemd#2181
(cherry picked from commit fae03ed)

[fbui: adjust context: drop the "Propagate start limit hit state" part
       introduced by 6bf0f40]
[fbui: needed by the backport of 0a62f81]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug 🐛 Programming errors, that need preferential fixing pid1
Milestone
v230
Development

No branches or pull requests
3 participants
@arvidjaar @beanaroo @poettering