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