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