| 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:44 |
| twb | I don't really want to "expect fork"; it's such a hack | 09:47 |
| twb | http://paste.debian.net/110841/ | 09:49 |
| twb | What am I supposed to do about that? | 09:49 |
| 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:14 |
| 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:15 |
| twb | Fixed: http://paste.debian.net/110845/ | 10:23 |
| JanC | I guess for such situations it would be useful to be able to point upstart to a "pidfile"... | 11:34 |
| 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:03 |
| SpamapS | soren: sshd and squid use this "madness" | 12:48 |
| SpamapS | soren: not sure we should ignore their success as highly stable daemons ;) | 12:48 |
| soren | SpamapS: I don't believe that's true. | 13:04 |
| 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:05 |
| SpamapS | breaks the assumptions that expect fork makes unfortunately | 13:06 |
| * soren facepalms | 13:06 | |
| SpamapS | Which, btw, are not well documented. :-P | 13:06 |
| 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 | 13:07 |
| dsc | I have an upstart job. I'd like to stop it gracefully. Is there someway to specify a script to stop it? | 15:03 |
| ralfgro | is there someting like "X-Start-Before:" from insserv in upstart? | 15:08 |
| 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). | 15:22 |
| SpamapS | ralfgro: start on starting | 16:25 |
| SpamapS | dsc: what do you mean gracefully? | 16:25 |
| SpamapS | dsc: stop job_name tells upstart to send SIGTERM, then after kill timeout (default 5 seconds) SIGKILL | 16:26 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:44 |
| 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:45 |
| 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:46 |
| Keybuk | yeah, I seem to like lots of smaller manpages | 16:47 |
| Keybuk | rather than one big one | 16:47 |
| dsc | I noticed one google hit that mentioned "service" in a job. I don't find that in init(5). Is that newer? | 16:50 |
| === dsc is now known as dcorbin_work | ||
| Keybuk | dcorbin_work: no, in fact "service" in a job predates any significant shipped version of Upstart | 18:12 |
| 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:13 |
| dcorbin_work | Keybuk: should I see it in init(5)? | 18:15 |
| 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 | 18:17 |
| dcorbin_work | Is there a log made of all upstart events? | 19:01 |
| dcorbin_work | (or a setting to have it log such) | 19:03 |
| JanC | dcorbin_work: read about "log-priority" in "man initctl" | 20:32 |
| JanC | and about "--verbose" in init(5) | 20:33 |
| JanC | in init(8) I mean | 20:33 |
| Keybuk | ion: I'm still trying to work out *why* shells are behaving like that (re: 619269) | 21:19 |
| 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:20 |
| Keybuk | oh, I see | 21:22 |
| Keybuk | the input file descriptor is "saved" | 21:23 |
| Keybuk | which means moving it to be >= 10 as permitted by POSIX | 21:23 |
| Keybuk | I think I'm being a numpty here anyway | 21:24 |
| Keybuk | yes, I am | 21:26 |
| Keybuk | if only this was p9 | 21:27 |
| ion | What does plan9 do? | 21:27 |
| Keybuk | in p9, we could just create a pipe | 21:28 |
| Keybuk | and pass the path of that pipe as a filename ;) | 21:28 |
| 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:34 |
| Keybuk | see my most recent comment | 21:35 |
| ion | ah :-) | 21:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| Keybuk | but most importantly doesn't leak it | 21:41 |
| ion | Yeah, none of them seem to. | 21:42 |
| 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:45 |
| Keybuk | so close(12) wouldn't actually close the file | 21:46 |
| Keybuk | of course | 21:49 |
| Keybuk | this is all another reason we can't support "perl script" ;-) | 21:49 |
| Keybuk | I'm such an evil cunt | 22:11 |
| 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:12 |
| ion | hah | 22:16 |
| Keybuk | sigh, it appears that Lennart is posting to upstart-devel with An Opinion ;-) | 23:21 |
| ion | The message from ~30 minutes ago or something that hasn’t made it into my mailbox yet? | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!