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