| djszapi | does "initctl" run only a job (/etc/init/*.conf file), right ? | 17:46 |
|---|---|---|
| djszapi | fex.: initctl stop xsession/conndlgs | 17:47 |
| djszapi | hi Keybuk | 21:27 |
| djszapi | what is up | 21:27 |
| Keybuk | hey | 21:27 |
| 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:28 |
| 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:29 |
| * 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:30 |
| 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:31 |
| 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:32 |
| Keybuk | the business reason was to have insurance | 21:33 |
| Keybuk | there might not have been an engineering reason | 21:33 |
| Keybuk | but engineering reasons and business reasons rarely coincide | 21:34 |
| djszapi | insurance can be bought somewhere else :p | 21:34 |
| djszapi | what kind of insurance, btw ? | 21:35 |
| 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 ? :) | 21:36 |
| 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:46 |
| 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:51 |
| crass | * the domain socket with path | 22:52 |
| Keybuk | is stop/start hanging or blocking? | 22:52 |
| crass | its blocking on poll | 22:53 |
| crass | which is only polling on the socket | 22:54 |
| crass | it does an AUTH EXTERNAL and gets a response, then does BEGIN and writes what is probably some binary data | 22:55 |
| 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? | 22:57 |
| 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:01 |
| crass | Keybuk: so possibly the libvirt script is doing something where its not completing? | 23:06 |
| crass | is there a way to restart the upstart/init process? | 23:08 |
| 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:12 |
| 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:13 |
| crass | radix: yeah upstart-udev-bridge stopped, started, stopped and now won't start, though I can manually start it | 23:14 |
| crass | hmm, maybe the cause is because of the "expect daemon" | 23:17 |
| 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:18 |
| Keybuk | yes, that's likely | 23:26 |
| 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:27 |
| crass | is that a limitation of the kernel init process? | 23:28 |
| 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:48 |
| Keybuk | so the restarted copy would have the same state as the old one | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!