[03:37] Is "pre-start exec" allowed (instead of "pre-start script")? [03:38] Also: WTF just happened: stop gitit ==> stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist [03:38] twb: yes [03:39] an no clue about the DBus error ;) [03:39] and * [03:39] OK, thanks [03:39] I think it was pissed because I said "script end" instead of "end script" [03:41] http://paste.debian.net/106276/ [03:41] Though strangely, it isn't writing anything to the logfile now I rotated it [03:43] hm, how does it log? [03:43] not via syslog(3) [03:43] I think it opens it directly [03:45] http://paste.debian.net/106277/ [03:45] This is on lucid, btw [03:46] hm, and with savelog -p the permissions should be right too, I suppose [03:47] Hmm, even if I run gitit as root, it doesn't write to that file [03:48] Strace can see it opening the log, though [03:48] open("/var/log/gitit.log", O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_NONBLOCK, 0666) = 7 [03:49] is it supposed to write anything in absence of errors? [03:50] Ah, I think the original 271 bytes were logs of *init* [03:50] i.e. subsequent boots don't print anything, even for GETs [03:57] I give up. [03:57] BTW, do you know how to not have the extra su process hanging around? [03:57] http://paste.debian.net/106278/ [04:19] yes, but not sure if upstart will like that ;) [04:20] Tell me and I'll check [04:20] Also re logging, it was because 'log-level: WARNING' is the default. [04:22] basically, su is waiting for the process it starts to end [04:23] Why doesn't it do a forkless exec of sh -c? [04:31] I'd use sudo instead, but I'd prefer to avoid the syslog noise from sudo [04:46] you can run gitit in the background [04:47] but upstart might not like that ;) [04:47] Yeah, obviously that's no good [04:50] I doubt the su process does any harm to your system anyway ;) [04:50] Sure, it's just ugly [15:47] hi all, does anyone know where the upstart/initctl status is saved? like the association between the daemon and the pid. i have a incorrectly stopped init that is now giving the 'start/killed' with a non-existant pid [15:47] i was hoping to clear the config somewhere [16:08] it's "saved" in memory only [16:15] http://heh.fi/tmp/workaround-upstart-snafu might be useful [16:31] anchepiece: just stop the job .. [16:33] Oh I see.. can't kill the pid that doesn't exist. Interesting. [16:44] JanC: where did that workaround-upstart-snafu script come from btw? [16:45] SpamapS: ion pointed to it a couple of days ago [16:49] Seems like init would know about any pids it was tracking dying. [16:51] grrr, why does my ISP insist on 36-hourly disconnects... :-( [16:51] SpamapS: ion pointed to it a couple of days ago [16:51] I guess it's his script === JanC_ is now known as JanC [16:52] maybe it was tracking the wrong pid though? [18:29] SpamapS: i cant find that script online anymore [18:29] have a copy [18:29] ? [18:32] anchepiece: if you mean the snafu script, it's still there? [18:32] the url is 404 [18:33] not from here... [18:33] you in some place where internet is filtered? [18:33] ah its back! [18:33] thanks [18:37] well it just spawns infinit threads [18:37] JanC: my point is that even if it was tracking the wrong pid.. if the pid it is tracking dies.. it will know and respawn or not .. [18:37] i think ill wait till a reboot and leave the renamed daemon [18:38] anchepiece: so status foo shows a pid that doesn't exist? [18:38] anchepiece: or status foo shows infinite pids ? [18:38] SpamapS: it won't (always) respawn infinitely though [18:38] status foo shows a pid that doesdnt exist [18:38] JanC: right, I'm more saying that I can't see a situation where upstart shows a pid that is dead in status. [18:39] the workaround-snafu prints out an increasing number (new pids?) [18:39] seems like a bug somewhere. [18:39] that workaround-snafu may take forever on a system that uses pseudo random pids. [18:39] I've never seen it happen myself [18:39] the bug was my fault (putting an expect fork when there shouldnt have been, then prematurely ctrl-c killing the stop command when it stalled) [18:40] no it increments [18:40] SpamapS: yeah, in theory it can as well take 100 years or something ;) [18:41] ie: start/killed, process 13790 ./workaround-upstart-snafu 13790 prints out the next pid available past 13790 like 22xxx then counts up as it creates new pids [18:41] interesting [18:41] going to leave it running just to see what happens [18:42] ok it dropped back to 1000s [18:42] now i understand how it works [18:43] it tries until a process with that PID exists [18:43] then we hope upstart gets unconfused ;) [18:44] it did, but it respawned the old conf [18:44] it's normally used for a slightly different issue though [18:44] nowe stop is hung [18:47] i think this tool will work [18:47] upstart needs a built-in "unbreak" command I guess ;) [18:47] well maybe a non-ruby dependant version of the script will do [18:47] that should be easy enough [18:48] it just forks until a process has the requested PID [18:49] JanC: the issue is that upstart can only do anything if a process's parent pid is 1.. it does that by either keeping it in the foreground, or ptrace attaching.. so somewhere, it detached from the process without making sure it was dead. That seems to be the bug. [18:50] it worked -> status: Unknown job: [18:50] thanks for help [18:51] anchepiece: glad its resolved for you.. but thats pretty ugly.. forking through the whole pid namespace. :-P [18:51] err.. pid space.. [18:52] SpamapS: that's why it's called a workaround ;) [18:52] and now respawning on a crash is working perfectly [18:53] i vote to add that script or a bash variant to the release package [18:54] fixing the bug would be better ;) [18:54] a long-term state of stopped/killed with a pid may be a clue [18:55] a command to tell upstart it has to forget or force the status of 1 particular job could be useful too [18:55] but of course that's still a workaround [18:56] Yeah [18:56] better workaround [18:56] It actually may be this bug https://bugs.launchpad.net/upstart/+bug/539175 [18:56] but.. in reverse [18:59] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/438313 https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/504989 https://bugs.launchpad.net/upstart/+bug/406397 [19:03] anchepiece: thanks.. that does look like the problem [19:18] The real fix is the proc connector implementation that Just Works™. Meanwhile, people just need to use ‘expect’ only when they’re 100 % sure of the forking behavior of their main process. [19:22] given the response tho [19:22] the existence of a "verify pids" workaround seems needed [19:23] also it would make sense for init to just verify that its signal was acted on by checking the entry in /proc if available [19:24] Backups are needed for people who delete important stuff by mistake. Yes, people shouldn’t delete important stuff by mistake. [19:25] Anyhoo, a clean patch that is not too nasty a kluge might make it into Upstart. [19:33] …if Keybuk approves it, of course. :-) [19:39] what do I have to approve? [19:52] People have been suggesting that Upstart check the pids it thinks it’s tracking actually exist as a workaround when people confuse Upstart with incorrect use of ‘expect’. That is, until the proc connector implementation is there, of course. I said your approval is needed for a patch if someone feels like creating one. [20:00] how would it "check" the pid? [20:02] In any case, it would be a kluge. I didn’t really give thought to how to avoid a race condition etc. [20:14] reminds me that I must finish my new supervisor code, give that to everyone to play with [20:19] The proc connector code? [21:04] Hello! I hope I'm in the right channel. I have a question on upstart. I have a daemon to monitor the power status. It needs to intercept shutdown/reboot event, i.e. runlevel 0 and 6, and before network goes down, it needs to report to a centralized server. My question is: in upstart how to I define "before network goes down and after shutdown/reboot"? [21:20] Or can someone point me to the right place/mailing list to ask the question? Thanks! [21:24] yuantai: i think if you stick around a bit someone will have a good answer for you.. [21:24] i think yuo can throw a script into here though: /etc/network/if-down.d [21:24] /etc/network/if-down.d/upstart i mean [21:29] thank you anchepiece, [21:31] I'm doing it on a RHEL6 machine, it doesn't have the /etc/network/if-down.d/upstart. Is it only in Ubuntu? [21:33] http://upstart.pastebin.com/vz8hq557 [21:33] yuantai: how about start on starting rc RUNLEVEL=[016] ? [21:33] thats the initctl emit [21:34] * SpamapS doesn't know if RHEL6 uses rc either :-P [21:34] that file is in marked executabe in /etc/network/if-down.d/ dir [21:39] Thanks SpamapS, it seems RHEL6 also uses rc. [21:39] yuantai: note that that will make it run *before* the shutdown commences [21:39] yuantai: but, as soon as your job finishes, the rc will start and shutdown [21:41] anchepiece: I'm wondering if I can use this code in my own machine? [21:43] in a conf file add a "start on net-device-down" [21:43] SpamapS: in this combined format, can I find out which runlevel the admin issued? My daemon also needs to know whether it's reboot or shutdown [21:46] anchepiece: for "start on net-device-down", is it going to run when ifdown command is issued? [21:47] you need to drop that script in /etc/network/if-down.d/ ,which will emit and read in your conf [21:47] so yes [21:47] yuantai: yes $RUNLEVEL will be set to it I think [21:47] i guess that ubuntu is much more tightly integrate with upstart than fedora/redhat [21:48] anchepiece: I don't know if they have that in fedora/redhat [21:48] /etc/network/if-down.d/ ? [21:48] oh hrm [21:48] yes you're right [21:49] well, on this older fedora c7 its not there [21:50] but i see mention of it in fc13 [21:51] i guess look thtough /etc/sysconfig/network-scripts [21:52] thanks anchepiece, yes it's in /etc/sysconfig/network-scripts, [21:55] But is this folder the upstart scripts? [21:56] i think you'd have to add a call yourself to the /etc/sysconfig/network-scripts/ifdown script (see how OTHERSCRIPT is run, duplicate that) [21:56] sorry have to go but you are close [21:56] thank you anchepiece