SpamapSslangasek: any idea on how to get upstart to print stuff on the console in sid?00:30
=== nikias_ is now known as nikias
gabrbeddHello! When upstart emits an event... is there a way to get that event broadcast over something like dbus?01:47
gabrbeddE.g. I have a system daemon that needs to be notified of upstart events as they happen.01:48
gabrbeddnevermind... I was using upstart 1.5.  I see that this "just works" in 1.10.01:55
=== jodh` is now known as jodh
=== adrien_o1w is now known as adrien_oww
SpamapSgabrbedd: :)16:37
SpamapSslangasek: uugggh.. startpar.c has mixed tabs and spaces17:23
slangasekSpamapS: which stuff are you looking for upstart to print on the console?17:37
slangasekif 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 previously17:38
SpamapSslangasek: init: starting foo.. 17:40
SpamapSslangasek: ahh yeah if kmsg is not working the same way that might do it17:41
SpamapSslangasek: I _do_ see some init: stuff in dmesg17:41
SpamapSslangasek: hey I'm reading startpar's upstart integration and wondering if there is a huge race condition17:41
SpamapSslangasek: Help me understand.. startpar is going to wait for started events from stuff in /etc/rc2.d ..17:42
SpamapSslangasek: but what if started already happened before startpar was listening17:42
slangasekSpamapS: 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 fine17:54
SpamapSslangasek: ok, so cloud-init won't work then17:54
SpamapSslangasek: it has tasks17:54
SpamapSslangasek: that scheme wont' work for tasks17:54
SpamapSslangasek: they're stop/waiting already17:54
slangasekyes, so the cloud-init upstart job needs to be changed to end in state 'started' with no running job17:54
SpamapSI believe that is what is going on in my VM17:55
SpamapSthats like.. breaking the basic way tasks work.17:55
slangasekwhy does it need to be a task?17:55
slangasekas opposed to being a non-task with no main process and a pre-start script?17:55
SpamapSbecause it blocks startup while udev-y things are happening.17:55
SpamapSbasically cloud-init wants to stop everything until the network is up17:56
slangasekand 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 times17:56
SpamapSok so this will work for cloud-init, I see that. However.. it seems like we could fix this some other way.17:57
SpamapSslangasek: is this documented already and I just skipped it?17:58
slangasekwhich part?17:58
SpamapSslangasek: the "startup tasks must be converted to jobs" part?17:59
slangasekyeah, that's not documented17:59
slangasekbecause the set of affected packages is rather small, and doesn't really include anything outside of the base system... except for cloud-init :P18:00
SpamapSslangasek: :)18:03
SpamapSslangasek: and can I assume that you're using the symlinks in /etc/rc#.d to allow enable/disable?18:04
slangasekSpamapS: update-rc.d in sid supports managing upstart .override files for enable/disable, in parallel with the rc?.d symlink changes18:04
slangasek(upstart is certainly not going to look at the symlinks when deciding whether to start or stop a job)18:05
SpamapSoh ok, so would another possibility be to remove the symlinks for special packages like cloud-init ?18:05
slangasekyou could do that locally, yeah18:05
SpamapSok, I did that and cloud-init didn't start18:05
slangasekdoing it in the distro doesn't help, since it breaks compatibility with sysvinit, which someone decided was worthwhile when porting to Debian :P18:05
SpamapSso I was thinking startpar was stopping it or something18:06
SpamapSthat observation is only about 4 minutes old though, so do ignore for now18:06
SpamapSslangasek: I'm also wondering why I'm not hitting some kind of timeout ...18:07
slangasekpossibly because cloud-init sticks itself in places that block the timeout handling?18:08
* slangasek doesn't really know18:08
SpamapSslangasek: so the timeouts apply to waiting for the upstart jobs, right?18:08
slangasekwhich timeouts?18:08
SpamapSoh hm.. startpar's timeouts are about flushing buffers18:10
SpamapSslangasek: I saw -t ## and thought it was "stop waiting for it after ## seconds"18:10
SpamapShm just changing all the tasks to pre-starts hangs boot for me :(18:11
SpamapSah and anything that uses the stopped events of these tasks now has to use the started event... thats why ti hangs. :-P18:22
SpamapSdoh, and have to add stop on's18:29
SpamapSslangasek: 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:33
slangasekisn't that the same thing startpar does with an init script that fails?18:34
SpamapSI dont know18:34
slangasekI'm pretty sure it is18:35
SpamapSI thought it would mark it as FAIL18:35
SpamapSand still finish the boot18:35
slangasekyeah, you could be right18:35
slangasekin which case, we would need to extend the startpar bridge to handle this case18:35
slangasekI'm not too enthusiastic about this; the startpar bridge was always intended to be a short-term transitional solution18:36
SpamapSYou should get the stopped RESULT=# event.. but you might have missed it. :-P18:36
SpamapSslangasek: Understood. I'm happy to help. This is a side project of mine at the moment. :)18:36
slangasekwe probably are getting the stopped RESULT=# event, but we aren't doing anything meaningful with the $RESULT18:37
SpamapSslangasek: so this particular job is start on (filesystem and started rsyslog) ..18:39
SpamapSslangasek: and it fails in < 1s18:39
SpamapSslangasek: so I'm guessing startpar is nearly always going to miss that18:39
SpamapSunless they're queued up or something18:39
slangasekwhich they aren't, I'm afraid18:39
slangasek(why is it 'start on filesystem and started rsyslog' instead of 'start on started rsyslog', given that rsyslog starts on filesystem?)18:40
SpamapSslangasek: cribbed from ubuntu I'm sure18:40
SpamapSit should probably just be start on started rsyslog18:40
SpamapSbut even then.. :-P18:40
SpamapSthis is cloud-config18:41
SpamapSit could probably just be 'start on stopped rc RUNLEVEL=[2345]' in Ubuntu..18:41
SpamapSbut with the current scheme, nothing can be 'start on stopped rc RUNLEVEL=[2345]' because rc is waiting for it to start. :-P18:41
SpamapSanyway I think I'm in the weeds..18:42
SpamapSslangasek: what is your longer term plan?18:42
slangasekSpamapS: longer term plan is to not need a startpar bridge because everything is natively upstart18:42
SpamapSslangasek: 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
slangasekor because Debian adopts systemd instead, one of the two :P18:43
SpamapSso this resolves when the war is over. wonderful. ;)18:43
SpamapSrsyslog isn't installed on my vm18:59
SpamapSwait no it is..18:59
SpamapSbut it has no upstart job18:59
SpamapSwhich explains a lot ;)18:59
SpamapSslangasek: ok so for my purposes, just removing the symlinks in /etc/rc2.d is the simplest solution19:01
SpamapSslangasek: cloud-init is also pretty borken and will basically never work as-is but I'll submit patches. Thanks for the feedback.19:02
slangasekah 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, heh19:13
SpamapSslangasek: doh19:43
SpamapSslangasek: in a perfect world that wouldn't be problematic. :(19:44
slangasekSpamapS: 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 while19:48
slangasekSpamapS: but that can be done as a hook into lsb init functions19:48
SpamapSslangasek: yeah I always thought that would have been nice even in Ubuntu.19:50
slangasekSpamapS: it's < 20 lines of shell code, if you want to JFDI :)19:51
SpamapSslangasek: no, I don't think cloud-config actually needs rsyslog for one thing.19:51
SpamapSslangasek: 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
SpamapScloud-config really can just start at runlevel 2.19:52
SpamapSslangasek: 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:55
slangasekSpamapS: there definitely isn't, because the init system can be changed at runtime, post-install19:56
SpamapSI fail to see how that doesn't result in a bootable system.19:56
SpamapSTriggers would be needed actually.19:57
SpamapSYou'd need a trigger that removes the symlinks if upstart is the init, and adds them back in if sysvinit is in place.19:57
SpamapSah delta management19:58
SpamapSslangasek: is there some kind of CTTE action coming soon on this?19:58
slangasekright... and those triggers don't exist, the current model is that the filesystem should have everything in place to boot under any init19:59
slangasekSpamapS: probably going to vote this month, if all the members have a chance to finish their investigation19:59
SpamapSslangasek: I get that model. Another option is to have a latch job keeps track of tasks that have started.20:01
slangasekanyway, I think making init scripts emit start/stop events is a good thing in and of itself20:01
SpamapSyeah I do too20:01
slangasekso if I can't goad you into JFDI, maybe I should ;)20:01
SpamapSjust don't have much more time to put into my little side project :)20:01
SpamapSslangasek: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735204 reported against cloud-init, FYI20:19
SpamapSslangasek: note that I am pondering a single "start on started" job that keeps track of what has started in /run20:20
SpamapSslangasek: startpar could check that after setting up the event listening.. 20:21
slangasekI'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
SpamapSOh I didn't look at that20:21
SpamapSbut... right.. I never thoguht of that!20:21
SpamapSyou almost have to have a special type of start on for htat20:22
SpamapSfor that20:22

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!