[02:05] Keybuk: what do you have in mind? [04:21] Does the pid of the process get sent to post-start in any manner? [08:17] Hi [08:17] I finished my state machine thingy. [08:18] I now need to send event from within the kernel. it that possible? [08:45] sadmac: "status" will give it to you [13:09] re [13:09] I have two more interesting questions :P [13:11] it looks like when I perform an emit from one jobs it waits for the emit to be processesd before it returns [13:12] is there a way around this? (my job does a pivot_root) [13:23] hmm --no-wait helps [14:32] keesj: right, you found it ;) --no-wait [14:32] also make sure the job is configured right [14:32] if the emit is waiting for the job to stop again, and it's a daemon, you need either "service" or "respawn" in the job [14:32] then emit will only wait until it's started [15:55] Keybuk: so... logd... how do we replace it? [16:03] define what we want ;) [16:03] for me the main thing is to be able to capture output from jobs [16:03] and have that logged and not lost [16:03] (even if filesystem not mounted) [16:04] and maybe even mail that (cron-like) [16:11] what would service do? [16:15] Keybuk: pushing it into syslog would do most of that. [16:18] cool, after a pivot root and a kill 1 it sill works (init apparently reloaded from a different partition) [16:19] sadmac_: indeed [16:20] Keybuk: so the issue is: how do we attach a reliable file descriptor to processes and how do we get the input from there to syslog [17:11] sadmac_: right [17:11] and e.g. how does upstart tell the logging daemon that the output of a particular job should be e-mailed out [17:11] (since the job failed) === phoenix24_ is now known as phoenix24 [18:14] Keybuk: I'd assume upstart would have pipes open to the programs being logged, and simply stuff the output to syslog [18:15] that means init has to do quite a bit of work for every process running though, no? [18:16] Keybuk: is there a way to open a socket direct to syslog? [18:17] Keybuk: if we want to keep an external daemon, using ptys for each bothers me less and less. [18:19] yeah, the problem then is when that logging daemon dies [18:20] strange things happen to shell scripts [18:20] Ahh, yeah, if you loose the master fd the pty still drops [18:21] I know what kind of IO we need, and I can write a kernel module to support it, but I don't like the idea of pushing that upstream :( [18:22] hehe, indeed [18:23] That's what I need to do, find some kernel devs. There's got to be a mechanism for this. [18:23] there probably is already [18:23] I just haven't read the relevant section of Stevens yet [18:23] logd is quite low on my priority list right now [18:24] the existing one "works" for people that want it [18:24] Keybuk: which book is Stevens? [18:25] any of his [18:25] his Unix Network Programming series will have the likely answer [18:25] since that covers all types of sockets, file descriptors and IPC [18:25] ahh, that one [18:31] Keybuk: I've got it :) [18:32] Keybuk: Pipe it to a file in /dev/shm [18:32] the book? [18:32] /dev/shm isn't mounted when init starts [18:33] It could be. For us at least [18:34] Hmm, and it turns out it doesn't spool the way I had hoped [18:35] some kind of shared ring buffer would be ideal [18:36] so the app could output freely [18:36] and a logging daemon could pick it up and read from it [18:36] but if it didn't, that wouldn't be bad [18:36] exactly [18:36] in fact what we need is very nearly the example from the linux device drivers book. [18:54] heh [18:54] * sadmac_ looks at list of known major numbers in linux kernel [18:58] right, back tomorrow [18:58] * Keybuk heads to london [18:58] damn. he left === elmarco|bzz is now known as elmarco === Amaranth_ is now known as Amaranth