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