[00:03] you lost the container? [00:03] ahh, the running init died? [00:03] yes. but patched and build again. what to do? [00:03] hmm [00:03] we need a way for you to be able to crash that one, without losing the container you're doing it in [00:04] one way would be to do something like [00:04] well.. I see what gets displayed until the crash.. [00:05] ok [00:05] so try that [00:05] cfg_create_modify_handler: foo job definition changed [00:05] cfg_read_job: Loading foo from /etc/event.d/foo [00:05] init:error.c:255: Assertion failed in nih_error_get: CURRENT_CONTEXT->error != NULL [00:05] Aborted [00:05] got signal 9 [00:05] exited from VE 12345 [00:05] did the debug version crash? [00:07] how can I be sure? from the core file? [00:07] from the debug output [00:07] it should also asset [00:07] assert [00:07] what I've pasted.. [00:07] we need the container now to crash [00:07] not to crash [00:07] rm /sbin/init [00:07] cp /bin/bash /sbin/init [00:07] and boot the container that way [00:11] well.. it does not start that way.. "init: Failed to open console: Permission denied" isn't a problem, is it? [00:11] ..just stops after ~1 sec again, cannot enter [00:11] sorry? [00:11] I don't understand [00:11] what does not start what way? [00:11] the container, with bash as init. [00:12] oh [00:12] no idea [00:12] I don't know openvz [00:12] but you need to be running _something_ as /sbin/init that isn't Upstart [00:12] since otherwise every time you trigger the crash, you'll lose the container [00:12] and since I want you to run gdb inside the container while triggering the crash, that won't help ;) [00:22] busybox does not work either. But "minit" does.. :) [00:23] heh [00:23] as long as you have something [00:23] once in, start the debug upstart with --debug [00:23] (no need to redirect now) [00:23] and try and trigger the crash [00:23] you should get an assert in its output [00:24] "Assertion failed in nih_error_get: CURRENT_CONTEXT->error != NULL", then "Aborted" on a single line [00:25] excellent [00:25] I have it started now in gdb.. with "--debug". [00:25] ok [00:25] and does it crash in gdb too? [00:26] it crashed right away, when the empty file was not there.. I'll touch it again. [00:26] no, does not crash now..?! I've done "gdb ./init/init", then "run --debug". [00:27] ? [00:27] it works under gdb? [00:27] what about under stract [00:27] strace ./init/init --debug [00:27] no.. Had done "rm" instead of "touch", sry. [00:28] crashes in the gdb session after touching the file, too. [00:28] oh good [00:28] ok, so the next bit is to find out which of the parsing functions is exiting [00:29] this isn't quite easy [00:29] do you want access on that machine btw? :) [00:29] if you can give me access, that would be a lot quicker, yeah :p [00:36] if not, we can step through by hand [01:50] sadmac2: great! [13:59] hi [14:01] hey [14:11] are there examples of handling a failed emit? [14:13] you know of failure in two ways [14:13] I have a jobs that itself calls "stop an_other_job" (the last one fails and apparently also the "stop" command itself return false [14:13] the "emit" command will return a non-zero value [14:14] _and_ a "/failed" event will also be emitted [14:14] is that what you mean? [14:15] or do you mean failed start and/or stop commands? [14:15] I think I already answerd my own question [14:16] Keybuk: what is failing is a post-stop script [14:17] right [14:17] then the stop command will return non-zero [14:17] for the job "foo" (that calls the failing stop command) you'll also have the following event: [14:17] stopped foo RESULT=failed PROCESS=post-stop EXIT_STATUS=... [14:19] but I can "if stop my_job ; then you failed ; done" right? [14:19] right [14:20] any upstart people going to linuxtag btw? [14:20] thanks [14:22] I wasn't planning to [14:23] it is far away for you :p [14:30] not so much that [14:31] everyone has the conferences that they go to [14:31] mine happen to be GUADEC and if I can, LCA [14:31] I've never been to FOSDEM or LinuxTag which seem to be another common set [14:31] it's not that I don't want to, just that I never know when they are, and it's too late by the time someone tells me :) [14:31] :p [17:28] * Keybuk starts bricking his new MP3 player [17:35] hurrah, success [17:35] I now have a USB mass storage-capable OGG player ;) [18:14] rockbox? [18:29] upstart enabled mp3 player? [18:36] Jc2k: heh, no, just the Korean firmware for the player [18:36] Samsung are strange like that [18:36] Europeans get RDS support for the radio [18:36] Koreans get OGG and UMS support [21:47] Keybuk: how are things progressing? [21:48] anyone would think you were in a hurry [21:48] Hyperactive. Too much television as a kid. [21:52] lol [21:53] Keybuk: well if you consider that, essentially, I'm now paid full time to work on Upstart, and that there's not much for me to do until 0.5 comes out, basically Red Hat pays me to annoy you 40 hours a week. [21:55] which I like :) [21:57] Keybuk: in the process of writing that web server I mentioned, I got sidetracked on some error handling code and ended up implementing lisp-style signal handling in C. [21:57] Could libnih profit from this? [21:58] what's lisp-style signal handling? [21:59] Keybuk: its kind of like exceptions. [21:59] example? [22:00] lemme cook one up.... [22:36] http://paste.ubuntu.com/12129/ [22:37] sweet [22:46] hmm. crap. [22:47] something suddenly stopped working :) [22:47] hrh [22:52] ahh. I think I figured it out. [22:52] fun with setjmp :) [22:59] Hi there [22:59] xsun: hi [23:00] Anyone knows where I can find Scott here? [23:00] that's me [23:01] Hey Scott, can I pvt you? [23:01] sure, what's uo? [23:01] up [23:03] Keybuk: DCC sending ok by you? [23:03] sure [23:04] Keybuk: sending [23:05] can't seem to connect to you [23:05] Keybuk: email then [23:05] scott@netsplit.com :-) [23:06] Keybuk: you have it [23:08] ah, you're using lngjmp [23:09] Keybuk: only way to do it. [23:09] modulo inline asm [23:09] dpkg does something very similar to this [23:09] you push cleanup handlers [23:09] and errors are raised by lngjmp, which will replay any cleanup handlers [23:11] there's a bit more to this one. There are 3 namespaces for signals. USER (ones you make up for your app) ERROR (allows you to directly throw ENOMEM and the like as errors) and UNIX (literal signals like SIGSEGV) [23:12] you can treat them similarly (the last category might get me into trouble, still investigating it) [23:13] if only C had closures [23:13] Keybuk: GCC has function nesting, which gets you mostly there. [23:13] if only the rest of C had them. [23:22] yeah, but you can't return pointers to them :) [23:22] true. [23:22] You can pass them downward. [23:29] I need to go home