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

Timeout usbstick automount after 2 seconds #270

Merged
merged 1 commit into from
Feb 18, 2022
Merged

Timeout usbstick automount after 2 seconds #270

merged 1 commit into from
Feb 18, 2022

Conversation

kedder
Copy link
Member

@kedder kedder commented Feb 13, 2022

When user tries to perform any operation that involves USB stick (e.g.
"Download IGC") and USB stick is not inserted, openvario appears to
"freeze" - becomes unresponsive, with no way to recover.

This is because it waits for /dev/sda1 device to appear in order to
mount it. With the default 90s timeout the system appears to be stuck.

This lowers the timeout to 2 seconds to "unstuck" the system quickly
enough before user gets frustrated.

@kedder
Timeout usbstick automount after 2 seconds
97cb3ce 
When user tries to perform any operation that involves USB stick (e.g.
"Download IGC") and USB stick is not inserted, openvario appears to
"freeze" - becomes unresponsive, with no way to recover.

This is because it waits for /dev/sda1 device to appear in order to
mount it.  With the default 90s timeout the system appears to be stuck.

This lowers the timeout to 2 seconds to "unstuck" the system quickly
enough before user gets frustrated.
@MaxKellermann
Copy link
Collaborator

JobTimeoutSec is the generic timeout for a start job, but mount units have a TimeoutSec setting which seems more appropriate. I don't know the exact semantics of both, I just guess "more specific" = "better".
I wonder if we can avoid waiting for a device completely, i.e. never wait, and fail immediately if the device doesn't exist. Because ... what's the point of waiting?

And actually, I wouldn't use the auto-mounter at all. I changed to systemd automount not because I think auto-mounting is fine, but only because I think systemd can do that feature better than the old "autofs" daemon. I think it's better to explicitly mount in all programs that wish to access the USB stick, and more importantly: explicitly unmount when finished.

@kedder
Copy link
Member Author

kedder commented Feb 13, 2022

TimeoutSec is a timeout for mount command, but in this case mountcommand never executes: systemd actually waits for /dev/sda1 device to appear. And it will wait for 90s before failing because it will never appear. IOW, TimeoutSec doesn't work for this purpose.

Automounter is nice in a way because it handles all the edge cases. E.g. it makes sure device is correctly unmounted even if app that reads the device crashes because the stick was taken out in the middle of copy operation.

@kedder
Copy link
Member Author

kedder commented Feb 13, 2022

I wonder if we can avoid waiting for a device completely, i.e. never wait, and fail immediately if the device doesn't exist. Because ... what's the point of waiting?

That's what I do in ovshell - wait for device to appear before looking into the /usb/usbstick directory. Probably something like this can be done in the ng-menu script as well. But at least things are not get IO blocked if something (e.g. opkg update) tries to read the mount point directly.

@MaxKellermann
Copy link
Collaborator

TimeoutSec is a timeout for mount command, but in this case mountcommand never executes: systemd actually waits for /dev/sda1 device to appear. And it will wait for 90s before failing because it will never appear. IOW, TimeoutSec doesn't work for this purpose.

You're right. Though, reading the systemd source code, it looks like "JobRunningTimeoutSec" is better. The fstab generator translates "x-systemd.device-timeout" ("Configure how long systemd should wait for a device to show up before giving up") to "JobRunningTimeoutSec": https://github.com/systemd/systemd/blob/main/src/shared/generator.c#L281

linuxianer99
linuxianer99 approved these changes Feb 14, 2022
View reviewed changes
Copy link
Member

@linuxianer99 linuxianer99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK for me.
But we should really think about the solution Max mentioned: Only mount the stick if necessary (an app needs it)

@kedder
Copy link
Member Author

kedder commented Feb 15, 2022

@MaxKellermann JobRunningTimeoutSec doesn't work for the same reason as TimeoutSec - the job isn't actually running - it is waiting for dependent job (the device) to finish.

@kedder
Copy link
Member Author

kedder commented Feb 17, 2022

Can we merge this?

@kedder
Copy link
Member Author

kedder commented Feb 18, 2022

Assuming no objections.

@linuxianer99
Copy link
Member

@MaxKellermann ??

@kedder kedder merged commit c9eef25 into Openvario:master Feb 18, 2022
@MaxKellermann
Copy link
Collaborator

@MaxKellermann JobRunningTimeoutSec doesn't work for the same reason as TimeoutSec - the job isn't actually running - it is waiting for dependent job (the device) to finish.

Does this mean the systemd generator is buggy?

@kedder
Copy link
Member Author

kedder commented Feb 18, 2022

Does this mean the systemd generator is buggy?

I don't see why you would imply that.

@MaxKellermann
Copy link
Collaborator

MaxKellermann commented Feb 18, 2022 •
edited
Loading

I don't see why you would imply that.

Because:

The fstab generator translates "x-systemd.device-timeout" ("Configure how long systemd should wait for a device to show up before giving up") to "JobRunningTimeoutSec": https://github.com/systemd/systemd/blob/main/src/shared/generator.c#L281

But I found the answer already: this sets the device's timeout, not the mount's timeout.

So... the proper way of fixing this would be to set JobRunningTimeoutSec in the device unit.

@MaxKellermann MaxKellermann mentioned this pull request Feb 18, 2022
Merged
iglesiasmarianod pushed a commit to iglesiasmarianod/meta-openvario that referenced this pull request Apr 20, 2022
@MaxKellermann @iglesiasmarianod
autofs-config: configure timeout on the device, not on the mount
8f89f66 
This is the proper fix for
Openvario#270 because this is
the way systemd's fstab generator does it; it translates
"x-systemd.device-timeout" ("Configure how long systemd should wait
for a device to show up before giving up") to "JobRunningTimeoutSec"
in the device unit:
 https://github.com/systemd/systemd/blob/main/src/shared/generator.c#L281

The journal now looks like this:

 systemd[1]: usb-usbstick.automount: Got automount request for /usb/usbstick, triggered by 1224 (ls)
 systemd[1]: dev-sda1.device: Job dev-sda1.device/start timed out.
 systemd[1]: Timed out waiting for device USB stick.
 systemd[1]: Dependency failed for Automatically mount connected USB drives.
 systemd[1]: usb-usbstick.mount: Job usb-usbstick.mount/start failed with result 'dependency'.
 systemd[1]: dev-sda1.device: Job dev-sda1.device/start failed with result 'timeout'.

Before, it looked like this:

 systemd[1]: usb-usbstick.automount: Got automount request for /usb/usbstick, triggered by 1320 (ls)
 systemd[1]: usb-usbstick.mount: Job usb-usbstick.mount/start timed out.
 systemd[1]: Timed out mounting Automatically mount connected USB drives.
 systemd[1]: usb-usbstick.mount: Job usb-usbstick.mount/start failed with result 'timeout'.
 systemd[1]: Unnecessary job was removed for /dev/sda1.

Now systemd clearly states that waiting for the USB stick has timed
out, not that mounting it has timed out.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@linuxianer99 linuxianer99 linuxianer99 approved these changes

@MaxKellermann MaxKellermann Awaiting requested review from MaxKellermann

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@kedder @MaxKellermann @linuxianer99