[04:28] <lolzadam> JanC:  yes, but I couldn't find a -2 so i assumed. Any clue what -2 is then?
[04:54] <cypherpunks> Question about upstart start conditions: are events instantaneous never-to-be-repeated things, or long-lasting conditions?  If the former, how do "and" start conditions work?  IF the latter, how to get a list of the current conditions?  (I'm trying to figure out why a job isn't starting.)
[06:07] <cypherpunks> Ping?
[07:09] <cypherpunks> Ping?
[07:57] <cypherpunks> Sigh, it's quiet.
[09:55] <cypherpunks> Anyone actually here?
[10:04] <ion> They are instantaneous. Upstart was supposed to gain support for states (which would have made “and” much better) but development has been kind of slow and now even Ubuntu is going to switch to systemd.
[10:32] <cypherpunks> ion: Wow, thanks!  So if I have an and condition, like the one in stock Ubuntu tty2: "start on runlevel [23] and (not-container or container CONTAINER=lxc or container CONTAINER=lxc-libvirt)", it might not ever start because I can have the "runlevel" and "not-container" events both trigger, just not simultaneously?
[10:35] <cypherpunks> I wish the cookbook was a little clearer on this point.  I have a mostly 12.04 system that refuses to start any console login process (getty or lightdm) until I ssh in and do it manually.  Very annoying.
[10:35] <ion> IIRC the job keeps track of the events and when both conditions have been triggered it’ll get started. The problem with events (compared to states) is that if the job is stopped by an event, i think both events may need to happen again for it to start again, even though you never left the state whose start one of the events represents.
[10:36] <cypherpunks> Ah, so an event *can* be pending, but it's kept in the job's condition parse tree?  And there's no way to see them?
[10:39] <cypherpunks> (I'm just trying to figure out "why the @#$$@$# is this not running", and it's a real bother to reboot, but I guess "--debug" is the only way.)
[10:39] <cypherpunks> (to reboot this particular machine, FWIW.  There's a second bug I'm tying to debug where the kernel isn't finding the root file system, requiring manual intervention at the initrd shell prompt.)
[10:41] <ion> Someone who has paid more attention to the and/or condition handling code than me can probably give more definite answers.
[10:44] <cypherpunks> But thanks.  That does help clarify things.
[13:40] <bingsucks> JanC: FYI I dug through the kernel source last night and error codes are negated before returned. The -2 I got is in fact equal to 2, which if you take a look at include/uapi/asm-generic/error-base.h, corresponds to ENOENT. I assume that means no inode entry for that file, because it is commented as no such file or directory.
[13:43] <bingsucks> However I do need to look again to see if ENOENT is assigned to another constant.
[13:52] <lolzadam> cypherpunks: if nothing else, have each event trigger a task job that sets an env var. Change that and to an or and just make the job check both vars
[13:59] <jodh> xnox: Hi - could you review https://code.launchpad.net/~jamesodhunt/upstart/bug-1288243/+merge/209693 (and maybe knock off https://code.launchpad.net/~jamesodhunt/upstart/restrict-debug-stanza/+merge/204363 too?)
[14:00] <xnox> jodh: i'm confused about the debug stanza =))) hence i didn't review it =)))
[14:00] <xnox> jodh: aha, so re-exec didn't keep the name. Maybe re-exec should keep the name?
[14:00] <jodh> xnox: that 2nd branch simply makes the debug stanza a NOP unless you boot with --debug.
[14:01] <xnox> jodh: such that e.g. if i booted /sbin/init.dima it would stay init.dima after re-exec?
[14:01] <xnox> jodh: and is the same binary re-execed?
[14:02] <jodh> xnox: yes, it always re-execs its original argv[0].
[14:02] <jodh> xnox: hence the problem in the test env :)
[14:02] <xnox> jodh: hm, create test_init symlink?! =))))
[14:02] <jodh> xnox: nooooooooo....!
[14:03] <xnox> ok. =)
[14:35] <lolzadam> On a kernel + busybox setup, I compiled upstart with an Arch disc. Used the /opt/upstart prefix, changed kernel line to include upstart init location. Now getting kernel panic "Failed to execute /opt/upstart/sbin/init (error -2)"
[14:37] <lolzadam> Error -2 is commented in the kernel source as no such file. I have verified the rootfs is mounting successfully, and the old init on the same partition still works. Any ideas?
[14:37] <lolzadam> BTW also verified the file is there and size is non zero
[14:38] <jodh> lolzadam: boot using init=/bin/sh then after checking the file exists and ldd is happy with it, 'exec /opt/upstart/sbin/init --debug </dev/console >/dev/console 2>&1
[14:38] <jodh> lolzadam: ' :-)
[14:38] <lolzadam> Lol thanks.
[14:40] <lolzadam> Haven't tried ldd, but did try 'exec <path> --verbose' per troubleshooting info on website and got 'init must be PID 1' erroe
[14:40] <jodh> xnox: thanks for the reviews. The final https://code.launchpad.net/~jamesodhunt/upstart/bug-1258098/+merge/202458 should now complete the tests successfully.
[14:40] <lolzadam> I will give that a shot though
[14:42] <lolzadam> BTW is the upstart project going to be dropped after Ubuntu switches to systemd?
[14:43] <lolzadam> systemd is too heavy and over complicated. Great for desktop, not so much for server OS imho
[14:44] <xnox> lolzadam: systemd software collection is about ~30 daemons. /all/ of them are two heavy, but just the init is actually ok for a server.
[14:44] <jodh> lolzadam: huh? when you boot with init=/bin/sh, you should be pid 1 ("echo $$")
[14:44] <xnox> s/two/too/
[14:46] <lolzadam> xnox: ah makes sense. So any predictions/insight on continued upstart development?
[14:46] <jodh> lolzadam: regarding the upstart project - yes Ubuntu are switching to systemd, but we have not yet decided *when*. Also, even after we switch we still have years of support for releases containing upstart. After that, "I don't know" I'm afraid.
[14:46] <lolzadam> jodh: I'll check, hang on
[14:46] <lolzadam> Hmmm
[14:48] <lolzadam> 158
[14:48] <xnox> lolzadam: for the next 5-7 years, upstart will still be developed. Which is long enough for anything to happen.
[14:48] <jodh> lolzadam: um, if that's a pid, that's your problem :)
[14:49] <lolzadam> Lol sorry, wrong VM o.O
[15:05] <lolzadam> Aha... ldd reveals some missing libs. Guess those wouldn't have been copied to the mounted partition with make install
[15:05] <lolzadam> Doh! Lol
[16:05] <lolzadam> Will it build and run right with --enable-static
[18:00] <xnox> jodh: so, upstart bugfix release will be happening this week, right? i'm thinking to use inet6 socket activation =)