[01:44] <blackmogu> got a quick question about initctl and upstart
[01:45] <blackmogu> is it possible to get output from a job on a pty without resorting to silly hacks ?
[10:41] <sadleder> mbiebl: hi, what's going on on the upstart-for-debian front?
[10:59] <Md> sadleder: crap. some people are proposing to create a huge infrastructure to support every existing init daemon
[11:00] <sadleder> Md: oh boy
[11:01] <sadleder> Md: i read some posts on p.d.o
[11:08] <sadleder> Md: could you point me to planning pages?
[11:09] <Md> no pages, subscribe to the initscripts-ng-devel@lists.alioth.debian.org list
[11:14] <mbiebl> I also think that this idea is crap and will not work.
[11:16] <nenolod> seems a bit silly
[11:21] <Md> yes, but right now I am the only person saying it's stupid... please subscribe
[11:24] <mbiebl> Md: Yeah, I'll add my 2 soon.
[11:25] <sadleder> i sencond this
[11:25] <sadleder> second*
[11:28] <sadleder> mbiebl: are you running a fully upstartified system now?
[11:29] <mbiebl> Yes. The mounting and network stuff is still serial though.
[11:32] <sadleder> mbiebl: and it's not yet packaged, right?
[11:33] <mbiebl> There are still some missing pieces where I haven't decided yet, how I'm going to handle it.
[11:33] <mbiebl> So, no. No "official" packages yet.
[11:34] <sadleder> mbiebl: ok. just let me know, I'm available for trying them early
[11:34] <sadleder> ;-)
[01:05] <cort> what problem can't be solved by the addition of a new layer of indirection?
[01:25] <ion_> cort: Some problems need a perl oneliner and a regexp in addition to that.
[06:09] <Julius> hi
[06:09] <Julius> Md are u there ?
[06:24] <ion_> julius: Im sure others can answer your Upstart-related questions as well.
[06:25] <Julius> ion_, well actually i wanted to get my nickname dropped but some1 did it, thanks :)
[06:25] <ion_> I fail to see how thats on-topic for #upstart.
[06:25] <AlexExtreme> Julius, if you want freenode issues solving you should msg a staff member
[06:26] <Julius> AlexExtreme, that's what i did, thanks ! Md is one of them, that's why i tried to speak to him
[06:27] <Julius> cya guys :)
[08:37] <cyberix> How does one set up serial login with upstart?
[08:37] <cyberix> After a serial driver loaded signal somehow?
[08:49] <Md> what?
[08:49] <Md> you just take the event configuration for a console getty, copy it and write ttyS0 there
[08:53] <ion_> For a system without the sysvrc compatibility layer, perhaps just add a modprobe command to pre-start. An alternative would be making udev emit an event when it loads the module, and 'start on' that event.
[08:53] <ion_> If you have the compatibility layer, you can pretty much assume the module has been loaded.
[08:54] <ion_> (i think)
[08:54] <cyberix> Thanks
[08:55] <Md> the serial driver will be loaded automatically by udev
[10:40] <AlexExtreme> so
[10:40] <AlexExtreme> if I stop and restart udev, or udevd dies and gets respawned
[10:40] <AlexExtreme> udevtrigger will be re-run
[10:40] <AlexExtreme> and thus all the jobs with start on stopped udevtrigger ok will get run
[10:40] <AlexExtreme> and the whole boot sequence will be run again
[10:40] <AlexExtreme> which is not good
[10:53] <mbiebl> This only happens for jobs which start on stopped udevtrigger, which aren't stateful, right?
[10:54] <mbiebl> In your case, that would be fsck and swap I guess.
[10:55] <mbiebl> Actually, swap is stateful.
[10:55] <mbiebl> So it wouldn't start again (as the job is already running)
[10:56] <mbiebl> AlexExtreme: You could create a state "system-mounted" (better name to be chosen) which run on started udevtrigger
[10:57] <mbiebl> Argh, I meant "system-fscked"
[10:58] <Md> actions on file systems like fsck and swap should happen as a result of the block devices appearing, either as udev rules or upstart events
[10:58] <Md> there is no need to serialize everything on udevtrigger
[11:00] <mbiebl> Md: If udev dies and is respawned, would udevtrigger see the block devices as newly added
[11:00] <mbiebl> or not.
[11:05] <Md> if udev is respawned for any reason (e.g. upgrade) it is wrong to run again udevtrigger
[11:05] <Md> udevtrigger must be run exactly once (at boot time) and never again
[11:08] <mbiebl>  Then either the udevtrigger has to create some kind of lock file on startup (in /var/run) and when invoked a second time it simply does nothing when this file exists
[11:08] <mbiebl> Or we would need something like a "once" keyword in upstart.
[11:09] <Md> I think it should be possible to create some condition to run an event only once
[11:09] <Md> udevtrigger cannot do anything by itself because it's usually run at a time where / is mounted ro, so if there is some rw fs available it's a distro-specific issue
[11:17] <mbiebl> One problem on running the mounting/fscking asynchronously is, that it might actually be slower than running it sequentially.
[11:18] <ion_> I dont see how.
[11:18] <ion_> And if there are multiple HDDs, it would be faster.
[11:18] <mbiebl> Disk thrashing.
[11:18] <ion_> That would naturally be prevented by locking the fsck instances based on the physical device.
[11:19] <mbiebl> (which means, we serialize them again ;-) )
[11:19] <ion_> Only if there is just a single HDD.
[11:20] <ion_> http://johan.kiviniemi.name/blag/2007/03/19/upstart-and-mounting-partitions-part-2/
[11:20] <mbiebl> Right. I agree with you though, that this is probably the way to go.
[11:22] <mbiebl> It might get a bit tricky for lvm on raid and stuff like that.
[11:22] <ion_> Why is that?
[11:23] <mbiebl> Have you already worked on the tools to give you the physical device?
[11:23] <ion_> I did a functional prototype in sh, but i havent done the final C implementation.
[11:25] <mbiebl> Ok: what about the following scenario:
[11:25] <mbiebl> You have two disks: 40 GB and 80 GB
[11:25] <ion_> % foo() { local syspath="${1#/sys/block/}"; syspath="${syspath%%/*}"; set -- $(ls -1 /sys/block/"$syspath"/slaves); if [ "$*" = "" ] ; then echo "$syspath"; else for file in "$@"; do foo "$(readlink -f /sys/block/"$syspath"/slaves/"$file")"; done; fi; }; for f in dm-0 md1 sda sdb/sdb1; do foo "$f" | xargs echo "$f":; done
[11:25] <ion_> dm-0: sda sdb
[11:25] <ion_> md1: sda sdb
[11:25] <ion_> sda: sda
[11:25] <ion_> sdb/sdb1: sdb
[11:26] <mbiebl> One 40 GB pv on the first, a second pv on the second disk, and the remaining 40 GB on disk 2 are a regular partition.
[11:26] <ion_> It causes no problem at all.
[11:26] <mbiebl> You then create a lv out of pv1 and pv2
[11:26] <mbiebl> When you fsck the lv, will you lock disk1 and disk2?
[11:26] <ion_> Yes.
[11:27] <mbiebl> So, this means the second hard disk has to wait, event when it could check the second partition hdb2.
[11:29] <ion_> How can you be sure it could check hdb2, unless you hack fsck itself to handle the parallelization and make it compute which physical devices certain subsections of a partition reside on?
[11:30] <mbiebl> Yeah, what if I make hdb1 1GB and hdb2 79 GB.
[11:31] <mbiebl> This would mean after fscking hda1 there would be two instances of fsck on hdb running in parallel
[11:31] <ion_> It changes nothing. :-)
[11:31] <mbiebl> (for 1 Gb)
[11:31] <ion_> What do you mean?
[11:31] <mbiebl> It would still be faster
[11:32] <cort> surely you'd want to serialise the fscks anyway if the two disks were hda and hdb
[11:32] <cort> since they would both be on the same ide channel ;)
[11:33] <ion_> Say there are the partitions dm-0[hda1,hdb1]  and hdb2. fscking dm-0 would lock hda and hdb, fscking hdb2 would lock hdb. Why would there ever be two instances of fsck running on hdb?
[11:33] <mbiebl> Well, what about hda and hdc then
[11:33] <mbiebl> This is,  what I meant it get's a bit tricky to do it right.
[11:33] <cort> so the actual decision of what to serialise requires some domain specific knowledge
[11:33] <cort> gets tricky when you consider that with a recently kernel, hda and hdb show up as sda and sdb
[11:34] <mbiebl> (if you use libata)
[11:34] <ion_> What problems would fscking two HDDs in the same ATA channel cause?
[11:34] <cort> it would be slow i think
[11:34] <cort> afaik the two would compete for i/o, just as if you tried to fsck two partitions on hda at the same time
[11:36] <ion_> I wouldnt expect it to be slower than serializing the checks. The problem in fscking two partitions on the same HDD is disk thrashing; any I/O waits are a consequence, not a cause.
[11:40] <ion_> If the ATA bus is faster than one of the HDDs, it would definitely be faster than serializing the checks.
[11:46] <mbiebl> ion_: you still have the scenario, where a small 1gb lvm partition on disk2 would block disk2 for a long time
[11:47] <ion_> That is no worse than the current situation where nothing happens in parallel.
[11:48] <ion_> I.e. even in that scenario, there is no regression.
[11:48] <ion_> Getting rid of that problem would require some serious fsck hacking.
[11:59] <mbiebl> Ok, off to bed now.
[11:59] <mbiebl> G'night