[17:46] does "initctl" run only a job (/etc/init/*.conf file), right ? [17:47] fex.: initctl stop xsession/conndlgs [21:27] hi Keybuk [21:27] what is up [21:27] hey [21:28] I missed the shuttle to work this morning, fail [21:28] there is also a day tomorrow =) [21:28] meego dropped the upstart iirc (Intel) [21:29] unexpected turn. [21:29] yeah, I spoke with Arjan about that a year ago [21:29] was entirely expected for me [21:29] haha xD [21:29] of course, Nokia dropped meego, so it's kinda irrelevant ;) [21:30] * djszapi has never understood the goal of the meego project, maemo has just worked fine... [21:30] maemo and meego are the same project [21:30] not really, no. [21:31] we still use upstart in maemo 6. [21:31] yeah, it's just the merging of maemo and mobiln [21:31] yeah in the dream worlds :) [21:32] from what I can say is that thingy, the maemo and meego security is completely different, no shared bit... [21:32] also, meego -> qml, maemo -> libmeegotouch etc. [21:32] sure [21:32] the point is that I am happy with maemo, I do not think there was a business reason for meego [21:33] the business reason was to have insurance [21:33] there might not have been an engineering reason [21:34] but engineering reasons and business reasons rarely coincide [21:34] insurance can be bought somewhere else :p [21:35] what kind of insurance, btw ? [21:36] < ion> Last night i dreamed walking along a path. I saw the code “class Burn a where burn :: a → a”. Then i saw the code “instance Burn Human” and people in various stages of dying (with a grotesque horror movie -style appearance) were walking on the path. Everyone of them was smoldering and coughing black smoke. [21:36] Keybuk: and how do you enjoy the US, btw ? :) [22:46] insurance, I mean Nokia poured a massive amount of money into maemo on their own [22:46] they needed partners to bear the burden of it [22:51] I'm having a problem where stop/start is hanging for an upstart job (libvirt-bin) on ubuntu [22:51] using strace, I can see that the /com/ubuntu/upstart is connected to [22:52] * the domain socket with path [22:52] is stop/start hanging or blocking? [22:53] its blocking on poll [22:54] which is only polling on the socket [22:55] it does an AUTH EXTERNAL and gets a response, then does BEGIN and writes what is probably some binary data [22:57] looks like that binary data is probably a GetJobByName call, and gets a response, then sends a Start, where it blocks on poll [22:57] is there some way to get logs for upstart? [23:01] sure, initctl log-priority info [23:01] and read syslog [23:01] so right, start/stop are just blocking [23:01] this means that libvirt-bin isn't ever in running or waiting [23:06] Keybuk: so possibly the libvirt script is doing something where its not completing? [23:08] is there a way to restart the upstart/init process? [23:12] crass: is this only happening on libvirt for you? [23:12] I'm having pretty similar behavior for pretty much everything on my vserver guest [23:12] actually, its now happening for upstart-udev-bridge, which I thought was the problem originally so I mucked with it and now it has the same behavior [23:13] like, I can't even restart cron [23:13] (as a very simple example) [23:13] I'm wondering if the internal state of upstart is messed up and needs to be restarted [23:14] radix: yeah upstart-udev-bridge stopped, started, stopped and now won't start, though I can manually start it [23:17] hmm, maybe the cause is because of the "expect daemon" [23:18] I modified the job to not daemonize, but left that, and now I've modified it back, but that didn't fix it [23:18] maybe its still waiting on the original process to fork again? though it should be dead [23:26] yes, that's likely [23:27] Keybuk: should "kill -9 1" restart upstart? [23:27] no [23:27] is there any way to restart upstart without rebooting? [23:27] no [23:28] is that a limitation of the kernel init process? [23:48] no, a limitation of upstart [23:48] though if it did support restarting, it would be restarting-with-state [23:48] which is what you think is broken ;) [23:49] so the restarted copy would have the same state as the old one