+++ This bug was initially created as a clone of Bug #734268 +++ <lots snipped> --- Additional comment from mingo on 2011-11-10 13:32:17 EST --- <more snipped> 3) 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*? Also, the output is pretty meaningless because it's not structured, unless you really are experienced in systemctl output (which most of the people are not): Active: failed since Thu, 10 Nov 2011 07:32:09 +0100; 3min 8s ago Process: 5078 ExecStart=/etc/rc.d/rc.local start (code=exited, status=203/EXEC) 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()? would have led me to the problem straight away. The fact remains, i spent more than half an hour on something that should have been far more obvious to analyse at first sight. I only solved it because i straced the systemctl command, strace -s 100000 it once again to see all the message, saw the writes() to the socket resulting in a failure being passed back, then identified where the pipe was openened, realized that it was used by PID 1, then straced PID 1 and also looked at the systemd source code and man page while doing this. If i have trouble with that and have to go to such lengths to figure out a pretty common failure then what will the typical sysadmin experience? ... Another option might be replacing EXEC/-ENOEXEC with the translated perror() string.
(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.