[08:16] <pmjdebruijn> I'm still having an issue where my shutdown is blocking
[08:16] <pmjdebruijn> last thing that upstart reports is that hwclock-save was stopped
[08:21] <pmjdebruijn> I fixed my RTC though
[11:27] <pmjdebruijn> ok
[11:36] <pmjdebruijn> so fiddling with the rc job is a bad idea
[11:36] <pmjdebruijn> it seems having something -start on stopped nethostname
[11:36] <pmjdebruijn> +start on stopped nethostname and starting rc
[11:36] <pmjdebruijn> sorry
[11:37] <pmjdebruijn> it seems that the following is a bad idea:
[11:37] <pmjdebruijn> -start on stopped nethostname
[11:37] <pmjdebruijn> +start on stopped nethostname and starting rc
[11:37] <pmjdebruijn> and it doesn't even do what I want it seems
[11:37] <pmjdebruijn> since starting rc doesn't garantee this job has finished before rc continues
[11:37] <pmjdebruijn> at least that's how it seems
[11:38] <pmjdebruijn> the big problem is, that's critical for me to have rc execute _after_ another job has finished running
[11:38] <pmjdebruijn> this is only relevant for bootup
[11:38] <pmjdebruijn> further runlevel changes do not need to be affected
[11:47] <pmjdebruijn> I guess I'll have to upstartify all important rc services
[11:47] <pmjdebruijn> to make this work
[11:48] <pmjdebruijn> :(
[14:46] <sleon> hi
[14:47] <sleon> is there a trick how to get current display and username of the user who is logged in other gdm?
[16:38] <sveinse> I'd like to start a small script when halt, reboot and shutdown are called. I've added a conf with start on runlevel [06] and the script embedded in a script block. However this often does not work, i.e. the script isn't run as it should. This is on Natty
[16:39] <sveinse> Because it could seems like there is a race between the rc.conf and my conf script. And if rc.conf is run prior to mine (which ultimately terminates the machine), then I understand why is doesn't run
[16:40] <sveinse> Is there a way to ensure ordered execution? Change rc.conf to start when my custom script is done?
[16:45] <pmjdebruijn> I'd not change rc conf
[16:45] <pmjdebruijn> that bit me recently :)
[17:00] <sveinse> Since init.d provides ordered script execution, while init doesn't, init doesn't seem to be a complete replacement of init.d yet.
[17:17] <pmjdebruijn> heh
[17:17] <pmjdebruijn> you really are missing the point
[17:17] <pmjdebruijn> :)
[17:17] <pmjdebruijn> the whole _point_ of upstart is not to be ordered, and allow parallization
[17:18] <pmjdebruijn> although I do agree it does complicate some things
[17:18] <pmjdebruijn> the fact that your job isn't always run is probably explainable
[17:18] <pmjdebruijn> sveinse: btw you can still use SysV init style scripts
[17:19] <pmjdebruijn> sveinse: you might want to pastebin your original upstart script here, so other can take a look, and idle a bit more
[17:37] <sleon> stopped manpage states that there is RESULT parameter which is either ok or failed
[17:38] <sleon> in which circumstances is it set ? because i do not see having it in the environment of a job which listens for stopped of other job
[17:50] <sleon> aaa i got it
[17:50] <sleon> they are only set in start on
[19:58] <marrusl> pmjdebruijn, yes.  however, there are some things that just need to run in order, there's no getting around it.  and there are ways to make that work in upstart.
[19:59] <marrusl> that guy didn't have to modify rc.conf necissarily.  he could have made his own job start on starting rc.
[20:00] <pmjdebruijn> huh?
[20:00]  * pmjdebruijn recommended he _not_ change rc.conf
[20:00] <marrusl> pmjdebruijn, yes.  agreed. 
[20:01] <marrusl> pmjdebruijn, so if he wants his custom.conf to always run before rc.conf, he can set his custom.conf to have "start on starting rc".
[20:01] <marrusl> maybe I missed something though.  ;)
[20:03] <marrusl> might not work depending on what he's doing with it.  and s/he's gone anyway.  so no matter.
[20:19] <pmjdebruijn> marrusl: that doesn't guarantee custom.conf has finished before rc.conf has finished
[20:19] <pmjdebruijn> also start on starting rc caused me problems when rebooting
[20:20] <marrusl> pmjdebruijn, no it actually should block until custom emits "started" or in his case, a task which I think would go straight to "stopped" then unblock rc
[20:20] <pmjdebruijn> eh
[20:20] <pmjdebruijn> it doesn't work like that
[20:20] <pmjdebruijn> I tried it
[20:21] <pmjdebruijn> unless something else was interfering
[20:21] <marrusl> in general if job a says "start on starting b", b will not do anything until a has emitted "started" or "stopped"
[20:21] <pmjdebruijn> gave me lots of grief in any case
[20:21] <marrusl> however rc is an odd job
[20:21] <pmjdebruijn> right
[20:21] <pmjdebruijn> like I said, in practise it didn't work for me
[20:22] <pmjdebruijn> didn't behave as expected
[20:22] <pmjdebruijn> and I had lockups when rebooting
[20:22] <pmjdebruijn>   digitalWrite(ledPin, HIGH);   // set the LED on
[20:22] <pmjdebruijn> sorry
[20:22] <pmjdebruijn> http://blog.pcode.nl/2011/08/11/upstart-dont-mess-with-the-rc-job/
[20:22] <marrusl> i'll buy it.  I just would say in general that it's not all about parallelization
[20:23] <marrusl> there are plenty of dependencies in upstart as well.  they're just not expressed that way.  you can order jobs.
[20:23] <pmjdebruijn> yeah
[20:23] <pmjdebruijn> rc just seems dangerous to mess with
[20:23] <marrusl> though it can be tough if you want job a to start before job b OR job c
[20:23] <marrusl> that I'll take on faith ;)
[20:23] <pmjdebruijn> :)
[20:24] <pmjdebruijn> I'm converting my remaining SysV scripts to upstart jobs
[20:24] <pmjdebruijn> then my problem just disppears
[20:24] <pmjdebruijn> most things are easy to upstartify
[20:24] <marrusl> It helps.  I've only tried a couple.
[20:24] <marrusl> seems like if you can run them in the foreground, you're set
[20:24] <pmjdebruijn> I had to patch nagios-nrpe though to allow it to run in the foreground
[20:24] <pmjdebruijn> still have to test that tomorrow
[20:24] <marrusl> right
[20:24] <marrusl> interesting
[20:25] <pmjdebruijn> https://launchpad.net/~unnet-pkg-master/+archive/icinga-release
[20:25] <pmjdebruijn> so it's untested now
[20:25] <pmjdebruijn> I hope to confirm tomorrow
[20:25] <marrusl> oh icinga.  interesting.
[20:25] <marrusl> how is that project going?
[20:25] <pmjdebruijn> well
[20:25] <pmjdebruijn> all the icinga extra's are not very nice
[20:26] <pmjdebruijn> but the CORE Icinga is great
[20:26] <pmjdebruijn> it's Nagios, but it seems to be better maintained
[20:26] <pmjdebruijn> the pimpy ajax frontend sucks, since it's impossible to package well at the moment
[20:26] <pmjdebruijn> I guess that'll just take some time
[20:26] <pmjdebruijn> but i'll take CORE icinga over nagios any time now
[20:27] <marrusl> i'm just wondering because the mindshare/install-base is still with nagios.  so some would be afraid of icinga having/maintaining momentum
[20:27] <marrusl> not close to that myself, just curious.
[20:28] <pmjdebruijn> my faith is with Icinga
[20:28] <pmjdebruijn> but I agree the war isn't over yet :)
[20:28] <pmjdebruijn> the big point is that core Icinga already is mature, since it's just a patched Nagios (3?)
[20:30] <pmjdebruijn> marrusl: btw we have more handy backports :)
[20:31] <marrusl> pmjdebruijn, when I get the chance, I will give it a go, because anything has got to be more pleasant than configuring nagios.
[20:31] <pmjdebruijn> well
[20:31] <pmjdebruijn> in that sense Icinga is the same
[20:31] <pmjdebruijn> configs haven't changed much
[20:31] <marrusl> haha.  rats.
[20:31] <pmjdebruijn> although the default layout is a bit nicer
[20:31] <pmjdebruijn> but that's marginal
[20:32] <pmjdebruijn> marrusl: to be honest I don't mind it much
[20:32] <pmjdebruijn> I haven't come across a different monitor tools that works as well as Nagios/Icinga
[20:32] <marrusl> and i've heard of a lot of people that use other tools to bend it into shape and find it pretty easy.
[20:32] <pmjdebruijn> even if it's harder to config
[20:32]  * pmjdebruijn does it by hand
[20:32] <pmjdebruijn> lots of automated tools create messy configs
[20:32]  * marrusl applauds.  :)
[20:32] <pmjdebruijn> so if you have to go in by hand for something it's that much harder
[20:34] <pmjdebruijn> in the end a good investment to config nagios by hand
[20:34] <pmjdebruijn> forces you to really think about things
[20:34] <pmjdebruijn> :)