| SpamapS | slangasek: any idea on how to get upstart to print stuff on the console in sid? | 00:30 |
|---|---|---|
| === nikias_ is now known as nikias | ||
| gabrbedd | Hello! When upstart emits an event... is there a way to get that event broadcast over something like dbus? | 01:47 |
| gabrbedd | E.g. I have a system daemon that needs to be notified of upstart events as they happen. | 01:48 |
| gabrbedd | nevermind... 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 | ||
| SpamapS | gabrbedd: :) | 16:37 |
| SpamapS | slangasek: uugggh.. startpar.c has mixed tabs and spaces | 17:23 |
| slangasek | SpamapS: which stuff are you looking for upstart to print on the console? | 17:37 |
| 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:38 |
| SpamapS | slangasek: init: starting foo.. | 17:40 |
| 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:41 |
| 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:42 |
| 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:54 |
| 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:55 |
| 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:56 |
| SpamapS | ok so this will work for cloud-init, I see that. However.. it seems like we could fix this some other way. | 17:57 |
| SpamapS | slangasek: is this documented already and I just skipped it? | 17:58 |
| slangasek | which part? | 17:58 |
| SpamapS | slangasek: the "startup tasks must be converted to jobs" part? | 17:59 |
| slangasek | yeah, that's not documented | 17:59 |
| 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:00 |
| SpamapS | slangasek: :) | 18:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| SpamapS | slangasek: I'm also wondering why I'm not hitting some kind of timeout ... | 18:07 |
| 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:08 |
| 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:10 |
| SpamapS | hm just changing all the tasks to pre-starts hangs boot for me :( | 18:11 |
| 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:22 |
| SpamapS | doh, and have to add stop on's | 18:29 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| slangasek | we probably are getting the stopped RESULT=# event, but we aren't doing anything meaningful with the $RESULT | 18:37 |
| 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: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 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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 ;) | 18:59 |
| SpamapS | slangasek: ok so for my purposes, just removing the symlinks in /etc/rc2.d is the simplest solution | 19:01 |
| 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:02 |
| 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:13 |
| SpamapS | slangasek: doh | 19:43 |
| SpamapS | slangasek: in a perfect world that wouldn't be problematic. :( | 19:44 |
| 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:48 |
| SpamapS | slangasek: yeah I always thought that would have been nice even in Ubuntu. | 19:50 |
| 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:51 |
| 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:52 |
| 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:55 |
| 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:56 |
| 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:57 |
| SpamapS | ah delta management | 19:58 |
| SpamapS | slangasek: is there some kind of CTTE action coming soon on this? | 19:58 |
| 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 | 19:59 |
| 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:01 |
| SpamapS | slangasek: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735204 reported against cloud-init, FYI | 20:19 |
| 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:20 |
| 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:21 |
| SpamapS | you almost have to have a special type of start on for htat | 20:22 |
| SpamapS | for that | 20:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!