| Summary: | RFE: more informative mount report upon failure or issue | ||
|---|---|---|---|
| Product: | systemd | Reporter: | ivo welch <ivo.welch> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | NEW --- | QA Contact: | systemd-bugs |
| Severity: | enhancement | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
ivo welch
2015-01-01 06:33:33 UTC
We can't really add a message here, but I think that a good catalogue entry (that would be printed by journalctl -x) would be helpful. I Googled for forum threads matching the error message to see how it behaved in the wild. As ivo thought, most (but not all) of the cases were mount errors. Another issue was people not being able to figure out what unit is actually having the issue as a result of badly written "Description=" tags. (For this would it be possible to have the error message explicitly include the unit name, e.g., "A start job is running for Incredibly Bad Description (foo.service) (89s / 90s)"?) See below for a proposed catalog entry: -- 48b695296b4d42fe8c127c20d01bc9bc Subject: A @TYPE@ job is running for @UNIT@ (@TIME@ / @LIMIT@) Defined-By: systemd Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel Something has delayed the start or stop job for a unit with the description "@UNIT". You will need to debug that unit to see why. @TIME@ of a total timeout of @LIMIT@ have elapsed. If you would like to shorten the timeout in future, you can edit the "TimeoutStartSec=" or "TimeoutStopSec" properties. A common situation is the delay in mounting a filesystem's *.device unit, which is typically caused by problems in "/etc/fstab". thank you for taking my suggestion seriously, whatever you end up deciding. my last 5 cents: as I wrote, most boot problems that newbies are experiencing with systemd (i.e., after the initrd was found and loaded) are /etc/fstab misconfig related. anything we can do to be smart about it (for users who are not), even if this just means giving precise fixing instructions, would be good. we can diagnose this better with our expertise than our newbies can with their's. the harm that is being done to expert users by more smarts here is minimal. the coding effort for some diagnoses and fixing suggestions is probably reasonable. (if we needed a standalone perl script, even I as a novice who is ignorant of systemd procedures and collaborative code development, could do this in a day.) socially speaking, the net time savings will be very positive. (In reply to Chris Atkinson from comment #2) for a proposed catalog entry: > > -- 48b695296b4d42fe8c127c20d01bc9bc > Subject: A @TYPE@ job is running for @UNIT@ (@TIME@ / @LIMIT@) > Defined-By: systemd > Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > Something has delayed the start or stop job for a unit with the description @TYPE@ here? > "@UNIT". You will need to debug that unit to see why. @TIME@ of a total > timeout of @LIMIT@ have elapsed. > If you would like to shorten the timeout > in future, you can edit the "TimeoutStartSec=" or "TimeoutStopSec" > properties. I don't think we should suggest that. > A common situation is the delay in mounting a filesystem's *.device unit, > which is typically caused by problems in "/etc/fstab". Add "You can list the dependencies with systemctl list-dependencies @UNIT@ "? Can you make this into a patch? |
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.