| 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:16 |
| pmjdebruijn | I fixed my RTC though | 08:21 |
| pmjdebruijn | ok | 11:27 |
| 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:36 |
| 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:37 |
| 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:38 |
| pmjdebruijn | I guess I'll have to upstartify all important rc services | 11:47 |
| pmjdebruijn | to make this work | 11:47 |
| pmjdebruijn | :( | 11:48 |
| sleon | hi | 14:46 |
| sleon | is there a trick how to get current display and username of the user who is logged in other gdm? | 14:47 |
| === balgarath_ is now known as balgarath | ||
| 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:38 |
| 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:39 |
| sveinse | Is there a way to ensure ordered execution? Change rc.conf to start when my custom script is done? | 16:40 |
| pmjdebruijn | I'd not change rc conf | 16:45 |
| pmjdebruijn | that bit me recently :) | 16:45 |
| 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:00 |
| 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:17 |
| 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:18 |
| pmjdebruijn | sveinse: you might want to pastebin your original upstart script here, so other can take a look, and idle a bit more | 17:19 |
| sleon | stopped manpage states that there is RESULT parameter which is either ok or failed | 17:37 |
| 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:38 |
| sleon | aaa i got it | 17:50 |
| sleon | they are only set in start on | 17:50 |
| 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:58 |
| marrusl | that guy didn't have to modify rc.conf necissarily. he could have made his own job start on starting rc. | 19:59 |
| pmjdebruijn | huh? | 20:00 |
| * pmjdebruijn recommended he _not_ change rc.conf | 20:00 | |
| marrusl | pmjdebruijn, yes. agreed. | 20:00 |
| 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:01 |
| marrusl | might not work depending on what he's doing with it. and s/he's gone anyway. so no matter. | 20:03 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| pmjdebruijn | marrusl: btw we have more handy backports :) | 20:30 |
| 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:31 |
| 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:32 |
| 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 | :) | 20:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!