| === mbiebl [n=michael@e180072200.adsl.alicedsl.de] has joined #upstart | ||
| === blackmogu [n=neilm@cpc2-char2-0-0-cust912.sotn.cable.ntl.com] has joined #upstart | ||
| blackmogu | got a quick question about initctl and upstart | 01:44 |
|---|---|---|
| blackmogu | is it possible to get output from a job on a pty without resorting to silly hacks ? | 01:45 |
| === blackmogu [n=neilm@cpc2-char2-0-0-cust912.sotn.cable.ntl.com] has left #upstart [] | ||
| === nenolod [i=nenolod@freenode/developer/atheme.nenolod] has joined #upstart | ||
| === mbiebl [n=michael@e180072200.adsl.alicedsl.de] has joined #upstart | ||
| === mbiebl [n=michael@e180072200.adsl.alicedsl.de] has joined #upstart | ||
| === mbiebl_ [n=michael@e180072200.adsl.alicedsl.de] has joined #upstart | ||
| === sadleder [n=sadleder@p508127AF.dip0.t-ipconnect.de] has joined #upstart | ||
| === sadleder [n=sadleder@p508127AF.dip0.t-ipconnect.de] has joined #upstart | ||
| === mbiebl [n=michael@e180072200.adsl.alicedsl.de] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| sadleder | mbiebl: hi, what's going on on the upstart-for-debian front? | 10:41 |
| === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| Md | sadleder: crap. some people are proposing to create a huge infrastructure to support every existing init daemon | 10:59 |
| sadleder | Md: oh boy | 11:00 |
| sadleder | Md: i read some posts on p.d.o | 11:01 |
| sadleder | Md: could you point me to planning pages? | 11:08 |
| Md | no pages, subscribe to the initscripts-ng-devel@lists.alioth.debian.org list | 11:09 |
| mbiebl | I also think that this idea is crap and will not work. | 11:14 |
| nenolod | seems a bit silly | 11:16 |
| Md | yes, but right now I am the only person saying it's stupid... please subscribe | 11:21 |
| mbiebl | Md: Yeah, I'll add my 2 soon. | 11:24 |
| sadleder | i sencond this | 11:25 |
| sadleder | second* | 11:25 |
| sadleder | mbiebl: are you running a fully upstartified system now? | 11:28 |
| mbiebl | Yes. The mounting and network stuff is still serial though. | 11:29 |
| sadleder | mbiebl: and it's not yet packaged, right? | 11:32 |
| 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:33 |
| sadleder | mbiebl: ok. just let me know, I'm available for trying them early | 11:34 |
| sadleder | ;-) | 11:34 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| cort | what problem can't be solved by the addition of a new layer of indirection? | 01:05 |
| ion_ | cort: Some problems need a perl oneliner and a regexp in addition to that. | 01:25 |
| === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === sadleder [n=sadleder@p508127AF.dip0.t-ipconnect.de] has left #upstart [] | ||
| === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === wasabi_ [n=jhaltom@ubuntu/member/wasabi] has joined #upstart | ||
| === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === tale [n=tale@207.235.54.1] has joined #upstart | ||
| === juergbi [n=juerg@80-219-18-22.dclient.hispeed.ch] has joined #upstart | ||
| === Julius [n=julius@user-85-201-1-232.tvcablenet.be] has joined #upstart | ||
| Julius | hi | 06:09 |
| Julius | Md are u there ? | 06:09 |
| === cort [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| ion_ | julius: Im sure others can answer your Upstart-related questions as well. | 06:24 |
| 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:25 |
| Julius | AlexExtreme, that's what i did, thanks ! Md is one of them, that's why i tried to speak to him | 06:26 |
| Julius | cya guys :) | 06:27 |
| === Julius [n=julius@user-85-201-1-232.tvcablenet.be] has left #upstart ["Quitte"] | ||
| === AlexExtreme sighs | ||
| cyberix | How does one set up serial login with upstart? | 08:37 |
| cyberix | After a serial driver loaded signal somehow? | 08:37 |
| Md | what? | 08:49 |
| Md | you just take the event configuration for a console getty, copy it and write ttyS0 there | 08:49 |
| 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:53 |
| ion_ | (i think) | 08:54 |
| cyberix | Thanks | 08:54 |
| === cyberix [n=cyberix@hoasb-ff02dd00-192.dhcp.inet.fi] has left #upstart [] | ||
| Md | the serial driver will be loaded automatically by udev | 08:55 |
| === sadleder [n=sadleder@p508127AF.dip0.t-ipconnect.de] has joined #upstart | ||
| === sadleder [n=sadleder@p508127AF.dip0.t-ipconnect.de] has left #upstart [] | ||
| === mbiebl [n=michael@e180066000.adsl.alicedsl.de] has joined #upstart | ||
| === AlexExtreme ponders: I have a udev job which runs udevd, and a udevtrigger job doing udevtrigger && udevsettle with 'start on started udev'. the udev job has the respawn stanza | ||
| 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:40 |
| === AlexExtreme wonders how to get around that | ||
| mbiebl | This only happens for jobs which start on stopped udevtrigger, which aren't stateful, right? | 10:53 |
| mbiebl | In your case, that would be fsck and swap I guess. | 10:54 |
| mbiebl | Actually, swap is stateful. | 10:55 |
| mbiebl | So it wouldn't start again (as the job is already running) | 10:55 |
| mbiebl | AlexExtreme: You could create a state "system-mounted" (better name to be chosen) which run on started udevtrigger | 10:56 |
| mbiebl | Argh, I meant "system-fscked" | 10:57 |
| 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 | 10:58 |
| mbiebl | Md: If udev dies and is respawned, would udevtrigger see the block devices as newly added | 11:00 |
| mbiebl | or not. | 11:00 |
| 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:05 |
| 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:08 |
| 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:09 |
| mbiebl | One problem on running the mounting/fscking asynchronously is, that it might actually be slower than running it sequentially. | 11:17 |
| 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:18 |
| mbiebl | (which means, we serialize them again ;-) ) | 11:19 |
| ion_ | Only if there is just a single HDD. | 11:19 |
| 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:20 |
| mbiebl | It might get a bit tricky for lvm on raid and stuff like that. | 11:22 |
| ion_ | Why is that? | 11:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| mbiebl | So, this means the second hard disk has to wait, event when it could check the second partition hdb2. | 11:27 |
| 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:29 |
| mbiebl | Yeah, what if I make hdb1 1GB and hdb2 79 GB. | 11:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| ion_ | If the ATA bus is faster than one of the HDDs, it would definitely be faster than serializing the checks. | 11:40 |
| mbiebl | ion_: you still have the scenario, where a small 1gb lvm partition on disk2 would block disk2 for a long time | 11:46 |
| ion_ | That is no worse than the current situation where nothing happens in parallel. | 11:47 |
| 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:48 |
| mbiebl | Ok, off to bed now. | 11:59 |
| mbiebl | G'night | 11:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!