[14:14] <sadmac2> Keybuk: good morning
[17:54] <Keybuk> sadmac2: morning
[18:04] <sadmac2> Keybuk: progress continuing steady?
[18:06] <Keybuk> yeah I have rough versions of the major commands (start/stop/emit)
[18:16] <sadmac2> sweet
[18:16] <sadmac2> Keybuk: got bored waiting, so I started writing a web server in C :)
[18:28] <sadmac2> Keybuk: does the job definition format support custom stanzas?
[18:28] <Keybuk> no
[18:28] <sadmac2> for example: X-redhat-boot-icon /usr/share/icons/fubar
[18:28] <Keybuk> would you want to parse the file yourself, or get it via d-bus properties?
[18:29] <sadmac2> Keybuk: the former would suffice, but just putting all stanzas beginning with an X- keyword into a hash available from the dbus object would be nice.
[18:29] <Keybuk> that's doable
[18:33] <sadmac2> sweet
[23:06] <blueyed> Hi. upstart/init crashes on me in an OpenVZ container ("signal 9"), when I save a file in /etc/event.d/. This may be related to the backup file vi creates (or the .pysieved.sw? files laying there). Any idea how I could get a backtrace of this? I'm trying to set this up in another container, because this is on my mailserver container..
[23:07] <Keybuk> it should drop a core in / ?
[23:07] <Keybuk> actually
[23:07] <Keybuk> no it won't
[23:07] <Keybuk> !! 9 ??
[23:08] <blueyed> init: error.c:255: Assertion failed in nih_error_get: CURRENT_CONTEXT->error != NULL
[23:08] <Keybuk> eep.
[23:08] <Keybuk> that should still be signal 6 ;)
[23:09] <blueyed> This is how vim (and the container) crashes when pressing ":wq"+enter:
[23:09] <blueyed> "foo"got signal 9
[23:09] <blueyed>                  exited from VE 12345
[23:09] <blueyed> "foo" being the filename.
[23:09] <Keybuk> ah, vim crashed
[23:09] <Keybuk> is there a /core file?
[23:09] <blueyed> yes..
[23:10] <Keybuk> gdb /sbin/init /core
[23:10] <Keybuk> where
[23:10] <blueyed> mom.. need to setup the new container first with gdb etc
[23:14] <blueyed> I guess I need the dbgsym packages for init?
[23:14] <Keybuk> yup
[23:14] <Keybuk> upstart-dbgsym
[23:16] <blueyed> there you go: http://pastebin.com/m693040b3
[23:16] <Keybuk> upstart 0.3.9 ?
[23:17] <blueyed> 0.3.9-2, yup
[23:17] <blueyed> ubuntu hardy, minimal image, in openvz container
[23:18] <Keybuk> if only gdb could step backwards *sigh*
[23:19] <blueyed> It happens always when changing the file and saving it anew. I'll try to trigger it down to some certain line(s). Currently it's: http://pastebin.com/m55a7424f
[23:24] <Keybuk> err
[23:24] <Keybuk> so, that's basically impossible ;)
[23:25] <Keybuk> can you gdb init while it's running in openvz?
[23:25] <Keybuk> ie gdb -p 1
[23:26] <blueyed> I'll try.. currently the container does not start at all anymore.. I'll look at that core dump and then remove the event file again.
[23:27] <Keybuk> what's happened is it's tried to parse the file
[23:27] <Keybuk> and an error has occurred, causing the function chain to end
[23:27] <Keybuk> but no error is in the stack
[23:27] <Keybuk> I've just been through the code and can't see anything that returns without first raising an error
[23:27] <Keybuk> oops, killed the wrong window
[23:28] <blueyed> Do dot-files and backup file get ignored? (e.g. "foo~" and .foo.swp) - or could that cause a race condition?
[23:29] <Keybuk> yes
[23:29] <Keybuk> they're ignored
[23:32] <blueyed> It failed to start because of an empty file "foo".. had to remove this from outside of the container first..
[23:32] <blueyed> the bt from that crash: http://pastebin.com/m569cc617
[23:33] <blueyed> Attaching to process 1
[23:33] <blueyed> ptrace: Operation not permitted.
[23:33] <blueyed> ..does not seem to work?
[23:36] <Keybuk> no, was hoping openvz might let that happen ;)
[23:37] <Keybuk> would you be able to rebuild the source to upstart inside the openvz?
[23:37] <blueyed> yes
[23:37] <blueyed> without any patches?
[23:37] <Keybuk> apt-get source upstart
[23:37] <Keybuk> apt-get build-dep upstart
[23:38] <Keybuk> then cd into the upstart directory and _EDIT_ init/main.c
[23:38] <Keybuk> comment out (I tend to use #if 0 ... #endif around them) the following lines
[23:39] <Keybuk> prototypes for all handlers (65-70)
[23:39] <Keybuk> the pid 1 check (140-147)
[23:39] <Keybuk> the log redirection (178-179)
[23:40] <Keybuk> the console fu (185-191)
[23:40] <Keybuk> signal setup for handlers (213-239)
[23:40] <Keybuk> the startup event (283)
[23:41] <Keybuk> also comment out the handler functions themselves (353-567/eof)
[23:41] <Keybuk> -- 
[23:41] <Keybuk> that'll give you a version of upstart you can run as an ordinary process ;)
[23:42] <Keybuk> then build with debian/rules build
[23:42] <blueyed> "signal setup for handlers (213-239)"?`all nih_signal_set_* lines there? (line numbers do not seem to match)
[23:45] <Keybuk> not all of them
[23:46] <Keybuk> the ones that set a local handler
[23:46] <Keybuk> the ones that set nih_signal_handler have to remain
[23:46] <Keybuk> they cause the main loop to iterate
[23:51] <blueyed> ok. Built, 3/17 tests failed.. which might be expected, but I'm trying a clean build, too.
[23:52] <blueyed> What should I do with the stripped version now?
[23:52] <blueyed> clean version also fails with 3 tests..!
[23:55] <Keybuk> I'll worry about the tests later ;)
[23:55] <Keybuk> ok
[23:55] <Keybuk> just run it ./src/init
[23:55] <Keybuk> oh
[23:55] <Keybuk> just run it ./src/init --debug
[23:55] <Keybuk> the --debug helps ;)
[23:55] <Keybuk> you'll get output on the terminal
[23:55] <Keybuk> (as root, obviously)
[23:57] <blueyed> ok. then try to recreate the crash? (it's ./init/init btw)
[23:57] <Keybuk> yup
[23:57] <Keybuk> oh, yes ;)
[23:58] <blueyed> well, now the container is gone.. I should have redirected the debug output probably?
[23:59] <blueyed> ..and I shouldn't have built/modified it in /tmp.. :/