Found the dbus problem I had. Using strace I saw that the dbus client (initctl) was sending an authentication request to the dbus daemon, which the daemon rejected. The /etc/passwd file was in a bad state, which is why the daemon was rejecting.
Another question: is there any API I could use to programmatically get the list of upstart-managed jobs and their state? Right now I'm doing fork/exec on initctl and parsing the output. Wondering if there was a cleaner way. Thanks! -- Marcel Kinard import com.ibm.marcelk.Disclaimer; ----- Forwarded by Marcel Kinard/Raleigh/IBM on 10/28/2010 12:43 PM ----- From: Marcel Kinard/Raleigh/i...@ibmus To: [email protected] Date: 10/26/2010 11:37 PM Subject: dbus problem? Sent by: [email protected] I'm using upstart 0.6.5 in an embedded system. After working great for quite a while, today initctl started failing with "initctl: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." I can invoke initctl from a shell prompt and this error message gets returned to me immediately, there doesn't seem to be a pause at all indicative of a timeout. I'm feeling like this is a problem with dbus, since this message exists in libdbus and dbus-daemon. This is consistent behavior, all invocations of initctl are failing this way. Without tearing into the dbus source code, are there any hints as to what I should be looking for? -- Marcel Kinard import com.ibm.marcelk.Disclaimer;-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
