[00:15] Why does my Node server silently fail when daemonized with Upstart? https://github.com/mcandre/node-ios7crypt/blob/master/upstart.conf [00:36] Hey friends [00:43] Ah, it was a problem with relative paths in the Node.js code [00:49] I'm having problems with node.js and upstart as well.... [00:49] I can get it to start but I cannot get it to run on restart [02:53] does anyone have any experience running node processes via upstart? [02:53] works manually start and stop [10:41] jodh: i'm trying to fix the test-suite after adding correct pipe shrinkage and preventing close handler from double freeing the io [10:42] jodh: however i'm noticing very odd things. [10:42] jodh: for example: exec of a main process "/this/command/does/not/exist" in the child handler raises status 255, 13, 1 (in order of decreasing frequency) [10:43] am i receiving and catching some unrelated events and some such? [10:43] * xnox ponders if i should only monitor chld exited.... [10:48] xnox: are you only running that specific test? If not, I'd comment the rest out. Also, where's the latest branch? :-) [10:49] jodh: just locally at the moment. let me push it. [10:51] jodh: hm, in the child handler Is it actual exit status, or does one need to call WEXITSTATUS on it?! [10:54] xnox: yeah, you will if the child exited normally. Look at NihChildHandler in nih/child.h which documents exactly what status means (depends on NihChildEvents). [11:00] jodh: https://code.launchpad.net/~xnox/upstart/shrink-notifications just the top level commit on top of lp:upstart [11:00] xnox: ta [11:01] test suite hangs at the moment. E.g. after exiting the mainloop, the log is not written / flushed for not ok 49 - with single-line command running an invalid command, then a 2-line post-stop script [11:01] wrong value for stat (filename, &statbuf), expected 0 got -1 [11:01] at tests/test_job_process.c:3270 (test_start). [11:01] not ok 49 - with single-line command running an invalid command, then a 2-line post-stop script [11:01] wrong value for stat (filename, &statbuf), expected 0 got -1 [11:01] at tests/test_job_process.c:3270 (test_start). [11:01] in the test_job_process [11:02] jodh: i'm trying to use the minimalistically simple main-loop exitor, out of all the editions i could find. Or is/was there branch and or commits from you where those tests were already adjusted to use main-loop without a lot of debug nih message codes? [11:03] when i went looking through your branches again, i didn't find such. [12:19] xnox: lp:~jamesodhunt/upstart/async-spawn.WIP is the latest wrt main loop tests. [13:28] xnox: I'd be tempted to pull in more of my test_job_process.c changes (I'm thinking of TEST_RESET_MAIN_LOOP() specifically so that you know each test will get a clean env). [13:30] jodh: yeah, working on disecting that now, given that it does pass further than my current shrinkage branch [13:30] xnox: ack. [15:30] Is there a way to see what jobs upstarts *thinks* is running? I'm trying to work out why on Ubuntu 14.04 'service udevtrigger start' (which is a task) says that the job is already running [15:31] alexbligh1: $ sudo initctl list ? [15:32] xnox, that's what I was missing, thanks. What does it mean if a task is "udevtrigger start/starting" [15:33] Surely a task, by the nature of a task, should be short lived? [15:33] (and no it's not doing anything) [15:34] alexbligh1: start/starting means the "start on" conditions are satisfied, however there are other jobs that are blocking udevtrigger from running. [15:35] alexbligh1: e.g. jobs that are "start on starting udevtrigger" that are blocking [15:36] alexbligh1: udevtrigger is typically run only once very early in the boot, and one wouldn't need to add any other custom jobs there. [15:36] alexbligh1: can you pastebin $ sudo initctl show-config ? [15:36] xnox, yeah I am having an issue where on my debootstrapped trusty, /dev/net/tun is not being created [15:37] xnox, initctl show-config : http://pastebin.com/pQdSCmYn [15:38] xnox, initctl list : http://pastebin.com/AAthU77A [15:39] xnox, the only thing "start on starting udevtrigger" I can see is udev-monitor, and that is start/running [18:22] xnox, I think I've found the problem. trusty udev is unhappy if /dev is not devtmpfs, but just a normal directory in my (ram) root filingsystem. Is that intentional? It's bizarrely difficult to work around as you can't mount both /dev and /dev/pts from /etc/fstab as no directory /dev/pts exists to mount on in devfs.