Comment 251 for bug 554172
Revision history for this message
| Scott James Remnant (Canonical) (canonical-scott) wrote Re: system services not starting at boot | #251 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
More robust, how?
If the job is configured to require its standard three file descriptors to the system console, and Upstart is unable to open the system console, it is unable to satisfy the requirements of the job configuration so will terminate the attempt to start the job.
Read through the entire job_process_spawn() function and you'll see that the code is already safe from EINTR due to the signal disposition, and all other permissible error returns from open() are non-transient.
open(2) does not document EIO as a valid return from this function, and I'm not even sure this error is appropriate - where it's used elsewhere it nearly always refers to a filesystem error - there are few exceptions. If the intent is that the calling process should just try again, shouldn't it instead return EAGAIN?
Also please bear in mind that "should" implies that it should somehow have been anticipated that the kernel was going to change an interface and introduce an undocumented non-transient error code where none existed before? :-)