Bug 752901
| Summary: | RFE: clearer error messages | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bill Nottingham <notting> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | amcnabb, fedora.qc, gaurierben, iarlyy, johannbg, jonathan, lpoetter, metherid, mingo, mschmidt, notting, plautrba, rvokal, shpnft, systemd-maint |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-37-11.fc16 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 734268 | Environment: | |
| Last Closed: | 2012-01-30 20:59:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bill Nottingham
2011-11-10 18:41:46 UTC
(In reply to comment #0) > I missed the 203/EXEC bit because it wasn't a familiar pattern (i mistakenly > thought that it simply means that things were attempted to be executed) - would > it be possible to prefix that output with -ENO, resulting in -ENOEXEC or so, > signalling that it's a *failure*? If systemctl runs on a tty, then the word "failed" and the text "(code=exited, status=203/EXEC)" are printed in red to signal a failure. The "203" is the exit status of a process. It is not an errno number, so calling it "ENOEXEC" would be very confusing. We do not store the errno of the execve() call anywhere. We just know that the call failed for whatever reason and this is what the systemd-reserved exit code "203/EXEC" means. > Something like this: > > Active: failed since Thu, 10 Nov 2011 07:32:09 +0100; 3min 8s ago > Process: 5078 ExecStart=/etc/rc.d/rc.local start exited abnormally with > status 203/-ENOEXEC - file not executable via exec()? Yes, we can easily add human-readable descriptions of the systemd-reserved exit codes to systemctl. Is there a reason we lose the errno that can't be fixed? It is fixable. We could: - log the errors from the forked process "sd(EXEC)". We just need to reopen the log fd, because we close all fds before we execve() the real service. That's easy to do. - communicate the errors from "sd(EXEC)" to systemd using the notify socket. This way we would not even need to have the reserved range of exit codes. Both methods may fail if the service is configured to run in a weird namespace, but such cases are rare. This is now improved a little in upstream: http://cgit.freedesktop.org/systemd/commit/?id=4c2630ebf23b6348174f0bdf1110e90efe45259c systemctl status still shows the same information, but in kmsg/syslog there will be a message: [ 12.933713] systemd[779]: Failed at step EXEC spawning /etc/rc.d/rc.local: Exec format error systemd-37-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-37-6.fc16 Package systemd-37-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-6.fc16 then log in and leave karma (feedback). Package systemd-37-7.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-7.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-7.fc16 then log in and leave karma (feedback). Package systemd-37-8.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-8.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-8.fc16 then log in and leave karma (feedback). Package systemd-37-10.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-10.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-10.fc16 then log in and leave karma (feedback). Package systemd-37-11.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-11.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-11.fc16 then log in and leave karma (feedback). systemd-37-11.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |