[09:44] I wrote an upstart job for nsd3, and it works. [09:44] ...except when nsd3 needs to regenerate its database, in which case it seems to fork even when I tell it not to [09:47] I don't really want to "expect fork"; it's such a hack [09:49] http://paste.debian.net/110841/ [09:49] What am I supposed to do about that? [10:14] OK, now I understand [10:14] Apparently when you -HUP (reload) nsd, it gets a whole new PID, and it writes the PID to its designated pidfile, but upstart doesn't know this. [10:15] So I think I just have to give up and define "pre start exec nsdc start" and "pre stop exec nsdc stop" instead of "exec nsd -d" [10:23] Fixed: http://paste.debian.net/110845/ [11:34] I guess for such situations it would be useful to be able to point upstart to a "pidfile"... [12:03] JanC: I think for such situations, it would be useful to stab someone in the face for fork()ing on SIGHUP. [12:03] JanC: That's just madness. [12:48] soren: sshd and squid use this "madness" [12:48] soren: not sure we should ignore their success as highly stable daemons ;) [13:04] SpamapS: I don't believe that's true. [13:05] soren: look at the recent bug fixes to the upstart confs for squid and sshd [13:05] both to move them to running in the foreground because they fork on HUP [13:05] SpamapS: I'm looking at sshd.c right now. sighup_restart execve's. I does not fork(). [13:05] janc: Insanity lies on that path. [13:05] execve's.. which subsequently, forks [13:05] SpamapS: Oh. [13:05] yeah.. its t3h suck [13:06] breaks the assumptions that expect fork makes unfortunately [13:06] * soren facepalms [13:06] Which, btw, are not well documented. :-P [13:07] The postfix developers have expressed interest in supporting upstart, but have also stated they won't do so until the interface for expect fork/reload/etc. is published [15:03] I have an upstart job. I'd like to stop it gracefully. Is there someway to specify a script to stop it? [15:08] is there someting like "X-Start-Before:" from insserv in upstart? [15:22] I have an upstart job. I'd like to stop it gracefully. Is there someway to specify a script to stop it? [15:22] damn. I swear I looked for where I'd posted that question and couldn't find it (until I pressed ENTER). [16:25] ralfgro: start on starting [16:25] dsc: what do you mean gracefully? [16:26] dsc: stop job_name tells upstart to send SIGTERM, then after kill timeout (default 5 seconds) SIGKILL [16:37] SpamapS: by graceful, what I mean is I want to run a script to stop it because I don't have any reason to suspect SIGTERM will be handled gracefully. [16:38] pre-stop script [16:38] ... [16:38] end script [16:38] ;-) [16:38] Keybuk: great. Thanks. [16:38] one of the main uses for a pre-stop is to perform a graceful shut down [16:39] I didn't see pre-stop documented anywhere, only post-stop [16:39] dsc: it's documented in "man 5 init" [16:39] pre-stop exec|script... [16:39] This process is run if the job is stopped by an event listed in [16:39] its stop on stanza or by the stop(8) command. It will be run [16:39] before the job's stopping(7) event is emitted and before the [16:39] main process is killed. It is typically used to send any neces‐ [16:39] sary shutdown commands to the main process, and it may also call [16:39] the start(8) command without arguments to cancel the stop. [16:40] Keybuk: if ever there was a time to create an upstart shirt.. now that 1.0 is out.. I think it should just read 'man 5 init' on the front. [16:44] "Upstart isn't documented! ... Except for all the man pages" [16:44] none of the top google hits mention it. I'm probably on an older version, which might explain my man pages. [16:45] dsc: you would have to be on a very, very old version [16:45] I guess I didn't fin it because I was doing "man init" and getting "man 8 init" [16:46] which has, on the very first screenful [16:46] Processes managed by init are known as jobs and are defined by files in [16:46] the /etc/init directory. See init(5) for more details on configuring [16:46] Upstart. [16:46] ... [16:46] just sayin' ;-) [16:46] yes it does. I plead guilty to a breadth-first scan of man. :) [16:47] yeah, I seem to like lots of smaller manpages [16:47] rather than one big one [16:50] I noticed one google hit that mentioned "service" in a job. I don't find that in init(5). Is that newer? === dsc is now known as dcorbin_work [18:12] dcorbin_work: no, in fact "service" in a job predates any significant shipped version of Upstart [18:13] all versions you're ever likely to encounter use "task" instead for the opposite (the default has been service since 0.5.0) [18:15] Keybuk: should I see it in init(5)? [18:17] dcorbin_work: not anymore [18:17] the term is used still, but there is no config keyword [18:17] Got it. Thanks [19:01] Is there a log made of all upstart events? [19:03] (or a setting to have it log such) [20:32] dcorbin_work: read about "log-priority" in "man initctl" [20:33] and about "--verbose" in init(5) [20:33] in init(8) I mean [21:19] ion: I'm still trying to work out *why* shells are behaving like that (re: 619269) [21:20] Perhaps for the very reason that the script closing a file descriptor doesn’t break the shell’s reading of the input file. [21:20] the shell doesn't really know [21:20] so far it seems to be a side-effect of another behaviour [21:22] oh, I see [21:23] the input file descriptor is "saved" [21:23] which means moving it to be >= 10 as permitted by POSIX [21:24] I think I'm being a numpty here anyway [21:26] yes, I am [21:27] if only this was p9 [21:27] What does plan9 do? [21:28] in p9, we could just create a pipe [21:28] and pass the path of that pipe as a filename ;) [21:34] Am i wrong in assuming that Upstart could simply use a fd <10 for the shell’s half of the pipe and insert the prefix 'exec n<&-;' to scripts? [21:35] see my most recent comment [21:35] ah :-) [21:37] keybuk@keybuk:~$ ls -l /proc/self/fd [21:37] total 0 [21:37] lrwx------ 1 keybuk eng 64 Mar 16 14:37 0 -> /dev/pts/2 [21:37] lrwx------ 1 keybuk eng 64 Mar 16 14:37 1 -> /dev/pts/2 [21:37] lrwx------ 1 keybuk eng 64 Mar 16 14:37 2 -> /dev/pts/2 [21:37] lr-x------ 1 keybuk eng 64 Mar 16 14:37 3 -> /proc/20482/fd [21:37] ... [21:37] where is that #3 coming from?! :p [21:37] It’s the dir opened by ls to do its thing :-) [21:38] keybuk@keybuk:~$ ls -l /proc/$$/fd [21:38] total 0 [21:38] lr-x------ 1 keybuk eng 64 Mar 16 14:09 0 -> /dev/pts/2 [21:38] lrwx------ 1 keybuk eng 64 Mar 16 14:09 1 -> /dev/pts/2 [21:38] lrwx------ 1 keybuk eng 64 Mar 16 14:09 2 -> /dev/pts/2 [21:38] lrwx------ 1 keybuk eng 64 Mar 16 14:38 255 -> /dev/pts/2 [21:38] ... [21:38] even funnier, 255 ?! [21:38] Yeah, bash did: dup2(3, 255) = 255 [21:38] why did bash do that? [21:39] what was that 3 originally? [21:39] the input file parameter opened [21:39] that was just "exec bash" [21:39] it must be a bash-y thing I guess [21:40] keybuk scripts% ls -l /proc/20541/fd [21:40] total 0 [21:40] lr-x------ 1 keybuk eng 64 Mar 16 14:39 0 -> /dev/pts/2 [21:40] lrwx------ 1 keybuk eng 64 Mar 16 14:39 1 -> /dev/pts/2 [21:40] lr-x------ 1 keybuk eng 64 Mar 16 14:39 10 -> /dev/tty [21:40] lrwx------ 1 keybuk eng 64 Mar 16 14:39 2 -> /dev/pts/2 [21:40] keybuk scripts% ls -l /proc/20603/fd [21:40] total 0 [21:40] lrwx------ 1 keybuk eng 64 Mar 16 14:40 0 -> /dev/pts/2 [21:40] lrwx------ 1 keybuk eng 64 Mar 16 14:40 1 -> /dev/pts/2 [21:40] lrwx------ 1 keybuk eng 64 Mar 16 14:40 2 -> /dev/pts/2 [21:40] dash keeps a tty open at #10 ;-) [21:41] but most importantly doesn't leak it [21:42] Yeah, none of them seem to. [21:45] keybuk init# ps w -p 31158 [21:45] PID TTY STAT TIME COMMAND [21:45] 31158 ? Ss 0:00 /bin/sh -e /proc/self/fd/12 [21:45] keybuk init# ls -l /proc/31158/fd [21:45] total 0 [21:45] lrwx------ 1 root root 64 Mar 16 14:44 0 -> /dev/null [21:45] lrwx------ 1 root root 64 Mar 16 14:44 1 -> /dev/null [21:45] lr-x------ 1 root root 64 Mar 16 14:44 12 -> pipe:[4648423] [21:45] lrwx------ 1 root root 64 Mar 16 14:44 2 -> /dev/null [21:45] lr-x------ 1 root root 64 Mar 16 14:44 255 -> pipe:[4648423] [21:45] keybuk init# ls -l /proc/31159/fd [21:45] total 0 [21:45] lrwx------ 1 root root 64 Mar 16 14:44 0 -> /dev/null [21:45] lrwx------ 1 root root 64 Mar 16 14:44 1 -> /dev/null [21:45] lr-x------ 1 root root 64 Mar 16 14:44 12 -> pipe:[4648423] [21:45] lrwx------ 1 root root 64 Mar 16 14:44 2 -> /dev/null [21:45] ... [21:45] whereas 12 is definitely leaked there [21:45] the shell actually has the file opened as #255 too [21:45] yeah [21:46] so close(12) wouldn't actually close the file [21:49] of course [21:49] this is all another reason we can't support "perl script" ;-) [22:11] I'm such an evil cunt [22:12] since a year has now passed since the MOST ANNOYING BUG EVAH was filed [22:12] I only now fix it [22:12] because it was too much fun leaving it open for the screaming idiots [22:12] (522197) [22:16] hah [23:21] sigh, it appears that Lennart is posting to upstart-devel with An Opinion ;-) [23:31] The message from ~30 minutes ago or something that hasn’t made it into my mailbox yet?