| 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:43 |
| 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:48 |
| mugwump | it's a longer path, but hugely satisfying once you've travelled a while down it... | 00:49 |
| mugwump | eg, knowing that no change breaks the test suite makes finding regressions pretty easy | 00:50 |
| ion | Yeah, i constantly use rebase -i for unpushed changes. | 00:52 |
| sadmac2 | ion: any idea why the macruby interpreter rakefile would run dtrace | 01:00 |
| sadmac2 | ? | 01:00 |
| ion | sadmac: I have no idea. | 01:41 |
| ion | Something to do with unit tests maybe? | 01:42 |
| sadmac2 | ion: something to do with probe points I think | 01:42 |
| Daviey | What is the best way of having an upstart job depends/requires on another process, that is still sysv? | 09:17 |
| Daviey | Am i correct in saying that upstart checks "start on starting xyz" sagainst upstart jobs only? | 09:18 |
| Daviey | Additionally, does anyone have an example of a job that sources variables from a conf file, for the exec line? | 09:22 |
| Daviey | is it as trival as you would expect? | 09:23 |
| === h\h is now known as haraldh | ||
| === robbiew_ is now known as robbiew | ||
| 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 | 14:59 |
| 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:30 |
| 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:37 |
| 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:40 |
| Keybuk | still have the fsck progress patch to merge | 16:41 |
| ion | /usr/bin/ionice has a -p PID parameter, so it should be possible. | 16:42 |
| Keybuk | neat | 16:49 |
| 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:52 |
| sadmac | I could disambiguate that a bit if I could find the actual definition | 16:53 |
| sadmac | ... is it written in ASM?! | 16:55 |
| sadmac | no, its just missing...weird... | 16:58 |
| Keybuk | it's probably under arch/ | 17:03 |
| 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:05 |
| ion | The ioprio_set manpage is clear enough. :-) | 17:07 |
| Keybuk | sadmac: fs/ioprio.c:75 no? | 17:08 |
| sadmac | Keybuk: ah. figured it was something like that. | 17:09 |
| sadmac | worthless macros making the world a better place. | 17:09 |
| ion | keybuk: Is a simple check for (mnt->tag > TAG_OTHER) a good rule for prioritizing running fsck instances? | 17:27 |
| Keybuk | ion: yes | 17:27 |
| === tclineks is now known as lpdn | ||
| === lpdn is now known as tclineks | ||
| === notting_ is now known as notting | ||
| === pocek_ is now known as pocek | ||
| TomJaeger | Bug #439138 is getting to be real frustrating. Could someone explain what the deal with console owner is? | 23:15 |
| 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:19 |
| 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:20 |
| Keybuk | we can lump them together under the description "terminals" for the next bit | 23:21 |
| Keybuk | we also have processes | 23:21 |
| TomJaeger | okay, so far so good | 23:23 |
| === robbiew is now known as robbiew-afk | ||
| 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:26 |
| Keybuk | now Stevens devotes an entire chapter for this | 23:27 |
| Keybuk | and nobody but me apparently understands it ;) | 23:27 |
| 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:28 |
| 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:29 |
| Keybuk | right | 23:30 |
| Keybuk | so this all has to do, fundamentally, with terminals | 23:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| Keybuk | the problem really is that things need a "console" at all | 23:44 |
| Keybuk | jobs that require interaction should DO IT THEMSELVES | 23:44 |
| 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:45 |
| TomJaeger | hmm | 23:47 |
| 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:50 |
| TomJaeger | "start usplash" doesn't do anything here (i965) | 23:52 |
| Keybuk | really? | 23:54 |
| Keybuk | that's odd :) | 23:54 |
| TomJaeger | I get this: usplash stop/pre-start, process 2357 | 23:55 |
| TomJaeger | but either way, that doesn't seem to be an option right now if it breaks on non-intel hardware. | 23:56 |
| Keybuk | that's a bug we have to fix for release anyway | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!