| Summary: | Deadlock on shutdown due to triggered automount unit | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Andrei Borzenkov <arvidjaar> |
| Component: | general | Assignee: | Lennart Poettering <lennart> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | hp4everything |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Console log of current GIT | ||
|
Description
Andrei Borzenkov
2011-01-24 10:52:10 UTC
Hmm, so adding this to shutdown.target is not really the right solution, the mount and automount points are pulled down by umount.target, not shutdown.target. So, the easy fix is to just get rid of that ALSA script. The systemd support that is now in alsa-utils upstream is everything needed to make ALSA work nicely. All that crap of iterating through /dev or /proc is a recipe to slow things down and make things ugly. It will trigger all automount points for no reason. That said we probably should fix systemd so that this deadlock becomes impossible. Most likely this is simply an ordering problem: the alsa shutdown script waits for the /dev/mqueue fs, which however is ordered to run after the alsa shutdown script. A possible fix might be to fail the triggering of an automount unit if a shutdown request for it is queued. That should be easy to do. Hmm, I made some changes to systemd git now, to be more verbose about when automount is triggered during shutdown. THere's now a debug log msg printed if ths happens when we go down. Could you install systemd git and generate me an outout like the one you already generated but with "systemd.log_level=debug" and "systemd.log_target=kmsg" on the kernel command line? This should give us enough information to figure out the real reason for the deadlock. Created attachment 42545 [details]
Console log of current GIT
See attached. Your debug output does not fire. Actually /dev/mqueue is happily mounted ... it just happens shortly before power off :)
3 minutes timeout is there
systemd[1]: alsa.service stopping timed out. Terminating.
systemd[1]: alsa.service changed stop -> stop-sigterm
The reason for deadlock is local-fs.target dependency implicitly added to every mount unit. Before=local-fs.target After=dev-mqueue.automount -.mount local-fs.target is being stopped on shutdown due to dependency on shutdown.target: systemd[1]: Installed new job poweroff.target/start as 112 systemd[1]: Installed new job poweroff.service/start as 113 systemd[1]: Installed new job shutdown.target/start as 114 systemd[1]: Installed new job systemd-update-utmp-shutdown.service/start as 115 systemd[1]: Installed new job local-fs.target/stop as 195 ... When later mount request for /dev/mqueue comes, dev-mqueue.mount waits for local-fs.target to be stopped according to rules: systemd[1]: Trying to enqueue job dev-mqueue.mount/start/replace systemd[1]: Installed new job dev-mqueue.mount/start as 216 systemd[1]: Enqueued job dev-mqueue.mount/start as 216 But local-fs.target can be stopped only after all services are stopped due to (start) ordering: local-fs.target => sysinit.target => basic.target => foo.service So this is typical A - B - C - A deadlock. local-fs.target (implicitly) waits for alsa.service, alsa.service (implicitly) waits for dev-mqueue.mount and dev-mqueue.mount waits for local-fs.target. This is second deadlock encountered due to implicit ordering rules (and one more was reported but not investigated due to lack of debugging information). This has been fixed a long time ago, we don't permit triggering of autofs anymore during shutdown. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.