[00:43] sadmac2: re: committing printf's, doesn't bzr have an equivalent of 'darcs record' / 'git add -p' [00:43] ? [00:43] assuming upstart is in bzr.. [00:48] mugwump: its a bit too interleaved for that to be easy [00:48] I tend to rebase a lot with git to preen my changes down [00:49] it's a longer path, but hugely satisfying once you've travelled a while down it... [00:50] eg, knowing that no change breaks the test suite makes finding regressions pretty easy [00:52] Yeah, i constantly use rebase -i for unpushed changes. [01:00] ion: any idea why the macruby interpreter rakefile would run dtrace [01:00] ? [01:41] sadmac: I have no idea. [01:42] Something to do with unit tests maybe? [01:42] ion: something to do with probe points I think [09:17] What is the best way of having an upstart job depends/requires on another process, that is still sysv? [09:18] Am i correct in saying that upstart checks "start on starting xyz" sagainst upstart jobs only? [09:22] Additionally, does anyone have an example of a job that sources variables from a conf file, for the exec line? [09:23] is it as trival as you would expect? === h\h is now known as haraldh === robbiew_ is now known as robbiew [14:59] Daviey: you can add "initctl emit" lines to your sysv scripts to make them emit events, which offers upstart a way to interact with them [16:30] keybuk: A random thought about prioritizing fscks and mounts: with the current system, if we’re already running fsck for /notimportant and then a partition for /important on the same device appears, it’s not possible to get /important queued any sooner than after the /notimportant check. How about this instead: don’t lock anything and start everything in parallel, but for each device, have only one fsck (the one deemed most important at any moment) running ... [16:30] ... with normal ionice prioritiy, and ionice all other instances ‘idle’. If we’re running a fsck for /notimportant and /important appears, the fsck for /notimportant would be changed to idle priority until the check for /important finishes. [16:37] keybuk: I take it that change would be too big for karmic at this point? [16:37] if i came up with a patch, say, today :-P [16:40] can you change the io priority of other processes? [16:40] if you can make the patch work, I can merge it [16:41] still have the fsck progress patch to merge [16:42] /usr/bin/ionice has a -p PID parameter, so it should be possible. [16:49] neat [16:52] either something's wrong with my git tree, or somethings wrong with cscope, or sys_ioprio_set is weird [16:52] Keybuk, ion: sys_ioprio_set(int which, int who, int ioprio) [16:53] I could disambiguate that a bit if I could find the actual definition [16:55] ... is it written in ASM?! [16:58] no, its just missing...weird... [17:03] it's probably under arch/ [17:05] Keybuk: I've grepped. its nowhere [17:05] Keybuk: every entry.S mentions it. syscalls.h mentions it. No source file mentions it. [17:07] The ioprio_set manpage is clear enough. :-) [17:08] sadmac: fs/ioprio.c:75 no? [17:09] Keybuk: ah. figured it was something like that. [17:09] worthless macros making the world a better place. [17:27] keybuk: Is a simple check for (mnt->tag > TAG_OTHER) a good rule for prioritizing running fsck instances? [17:27] ion: yes === tclineks is now known as lpdn === lpdn is now known as tclineks === notting_ is now known as notting === pocek_ is now known as pocek [23:15] Bug #439138 is getting to be real frustrating. Could someone explain what the deal with console owner is? [23:19] ok [23:19] it's about time I wrote this down [23:19] and please do feel free to tidy up what I write and paste it liberally ;) [23:20] in Linux, we have consoles [23:20] but really we mean Virtual Terminals (VTs) [23:20] and we have TTYs too [23:20] not to mention Pseudo-Terminals [23:20] (PTYs) [23:20] it's all a bit of the kind of jumble sale you get after 40 years of different solutions to different problems [23:21] we can lump them together under the description "terminals" for the next bit [23:21] we also have processes [23:23] okay, so far so good === robbiew is now known as robbiew-afk [23:26] now, processes have a lot of odd little details [23:26] they have a parent [23:26] they have a session [23:26] and a session has a foreground process group [23:26] and a background process group [23:27] now Stevens devotes an entire chapter for this [23:27] and nobody but me apparently understands it ;) [23:28] (and hopefully the guy who maintains the kernel side) [23:28] but it works something like that [23:28] each process is part of a session [23:28] a process may begin a new session by calling setsid() [23:28] every process that init creates is in its own session [23:28] the process is also then the leader of the foreground process group of that session [23:28] new processes are also in that session [23:28] and in that process group [23:28] unless otherwise placed into a new process group [23:29] (setpgrp) [23:29] any new process group is a background process group [23:29] so now, you have a bunch of sessions [23:29] each session has a bunch of process groups, one of which is the foreground process group [23:29] each process group has a bunch of processes, one of which is the leader [23:29] with me so far? [23:29] okay [23:30] right [23:30] so this all has to do, fundamentally, with terminals [23:31] and who gets the signals [23:31] when the leader of the foreground process group of a session opens a terminal device (without O_NOCTTY) that becomes the CONTROLLING TERMINAL of that process group [23:31] (in fact of that session) [23:32] the terminal and the session become bound to each other [23:32] you can fake this another way by opening a terminal device without O_NOCTTY (or having one passed to you) and then calling the TIOCSCTTY ioctl [23:33] ok [23:33] so [23:33] terminals, controlling terminals and processes [23:33] here's where this gets fun [23:33] if the controlling terminal is hung up, SIGHUP is sent to the foreground process group [23:33] if ^C is pressed on the controlling terminal, SIGINT is sent to the foreground process group [23:33] if ^Z is pressed on the controlling terminal, SIGTSTP is sent to the foreground process group [23:34] (you're getting the idea here I guess) [23:34] yup [23:34] so this is how the relationship between magic key presses and signals gets established [23:34] shells care about this a lot [23:35] (and yes, when you use & that becomes a background process group :p) [23:35] (and when you use | they are all in the same process group) [23:35] anyhoo [23:35] onwards [23:35] now [23:35] this controlling terminal business applies to all terminals [23:35] whether they be true terminals (which linux doesn't have) [23:35] or virtual terminals [23:36] or pseudo terminals [23:36] so this is as true for your ssh login as VT1 [23:36] okay [23:36] you can always access your *controlling terminal* using /dev/tty [23:36] it's a badly named device node [23:36] it may also be called /dev/ttyS0 or /dev/pts/4 etc. [23:37] so right [23:37] Linux has a bunch of virtual terminals [23:37] these are the things we think of when we say "console" but we're using that wrong [23:37] virtual terminals behave just like ordinary terminals [23:37] they can be the controlling terminal for a process group [23:38] but, unfortunately, stacked on top is the linux vt API [23:38] (they didn't think to make it separate) [23:38] so the stuff to set fonts [23:38] to place it in raw or graphics mode [23:38] to create new vts [23:38] to switch vts [23:38] etc. [23:38] is all loaded into the tty api [23:39] so, in order for X to function, it needs a VT [23:39] right [23:39] and it needs access to that VT in interesting and familiar ways to place it into raw and graphics mode [23:39] and so on [23:39] it also needs to know if the *current VT* is switched [23:39] so it opens the VT device it wants (/dev/tty7) [23:39] and that becomes its controlling terminal [23:39] so if you were to delete VT7, X would get SIGHUP :) [23:40] now, on VT1-6 you have getty [23:40] on VT8 you have usplash [23:40] and so on [23:40] this is all fine and dandy [23:40] except there's this last mystical piece [23:40] /dev/console [23:40] /dev/console is, like /dev/tty, a fake device [23:41] it points at the currently active VT [23:41] whatever that is [23:41] but it *behaves* like a terminal in its own right [23:41] (whereas /dev/tty just behaves as a proxy for the underlying terminal) [23:41] now, Upstart has a few knobs to customise the standard input, output & error file descriptors [23:41] normally it just starts all jobs with them as /dev/null [23:42] but for *emulation of sysvinit* it has two other options [23:42] 1. set them to /dev/console [23:42] 2. set them to /dev/console and issue the TIOCSCTTY ioctl() [23:42] (console output, console owner) [23:42] now, if your current VT is 7 (X) [23:42] and you start a job that has console owner in it [23:43] the new process will *take the terminal away from X* [23:43] X gets SIGHUP [23:43] and either hits 100% CPU or crashes [23:43] so this is clearly BAD [23:44] the problem really is that things need a "console" at all [23:44] jobs that require interaction should DO IT THEMSELVES [23:45] they should open a VT, switch to it, and ask there [23:45] or they should use usplash to do it [23:45] or they should use X [23:47] hmm [23:50] this (switching to an unused VT, asking for a pass, and then switching back) doesn't sound too hard [23:50] "start usplash" [23:50] you can do that under X [23:50] (please don't try it unless you have an Intel card right now ) [23:52] "start usplash" doesn't do anything here (i965) [23:54] really? [23:54] that's odd :) [23:55] I get this: usplash stop/pre-start, process 2357 [23:56] but either way, that doesn't seem to be an option right now if it breaks on non-intel hardware. [23:58] that's a bug we have to fix for release anyway