[00:30] <SpamapS> slangasek: any idea on how to get upstart to print stuff on the console in sid?
=== nikias_ is now known as nikias
[01:47] <gabrbedd> Hello! When upstart emits an event... is there a way to get that event broadcast over something like dbus?
[01:48] <gabrbedd> E.g. I have a system daemon that needs to be notified of upstart events as they happen.
[01:55] <gabrbedd> nevermind... I was using upstart 1.5.  I see that this "just works" in 1.10.
=== jodh` is now known as jodh
=== adrien_o1w is now known as adrien_oww
[16:37] <SpamapS> gabrbedd: :)
[17:23] <SpamapS> slangasek: uugggh.. startpar.c has mixed tabs and spaces
[17:37] <slangasek> SpamapS: which stuff are you looking for upstart to print on the console?
[17:38] <slangasek> if this is about upstart's log messages, I don't know; but somewhere along the line there was a behavior change, I think on the kernel side, that caused upstart's use of kmsg to not work the way it had previously
[17:40] <SpamapS> slangasek: init: starting foo.. 
[17:41] <SpamapS> slangasek: ahh yeah if kmsg is not working the same way that might do it
[17:41] <SpamapS> slangasek: I _do_ see some init: stuff in dmesg
[17:41] <SpamapS> slangasek: hey I'm reading startpar's upstart integration and wondering if there is a huge race condition
[17:42] <SpamapS> slangasek: Help me understand.. startpar is going to wait for started events from stuff in /etc/rc2.d ..
[17:42] <SpamapS> slangasek: but what if started already happened before startpar was listening
[17:54] <slangasek> SpamapS: startpar checks on startup for any already-running jobs; so as long as the job it's looking for ends in 'started' state, it's fine
[17:54] <SpamapS> slangasek: ok, so cloud-init won't work then
[17:54] <SpamapS> slangasek: it has tasks
[17:54] <SpamapS> slangasek: that scheme wont' work for tasks
[17:54] <slangasek> heh
[17:54] <SpamapS> slangasek: they're stop/waiting already
[17:54] <slangasek> yes, so the cloud-init upstart job needs to be changed to end in state 'started' with no running job
[17:55] <SpamapS> I believe that is what is going on in my VM
[17:55] <slangasek> s/job/process/
[17:55] <SpamapS> wha?
[17:55] <SpamapS> thats like.. breaking the basic way tasks work.
[17:55] <slangasek> why does it need to be a task?
[17:55] <slangasek> as opposed to being a non-task with no main process and a pre-start script?
[17:55] <SpamapS> because it blocks startup while udev-y things are happening.
[17:56] <SpamapS> basically cloud-init wants to stop everything until the network is up
[17:56] <slangasek> and why do you think a pre-start script doesn't do this just as well as a script?  AFAIK, the two models are interconvertible, unless you need to run the job multiple times
[17:57] <SpamapS> ok so this will work for cloud-init, I see that. However.. it seems like we could fix this some other way.
[17:58] <SpamapS> slangasek: is this documented already and I just skipped it?
[17:58] <slangasek> which part?
[17:59] <SpamapS> slangasek: the "startup tasks must be converted to jobs" part?
[17:59] <slangasek> yeah, that's not documented
[18:00] <slangasek> because the set of affected packages is rather small, and doesn't really include anything outside of the base system... except for cloud-init :P
[18:03] <SpamapS> slangasek: :)
[18:04] <SpamapS> slangasek: and can I assume that you're using the symlinks in /etc/rc#.d to allow enable/disable?
[18:04] <slangasek> SpamapS: update-rc.d in sid supports managing upstart .override files for enable/disable, in parallel with the rc?.d symlink changes
[18:05] <slangasek> (upstart is certainly not going to look at the symlinks when deciding whether to start or stop a job)
[18:05] <SpamapS> oh ok, so would another possibility be to remove the symlinks for special packages like cloud-init ?
[18:05] <slangasek> you could do that locally, yeah
[18:05] <SpamapS> ok, I did that and cloud-init didn't start
[18:05] <slangasek> doing it in the distro doesn't help, since it breaks compatibility with sysvinit, which someone decided was worthwhile when porting to Debian :P
[18:06] <slangasek> hmm
[18:06] <SpamapS> so I was thinking startpar was stopping it or something
[18:06] <slangasek> nope
[18:06] <SpamapS> that observation is only about 4 minutes old though, so do ignore for now
[18:07] <SpamapS> slangasek: I'm also wondering why I'm not hitting some kind of timeout ...
[18:08] <slangasek> possibly because cloud-init sticks itself in places that block the timeout handling?
[18:08]  * slangasek doesn't really know
[18:08] <SpamapS> slangasek: so the timeouts apply to waiting for the upstart jobs, right?
[18:08] <slangasek> which timeouts?
[18:10] <SpamapS> oh hm.. startpar's timeouts are about flushing buffers
[18:10] <SpamapS> n/m
[18:10] <SpamapS> slangasek: I saw -t ## and thought it was "stop waiting for it after ## seconds"
[18:11] <SpamapS> hm just changing all the tasks to pre-starts hangs boot for me :(
[18:22] <SpamapS> ah and anything that uses the stopped events of these tasks now has to use the started event... thats why ti hangs. :-P
[18:29] <SpamapS> doh, and have to add stop on's
[18:33] <SpamapS> slangasek: ok sorry to gab your ear off. If a job fails to start.. it will be stop/waiting .. but startpar will wait for it forever.... ideas?
[18:34] <slangasek> hmm
[18:34] <slangasek> isn't that the same thing startpar does with an init script that fails?
[18:34] <SpamapS> I dont know
[18:35] <slangasek> I'm pretty sure it is
[18:35] <SpamapS> I thought it would mark it as FAIL
[18:35] <slangasek> oh
[18:35] <SpamapS> and still finish the boot
[18:35] <slangasek> yeah, you could be right
[18:35] <slangasek> in which case, we would need to extend the startpar bridge to handle this case
[18:36] <slangasek> I'm not too enthusiastic about this; the startpar bridge was always intended to be a short-term transitional solution
[18:36] <SpamapS> You should get the stopped RESULT=# event.. but you might have missed it. :-P
[18:36] <SpamapS> slangasek: Understood. I'm happy to help. This is a side project of mine at the moment. :)
[18:37] <slangasek> we probably are getting the stopped RESULT=# event, but we aren't doing anything meaningful with the $RESULT
[18:39] <SpamapS> slangasek: so this particular job is start on (filesystem and started rsyslog) ..
[18:39] <SpamapS> slangasek: and it fails in < 1s
[18:39] <SpamapS> slangasek: so I'm guessing startpar is nearly always going to miss that
[18:39] <SpamapS> unless they're queued up or something
[18:39] <slangasek> which they aren't, I'm afraid
[18:40] <slangasek> (why is it 'start on filesystem and started rsyslog' instead of 'start on started rsyslog', given that rsyslog starts on filesystem?)
[18:40] <SpamapS> slangasek: cribbed from ubuntu I'm sure
[18:40] <SpamapS> it should probably just be start on started rsyslog
[18:40] <SpamapS> but even then.. :-P
[18:41] <slangasek> yep
[18:41] <SpamapS> this is cloud-config
[18:41] <SpamapS> it could probably just be 'start on stopped rc RUNLEVEL=[2345]' in Ubuntu..
[18:41] <SpamapS> but with the current scheme, nothing can be 'start on stopped rc RUNLEVEL=[2345]' because rc is waiting for it to start. :-P
[18:42] <SpamapS> anyway I think I'm in the weeds..
[18:42] <SpamapS> slangasek: what is your longer term plan?
[18:42] <slangasek> SpamapS: longer term plan is to not need a startpar bridge because everything is natively upstart
[18:43] <SpamapS> slangasek: part of what I'm doing is keeping a project that wants to use Debian from using systemd or generating a ton of new sysvinit scripts.. so just help me get out in front of them.. it doesn't have to be perfect today. :)
[18:43] <slangasek> or because Debian adopts systemd instead, one of the two :P
[18:43] <SpamapS> ok
[18:43] <SpamapS> so this resolves when the war is over. wonderful. ;)
[18:59] <SpamapS> doh
[18:59] <SpamapS> rsyslog isn't installed on my vm
[18:59] <SpamapS> wait no it is..
[18:59] <SpamapS> but it has no upstart job
[18:59] <SpamapS> which explains a lot ;)
[19:01] <SpamapS> slangasek: ok so for my purposes, just removing the symlinks in /etc/rc2.d is the simplest solution
[19:02] <SpamapS> slangasek: cloud-init is also pretty borken and will basically never work as-is but I'll submit patches. Thanks for the feedback.
[19:13] <slangasek> ah yes, rsyslog isn't upstartified yet, is it... I've not gotten around to submitting the patches since the Debian maintainer is one of the systemd maintainers, heh
[19:43] <SpamapS> slangasek: doh
[19:44] <SpamapS> slangasek: in a perfect world that wouldn't be problematic. :(
[19:48] <slangasek> SpamapS: so, we could extend this to let init scripts signal back to upstart as well by synthesizing 'start' events; this has been buried on my TODO list for a while
[19:48] <slangasek> SpamapS: but that can be done as a hook into lsb init functions
[19:50] <SpamapS> slangasek: yeah I always thought that would have been nice even in Ubuntu.
[19:51] <slangasek> SpamapS: it's < 20 lines of shell code, if you want to JFDI :)
[19:51] <SpamapS> slangasek: no, I don't think cloud-config actually needs rsyslog for one thing.
[19:52] <SpamapS> slangasek: also I've always discouraged that kind of boot ordering as crackful. Services that aren't _boot_ related should just all boot at runlevel 2.
[19:52] <SpamapS> cloud-config really can just start at runlevel 2.
[19:55] <SpamapS> slangasek: I'm reporting this bug against cloud-init and it is unfortunate.. I'm basically going to force an Ubuntu delta because of startpar. Are you sure there's no way for cloud-init to just say "don't put my symlinks in /etc/rc#.d as long as upstart is the intended init" ?
[19:56] <slangasek> SpamapS: there definitely isn't, because the init system can be changed at runtime, post-install
[19:56] <SpamapS> I fail to see how that doesn't result in a bootable system.
[19:57] <slangasek> ?
[19:57] <SpamapS> Triggers would be needed actually.
[19:57] <SpamapS> You'd need a trigger that removes the symlinks if upstart is the init, and adds them back in if sysvinit is in place.
[19:58] <SpamapS> ah delta management
[19:58] <SpamapS> slangasek: is there some kind of CTTE action coming soon on this?
[19:59] <slangasek> right... and those triggers don't exist, the current model is that the filesystem should have everything in place to boot under any init
[19:59] <slangasek> SpamapS: probably going to vote this month, if all the members have a chance to finish their investigation
[20:01] <SpamapS> slangasek: I get that model. Another option is to have a latch job keeps track of tasks that have started.
[20:01] <slangasek> anyway, I think making init scripts emit start/stop events is a good thing in and of itself
[20:01] <SpamapS> yeah I do too
[20:01] <slangasek> so if I can't goad you into JFDI, maybe I should ;)
[20:01] <SpamapS> just don't have much more time to put into my little side project :)
[20:19] <SpamapS> slangasek: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735204 reported against cloud-init, FYI
[20:20] <slangasek> cheers
[20:20] <SpamapS> slangasek: note that I am pondering a single "start on started" job that keeps track of what has started in /run
[20:21] <SpamapS> slangasek: startpar could check that after setting up the event listening.. 
[20:21] <slangasek> I'd suggest making it part of the existing startpar bridge job... trying to have two separate jobs that 'start on started' is a great way to get an infinite loop, jodh found this out once :)
[20:21] <SpamapS> Oh I didn't look at that
[20:21] <SpamapS> but... right.. I never thoguht of that!
[20:22] <SpamapS> you almost have to have a special type of start on for htat
[20:22] <SpamapS> for that