| === Amaranth_ [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === mbiebl_ [i=michael@conference/debconf/x-bd6bcb3ca59aabe6] has joined #upstart | ||
| === mbiebl_ [i=michael@conference/debconf/x-d275a5993d6c8d6a] has joined #upstart | ||
| === mbiebl_ [i=michael@conference/debconf/x-1297f79c091eafd5] has joined #upstart | ||
| === kylem [n=kyle@amnesiac.heapspace.net] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === tck [n=tck@212.2.170.159] has joined #upstart | ||
| === phoenix24 [i=cixz@ns37986.ovh.net] has joined #upstart | ||
| === phoenix24 [i=uko@ns37986.ovh.net] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === phoenix24_ [i=gwxy@ns37986.ovh.net] has joined #upstart | ||
| === phoenix24_ is now known as phoenix24 | ||
| === tck_ [n=tck@A-102-141.cust.iol.ie] has joined #upstart | ||
| Keybuk | today I feel like I have a handle of the event expression atomicity issues | 01:48 |
|---|---|---|
| === phoenix24_ [i=cwh@ns37986.ovh.net] has joined #upstart | ||
| === juergbi [n=juerg@80-219-19-183.dclient.hispeed.ch] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| Keybuk | Interesting question | 02:45 |
| Keybuk | when upstart kills a process, should it just kill that process, or should it kill everything in that process's group? | 02:45 |
| === phoenix24 [i=jbj@ns37986.ovh.net] has joined #upstart | ||
| shawarma | Keybuk: Good question. What about the session? | 02:53 |
| Keybuk | the session? | 02:54 |
| shawarma | Yup. | 02:54 |
| shawarma | getsid() | 02:54 |
| Keybuk | you can't kill a session | 02:55 |
| shawarma | If you SIGHUP the session leader, it trickles down to the other processes in the session. | 02:55 |
| Keybuk | actually, it's more complicated than that | 02:56 |
| shawarma | If you SIGTERM the session leader, it doesn't kill the rest of the processes, afair. | 02:56 |
| Keybuk | you don't mean session leader | 02:56 |
| Keybuk | you mean process group leader | 02:56 |
| shawarma | No, I'm quite sure I mean session leader. | 02:56 |
| Keybuk | and the SIGHUP thing only applies to the foreground process group with a controlling terminal | 02:57 |
| Keybuk | iirc. | 02:57 |
| shawarma | That's the session leader. | 02:57 |
| shawarma | Gah.. getsid has no man page. Gimme a sec. | 02:57 |
| Keybuk | the session leader is the first process in the session? | 02:57 |
| Keybuk | the one where the sid == pid | 02:57 |
| shawarma | Right. | 02:57 |
| Keybuk | setsid() gives you a process where pid == pgrp == sid | 02:57 |
| shawarma | Right. | 02:58 |
| Keybuk | ie. it's the session leader and a process group leader | 02:58 |
| Keybuk | process groups can exist without their leader | 02:58 |
| Keybuk | sessions contain one or more process groups | 02:59 |
| Keybuk | sessions can have a controlling terminal | 03:00 |
| shawarma | Right. | 03:00 |
| Keybuk | one of the process groups can be the foreground process group | 03:01 |
| Keybuk | all of the others are the background process groups | 03:01 |
| Keybuk | Control-C on the terminal will send SIGINT to all processes in the session's foreground process group | 03:01 |
| Keybuk | if the terminal is hung-up, SIGHUP is sent only to the session leader | 03:01 |
| shawarma | What causes the other processes in the session to die, then? | 03:02 |
| Keybuk | Control-Z sends SIGTSTP to all processes in the foreground process gruop | 03:03 |
| Keybuk | Control-\ sends SIGQUIT to all processes in the foreground process group | 03:03 |
| Keybuk | reading from standard input while you are not in the foreground process group will send SIGTTIN back to you | 03:04 |
| shawarma | ABout SIGHUP: "This signal is also generated if the session leader terminates. In this case the signal is sent to each process in the foreground process group". Hmm.. Is it the kernel doing that? | 03:04 |
| Keybuk | writing to a terminal while you are not in the foreground process group may either succeed or send SIGTTOU back to you | 03:04 |
| shawarma | (from APUE) | 03:05 |
| Keybuk | shawarma: dunno, not got that far yet (I'm in APUE too :p) | 03:05 |
| shawarma | *G* | 03:05 |
| shawarma | I cheated and skipped ahead. :) | 03:05 |
| Keybuk | children in a process group that are stopped are sent SIGHUP followed by SIGCONT if the process group they are in becomes orphaned | 03:07 |
| Keybuk | (ie. the parents of all processes in that process group are in different sessions) | 03:07 |
| Keybuk | SIGHUP is only sent if there is a controlling terminal | 03:08 |
| Keybuk | if the session leader terminates, SIGHUP is sent to the foreground process group (apparently) | 03:09 |
| shawarma | By whom? | 03:12 |
| shawarma | Must be the kernel.. | 03:12 |
| Keybuk | -- entering new session | 03:17 |
| Keybuk | pid: 9171 | 03:17 |
| Keybuk | pgrp: 9171 | 03:17 |
| Keybuk | sid: 9171 | 03:17 |
| Keybuk | -- execing shell script | 03:17 |
| Keybuk | --shell | 03:17 |
| Keybuk | pid: 9172 | 03:17 |
| Keybuk | pgrp: 9171 | 03:17 |
| Keybuk | sid: 9171 | 03:17 |
| Keybuk | --end shell | 03:17 |
| Keybuk | ok | 03:17 |
| Keybuk | so that's a session leader that execs a shell, which runs a single command | 03:17 |
| Keybuk | the shell is 9171 | 03:17 |
| Keybuk | the process group and session of the simple command is also 9171 | 03:17 |
| Keybuk | but the pid of the thing run in it is 9172 | 03:17 |
| Keybuk | which makes sense | 03:17 |
| Keybuk | doesn't get SIGHUP here | 03:24 |
| Keybuk | aha | 03:26 |
| Keybuk | does if it has a terminal | 03:26 |
| Keybuk | -- entering new session | 03:26 |
| Keybuk | -- taking control of terminal | 03:26 |
| Keybuk | pid: 9618 | 03:26 |
| Keybuk | pgrp: 9618 | 03:26 |
| Keybuk | sid: 9618 | 03:26 |
| Keybuk | -- execing shell script | 03:26 |
| Keybuk | -- shell 9618 | 03:26 |
| Keybuk | pid: 9619 | 03:26 |
| Keybuk | ppid: 9618 | 03:27 |
| Keybuk | pgrp: 9618 | 03:27 |
| Keybuk | sid: 9618 | 03:27 |
| Keybuk | -- end shell | 03:27 |
| Keybuk | 9619 got SIGHUP | 03:27 |
| Keybuk | -- exit | 03:27 |
| Keybuk | right | 03:27 |
| Keybuk | SIGHUP comes from the terminal control driver only | 03:27 |
| Keybuk | that makes sense | 03:36 |
| Keybuk | so the question is still valid | 03:36 |
| shawarma | I forgot the question :) | 03:37 |
| Keybuk | when upstart wants to kill a job, should it just send TERM to dash (which won't kill anything else since there's no terminal) or to the entire process group? | 03:37 |
| Keybuk | and how will this affect services with multiple processes, since they'll all get TERM, rather than just the top one? | 03:38 |
| shawarma | How does that work, actually? You iterate throguh the process space looking for things with the same pgid? | 03:38 |
| Keybuk | killpg :p | 03:38 |
| Keybuk | thom: how would apache cope with that? | 03:38 |
| shawarma | I think each request each child is handling would be dropped and the top process would clean up the mess.. | 03:40 |
| Keybuk | yeah | 03:44 |
| Keybuk | I think killpg is reasonable here | 03:44 |
| Keybuk | (it's also what sysvinit does ... I never noticed that) | 03:45 |
| Keybuk | *giggle* | 03:47 |
| Keybuk | well, that change royally buggered up my test suite | 03:47 |
| === Keybuk adds setpgrp() calls to the test children | ||
| === tck [n=tck@213-202-136-190.bas502.dsl.esat.net] has joined #upstart | ||
| === phoenix24 [i=wqsqpr@ns37986.ovh.net] has joined #upstart | ||
| === phoenix24 [i=eff@ns37986.ovh.net] has joined #upstart | ||
| === phoenix24 [i=ajfaxhw@ns37986.ovh.net] has joined #upstart | ||
| Keybuk | yay | 06:01 |
| Keybuk | job->cause is gone | 06:01 |
| AlexExtreme | whoo | 06:02 |
| === philippe_ [i=philippe@conference/debconf/x-29763299e36ef03e] has joined #upstart | ||
| Keybuk | though I now have a stack of issues with the new code ;o) | 06:03 |
| Keybuk | in particular | 06:03 |
| Keybuk | start on foo and bar | 06:03 |
| Keybuk | stop on frodo and bilbo | 06:03 |
| Keybuk | ... | 06:03 |
| Keybuk | if you stop that, and then foo happens quickly afterwards, it will start again | 06:03 |
| Keybuk | because the event tree still has the true values, and it's still enough to touch it | 06:03 |
| Keybuk | but if it happens after it has properly stopped, you need both foo and bar to happen again | 06:03 |
| Keybuk | (likewise for the stop on bit) | 06:03 |
| Keybuk | the way to solve that, I think, is to reference an "Event Expression" not just the root "Event Operator" | 06:04 |
| Keybuk | Event Expression would be the root Event Operator, and also an Event State | 06:04 |
| Keybuk | if the root operator becomes TRUE, the matching events from the tree are copied into the Event State, and then the operator tree is reset | 06:05 |
| Keybuk | the job would respond to the expression, so it retains the state while requiring the match to happen all over again | 06:05 |
| === mbiebl [i=michael@conference/debconf/x-95c94991903206ad] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === phoenix24 [i=pdadzx@ns37986.ovh.net] has joined #upstart | ||
| === phoenix24 [i=ychwysy@ns37986.ovh.net] has joined #upstart | ||
| === tck [n=tck@78.16.83.141] has joined #upstart | ||
| === tck_ [n=tck@213-202-139-46.bas502.dsl.esat.net] has joined #upstart | ||
| === phoenix24 [i=zaqabkr@ns37986.ovh.net] has joined #upstart | ||
| === phoenix24 [i=can@ns37986.ovh.net] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!