sadmac2 | Keybuk: good morning | 14:14 |
---|---|---|
Keybuk | sadmac2: morning | 17:54 |
sadmac2 | Keybuk: progress continuing steady? | 18:04 |
Keybuk | yeah I have rough versions of the major commands (start/stop/emit) | 18:06 |
sadmac2 | sweet | 18:16 |
sadmac2 | Keybuk: got bored waiting, so I started writing a web server in C :) | 18:16 |
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:28 |
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:29 |
sadmac2 | sweet | 18:33 |
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:06 |
Keybuk | it should drop a core in / ? | 23:07 |
Keybuk | actually | 23:07 |
Keybuk | no it won't | 23:07 |
Keybuk | !! 9 ?? | 23:07 |
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:08 |
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:09 |
Keybuk | gdb /sbin/init /core | 23:10 |
Keybuk | where | 23:10 |
blueyed | mom.. need to setup the new container first with gdb etc | 23:10 |
blueyed | I guess I need the dbgsym packages for init? | 23:14 |
Keybuk | yup | 23:14 |
Keybuk | upstart-dbgsym | 23:14 |
blueyed | there you go: http://pastebin.com/m693040b3 | 23:16 |
Keybuk | upstart 0.3.9 ? | 23:16 |
blueyed | 0.3.9-2, yup | 23:17 |
blueyed | ubuntu hardy, minimal image, in openvz container | 23:17 |
Keybuk | if only gdb could step backwards *sigh* | 23:18 |
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:19 |
Keybuk | err | 23:24 |
Keybuk | so, that's basically impossible ;) | 23:24 |
Keybuk | can you gdb init while it's running in openvz? | 23:25 |
Keybuk | ie gdb -p 1 | 23:25 |
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:26 |
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:27 |
blueyed | Do dot-files and backup file get ignored? (e.g. "foo~" and .foo.swp) - or could that cause a race condition? | 23:28 |
Keybuk | yes | 23:29 |
Keybuk | they're ignored | 23:29 |
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:32 |
blueyed | Attaching to process 1 | 23:33 |
blueyed | ptrace: Operation not permitted. | 23:33 |
blueyed | ..does not seem to work? | 23:33 |
Keybuk | no, was hoping openvz might let that happen ;) | 23:36 |
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:37 |
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:38 |
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:39 |
Keybuk | the console fu (185-191) | 23:40 |
Keybuk | signal setup for handlers (213-239) | 23:40 |
Keybuk | the startup event (283) | 23:40 |
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:41 |
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:42 |
Keybuk | not all of them | 23:45 |
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:46 |
blueyed | ok. Built, 3/17 tests failed.. which might be expected, but I'm trying a clean build, too. | 23:51 |
blueyed | What should I do with the stripped version now? | 23:52 |
blueyed | clean version also fails with 3 tests..! | 23:52 |
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:55 |
blueyed | ok. then try to recreate the crash? (it's ./init/init btw) | 23:57 |
Keybuk | yup | 23:57 |
Keybuk | oh, yes ;) | 23:57 |
blueyed | well, now the container is gone.. I should have redirected the debug output probably? | 23:58 |
blueyed | ..and I shouldn't have built/modified it in /tmp.. :/ | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!