Summary: | A hanging shell process remains after exiting rescue mode with suggested `systemctl default' | ||
---|---|---|---|
Product: | systemd | Reporter: | Алексей Шилин <rootlexx> |
Component: | general | Assignee: | systemd-bugs |
Status: | NEW --- | QA Contact: | systemd-bugs |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Interactive shell bash (618) strace output
The proposed patch to fix the rescue shell hangup issue |
Description
Алексей Шилин
2015-05-31 14:28:54 UTC
I've tested the ExecStopPost= solution, and it worked flawlessly, hence the proposed patch (which fixes emergency.service as well). (In fact, I like this solution better: * it makes the interactive shell process the main one (which makes sense); * it gets rid of unnecessary inline scripts (the /bin/sh -c stuff); * it works when the original one doesn't, like if one manually stops rescue.service from the rescue shell itself (which is stupid, but still).) Created attachment 116203 [details] [review] The proposed patch to fix the rescue shell hangup issue Unfortunately, I have discovered, that the proposed solution leads to an unwanted side effect: if one runs, say, `systemctl isolate multi-user.target' from the rescue shell, it will still lead to default.target isolation; same happens if one tries to switch from rescue mode to emergency mode or vice-versa with `systemctl rescue' or `systemctl emergency'. (`systemctl reboot' and `systemctl poweroff' work as expected.) So, it seems, some other solution needs to be invented. |
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.