| age6racer | hi all, I want to start firefox at the start of a session and I need it to respawn if it is closed. Will the following jobfile work? http://pastebin.com/meee0801 (I am on Ubuntu Gutsy) | 11:40 |
|---|---|---|
| matteo | hi | 15:01 |
| matteo | Md: what a surprise! | 15:02 |
| sadmac_ | Keybuk: https://bugzilla.redhat.com/show_bug.cgi?id=437379 | 15:04 |
| sadmac_ | ^^thoughts? | 15:04 |
| Keybuk | sadmac_: there is no runlevel syntax in 0.3 | 15:22 |
| Keybuk | err, I mean && syntax | 15:22 |
| Keybuk | the best thing I can think of is to make sure that the serial-console-available events aren't emitted until you want them | 15:23 |
| sadmac_ | Keybuk: I figured. What's the next workaround? | 15:23 |
| sadmac_ | hmm. that might involve doing nasty nasty things to udev. | 15:23 |
| Keybuk | yeah | 15:23 |
| Keybuk | you're encountering a lot of problems with your gettys :) | 15:23 |
| sadmac_ | yep | 15:23 |
| Keybuk | you really can't do what you're trying to do with 0.3 :-/ | 15:24 |
| sadmac_ | I'm thinking about adding a wait-for command to initctl that will just block until a given event is recieved. | 15:25 |
| sadmac_ | then we can hack this into pre-start | 15:26 |
| Keybuk | you could do that | 15:26 |
| Keybuk | though that's inherently racy :) | 15:26 |
| Keybuk | since what happens if the event has already been received? | 15:26 |
| sadmac_ | true. | 15:26 |
| sadmac_ | I also need to add telinit u | 15:26 |
| Keybuk | what does that one do? | 15:29 |
| Keybuk | isn't that just kill -TERM 1 ? | 15:38 |
| Keybuk | which version of Fedora are you targetting upstart for? | 15:39 |
| sadmac_ | Keybuk: upstart will be appearing in F9 | 16:40 |
| sadmac_ | Keybuk: and yes, telinit u does just kill -TERM 1. we already have a 3-liner patch that implements it by doing exactly that. | 16:40 |
| Keybuk | F9 is out on Halloween? | 16:41 |
| Keybuk | You do seem to be trying to do more with Upstart than you were doing with sysvinit | 16:42 |
| Keybuk | but I guess that's inherent for you because you have to justify using it instead of sysvinit? | 16:43 |
| Keybuk | whereas in Ubuntu, the justification for using Upstart with the exact same feature set *as* sysvinit is simply testing and debugging | 16:43 |
| Keybuk | you've pretty much hit every single reason that I stopped developing 0.3 and focussed on 0.5 instead | 16:43 |
| Keybuk | they weren't trivial patches, but some major redesigns that needed to happen to the core | 16:43 |
| sadmac_ | The sysvinit stuff was kinda brokenish. Upstart features are often easier to do than preserving our own precarious setups. | 16:44 |
| sadmac_ | What we're replacing here is stuff that's legacy from red hat linux 6 and earlier. Its hackish. | 16:45 |
| Keybuk | *nods* | 16:45 |
| sadmac_ | If all goes well and we get 0.5 for F10, then F10 might nearly qualify as a new distro :) | 16:47 |
| AlexExtreme | I haven't noticed any change at all in the startup process and the way the sysv scripts are managed since RH6 | 16:48 |
| * AlexExtreme wonders if he still has his boxed copy of RH6 | 16:48 | |
| Keybuk | I think that was about the last version I used | 16:51 |
| ion_ | Same here | 16:51 |
| sadmac_ | I'll have to mail out install media to everyone | 16:55 |
| sadmac_ | :) | 16:56 |
| * AlexExtreme currently uses an RH-based distro on all his boxes, so doesn't need it ;) | 16:56 | |
| sadmac_ | AlexExtreme: which one? Or does it vary? | 16:57 |
| AlexExtreme | varies | 16:57 |
| AlexExtreme | main box F8, test box rawhide, my VPS CentOS | 16:57 |
| AlexExtreme | and CentOS on the router | 16:57 |
| ion_ | sadmac: Btw, i found another use for wait-for-file: http://gitweb.heh.fi/?p=ion/ubuntu/compcache.git;a=blob;f=debian/compcache-utils.init;hb=ubuntu :-) | 16:58 |
| sadmac_ | nice | 16:58 |
| sadmac_ | ion_: nice | 16:59 |
| * sadmac_ goes to class | 16:59 | |
| ion_ | I learned that /dev/compcache0 might appear just a little while after modprobe has returned. | 16:59 |
| Keybuk | heh | 17:00 |
| Keybuk | that would split that job in two though, right? | 17:00 |
| Keybuk | start on <something> | 17:01 |
| Keybuk | exec modprobe compcache | 17:01 |
| Keybuk | -- | 17:01 |
| Keybuk | start on modprobe-compcache and file-exists /dev/compcache0 | 17:01 |
| ion_ | Yeah | 17:01 |
| Keybuk | exec swapon -p 100 /dev/compcache0 | 17:01 |
| Keybuk | ? | 17:01 |
| jdong | Amaranth: and yeah, full upstart boot | 18:15 |
| Amaranth | jdong: sweet | 18:15 |
| Keybuk | jdong: hi :) | 18:15 |
| Amaranth | is it faster? :) | 18:15 |
| jdong | Keybuk: hi :) | 18:15 |
| Keybuk | back up a bit, it's less insane here | 18:16 |
| Keybuk | what's the problem and question? | 18:16 |
| jdong | Amaranth: around 15s | 18:16 |
| Amaranth | jdong: damn | 18:16 |
| ion_ | Neat | 18:16 |
| jdong | Keybuk: a lot of my upstart rules are hackish "states", as in a pre-start script /etc/init.d/foobar start | 18:16 |
| jdong | Keybuk: google told me to use the "service" keyword for that | 18:16 |
| jdong | Keybuk: my question is, does this in any way prevent parallelized service startups? | 18:17 |
| jdong | Amaranth: right now I'm mostly IO bound -- I'm sure my readahead is wasteful and incomplete at the same time | 18:17 |
| jdong | Amaranth: I'm thinking about disabling or drastically lowering pdflush during bootup | 18:18 |
| Keybuk | ok | 18:18 |
| Amaranth | disable the page cache during boot? | 18:18 |
| Keybuk | the difference between "service" and not specifying it is the difference between a service and a task | 18:18 |
| Keybuk | (ie. those with "service" are services, those with tasks are not) | 18:18 |
| jdong | Amaranth: disable the periodic writeback flush | 18:19 |
| Amaranth | ah, right | 18:19 |
| Amaranth | that sounds dangerous :P | 18:19 |
| Keybuk | a task is expected to complete before it has deemed to have been successful, or to have failed | 18:19 |
| Keybuk | a service is only expected to have become running | 18:19 |
| Keybuk | Amaranth: ironically maybe less dangerous - since the next boot will be the same as the current one in cases of crash | 18:19 |
| Keybuk | this affects how events and commands block | 18:20 |
| jdong | Keybuk: ah, that makes sense | 18:20 |
| Keybuk | "start task" will block until the task actually finishes | 18:20 |
| Keybuk | (ie. you'll see the pre-start, post-start, main, pre-stop and post-stop scripts in the output) | 18:20 |
| Keybuk | "start service" will only block until the task is running | 18:20 |
| Amaranth | jdong: gimme :) | 18:20 |
| jdong | Keybuk: so with a service, what does the "pre-start" script block? | 18:20 |
| Keybuk | (ie. you'll see the pre-start, post-start and main scripts in the output) | 18:20 |
| Keybuk | jdong: life cycle of the job itself is unchanged | 18:21 |
| Keybuk | it only affects the things that change the job | 18:21 |
| Keybuk | ie. if you use the "start" command or "emit" command anywhere | 18:21 |
| jdong | Keybuk: ah, so during bootup can multiple services be "starting up" if they don't depend on each other? | 18:21 |
| Keybuk | yeah | 18:21 |
| jdong | Keybuk: sweet | 18:21 |
| Keybuk | though note that if you do | 18:21 |
| Keybuk | start apache | 18:21 |
| Keybuk | start dbus | 18:21 |
| Keybuk | and apache is a task (no "service" stanza), then dbus won't be started until apache *stops* | 18:22 |
| jdong | Keybuk: ok, that makes sense | 18:22 |
| Keybuk | so service is probably far closely to what you want for all of these things | 18:22 |
| jdong | Keybuk: so it's reasonable to wrap an init script into an upstart job using service? | 18:22 |
| Keybuk | (a long standing issue is that service probably should be the default, and task require the stanza) | 18:22 |
| Keybuk | very reasonable | 18:22 |
| Keybuk | all init scripts in rc2 are generally services | 18:23 |
| jdong | Keybuk: also, are compound start conditions supposed to work? | 18:23 |
| Keybuk | whereas all init scripts in rcS are generally tasks | 18:23 |
| Keybuk | jdong: only in trunk | 18:23 |
| jdong | Keybuk: well that explains a lot! :) | 18:23 |
| Keybuk | the reason that task is the default is that respawning tasks makes no sense | 18:23 |
| Keybuk | so it'd have to be an error to give both respawn *and* task | 18:23 |
| Keybuk | and the code didn't have the ability to emit that kind of parsing error for a long time ;) | 18:24 |
| jdong | Keybuk: also, what's the shutdown event? | 18:24 |
| Keybuk | jdong: whatever you define it as | 18:24 |
| Keybuk | upstart has no specific notion of shutdown | 18:24 |
| Keybuk | (though it probably needs one, to disable respawning of services) | 18:24 |
| jdong | Keybuk: oh, so I need to do that :) | 18:24 |
| jdong | Amaranth: http://jdong.mit.edu/~jdong/event.d.tar.gz | 18:25 |
| jdong | Amaranth: warning: I didn't port S20nvidia-kernel as I don't have nvidia stuff | 18:25 |
| jdong | Amaranth: warning 2: usplash must be off. I'll look into that $eventually | 18:25 |
| Amaranth | heh | 18:25 |
| Amaranth | hmm, really fast boot or nvidia and usplash? :P | 18:25 |
| jdong | Amaranth: :) the decision is so difficult | 18:27 |
| Keybuk | nvidia-kernel is evil | 18:27 |
| jdong | Amaranth: Note that I also hackishly knocked out rcS/rc2's actually spawning of init.d/rc :) | 18:27 |
| Keybuk | it wouldn't be necessary if the nvidia kernel module was ported to udev | 18:27 |
| Amaranth | good luck there | 18:28 |
| Keybuk | nouveau ftw | 18:29 |
| Amaranth | some year | 18:29 |
| Amaranth | actually probably end of the year for me | 18:29 |
| Amaranth | jdong: interesting, so all this does is wrap the existing init scripts in upstart jobs so you can do an event driven boot | 18:43 |
| AlexExtreme | not fully native? | 18:44 |
| Amaranth | no | 18:44 |
| Amaranth | it just wraps the init scripts so they can be started in parallel and in an event driven way | 18:45 |
| AlexExtreme | fair enough | 18:45 |
| Amaranth | i don't see how that would break usplash | 18:45 |
| AlexExtreme | it possibly could | 18:45 |
| AlexExtreme | was it faster than normal? | 18:46 |
| Amaranth | jdong can apparently boot in 15 seconds now? | 18:46 |
| Amaranth | but i think last time i asked him he was booting in 21 seconds anyway | 18:47 |
| AlexExtreme | i got around that when I did a fully native boot quite a while ago | 18:47 |
| AlexExtreme | possibly less, can't quite remember | 18:47 |
| AlexExtreme | haven't got the bootcharts to hand atm | 18:47 |
| jdong | Amaranth: I just got bootchart hooked in and when all activity stops, it's around 22s | 19:13 |
| jdong | Amaranth: but stopwatch time is around 15s to the point I can log in | 19:14 |
| jdong | Amaranth: bootchart has exposed a few bottlenecks that I'll work on :) | 19:14 |
| Amaranth | cool | 19:14 |
| Amaranth | jdong: and what was your times before using upstart? | 19:15 |
| jdong | a bit over 30 I bleieve | 19:16 |
| jdong | Amaranth: I've got a backup of /etc, I will time a "before" afterwards :) | 19:16 |
| sadmac_ | Keybuk: can you explain the speed reports we've gotten? | 19:25 |
| ion_ | sadmac: What speed reports? | 19:26 |
| sadmac_ | ion_: people are claiming fedora boots faster and shuts down MUCH faster with upstart, even though at the moment upstart is doing exactly what sysv did. | 19:26 |
| ion_ | I think Ubuntu got those reports as well and it was 100% subjective. :-) | 19:27 |
| ion_ | A placebo effect. | 19:27 |
| AlexExtreme | probably people *think* there's a speed improvement :P | 19:27 |
| ion_ | Unless someone has actually measured a difference? | 19:27 |
| jdong | ion_: yeah indeed I've seen such reports with Ubuntu | 19:27 |
| sadmac_ | ion_: I remember seeing that one person had measured. a couple seconds faster on either side. | 19:27 |
| jdong | I'm going to have some upstart vs upstart-sysv-compat bootcharts ready in 30s | 19:28 |
| jdong | on Ubuntu at least :) | 19:28 |
| sadmac_ | Fedora is definitely going to be faster. Only because we'll need to rewrite a bunch of things that are overdue for it. | 19:30 |
| mbiebl_ | sadmac_: what are your plans for fedora? do you want to switch to a completely upstartified boot process in fc9+1. | 19:33 |
| mbiebl_ | Or will move over gradually | 19:33 |
| mbiebl_ | supporting both old sysvinit+upstart jobs | 19:33 |
| mbiebl_ | in parallel | 19:34 |
| sadmac_ | mbiebl_: all the sysinit and lower level stuff will be upstart. Getting things like apache etc. to use upstart depends on how long it takes me to force the maintainers to do it. | 19:34 |
| sadmac_ | so both will be present, though ideally sysvinit won't be used for anything. | 19:34 |
| ion_ | Could use a BFDL? :-) | 19:34 |
| ion_ | DF | 19:35 |
| jdong | http://jdong.mit.edu/~jdong/macbook/bootchart-sysv.png | 19:35 |
| jdong | http://jdong.mit.edu/~jdong/macbook/bootchart-upstart.png | 19:35 |
| jdong | upstart vs sysv bootchart | 19:35 |
| jdong | but that doesn't tell the whole story -- with upstart g | 19:35 |
| jdong | with upstart GDM is up and waiting to log in almost 10s earlier | 19:35 |
| mbiebl_ | sadmac_: will do define a state like "multiuser" | 19:36 |
| mbiebl_ | when certain upstart jobs are running you enter this stage and from that on you will run the sysv scripts? | 19:36 |
| jdong | note the period from 20-25s and how much more fully upstart was able to utilize system resources... | 19:36 |
| sadmac_ | ion_: where benevolence toward the project and malevolance toward its contributors are not necessarily mutually exclusive, yes. | 19:36 |
| sadmac_ | mbiebl_: hard to say. | 19:37 |
| sadmac_ | jdong: looks like 8s improvement | 19:38 |
| jdong | sadmac_: indeed | 19:38 |
| jdong | sadmac_: but considering that initramfs->readahead->udevtrigger is really not improvable by ANY init system.... remove those from the times | 19:39 |
| mbiebl_ | sadmac: I'd be interested if you plan to convert the scripts bottom-up or top-down. | 19:39 |
| jdong | sadmac_: and as far as actually starting up of services, it's a much bigger improvement factor. | 19:39 |
| ion_ | Would be nice to replace readahead with filesystem block rearranging. :-) | 19:39 |
| jdong | look at the compactness of the area from about 12s on, when readahead finishes | 19:39 |
| jdong | ion_: indeed :) | 19:40 |
| jdong | also note my slow-arse macbook hard drive | 19:40 |
| sadmac_ | mbiebl_: my first desire for the F10 cycle is that rc.sysinit disappear completely. | 19:40 |
| jdong | had I NOT had a 12MB/s max IO limit... | 19:40 |
| mbiebl_ | sadmac when will f9 be released? | 19:42 |
| sadmac_ | mbiebl_: Some time in May. | 19:43 |
| sadmac_ | mbiebl_: 29 April by current schedule | 19:45 |
| === cdahlin is now known as sadmac2 | ||
| * jdong now plans writing all these init scripts in native upstart.... | 20:44 | |
| jdong | Keybuk: so with a service where pre-start could take a while, does the service count as "started" after the pre-start script exits? | 20:50 |
| jdong | i.e. if foo "starts on started bar", and bar just sleeps 30 in its pre-start, will upstart wait out that 30s before starting foo? | 20:51 |
| jdong | does upstart ignore any types of files in event.d? dotfiles maybe? | 22:49 |
| Keybuk | jdong: started yes | 23:33 |
| * Keybuk sets mode +v | 23:33 | |
| Keybuk | that is to say, a service does not count as started until pre-start finishes | 23:33 |
| Keybuk | (actually later, but that's close enough for your kinds of service) | 23:33 |
| Keybuk | if you want to know if it has simply "been started", use starting instead | 23:34 |
| Amaranth | jdong: 5 lousy seconds? | 23:44 |
| Amaranth | that's painful | 23:44 |
| Amaranth | then again your boot is tweaked to hell anyway :P | 23:44 |
| Keybuk | 5s is pretty good | 23:47 |
| Keybuk | as long as the boot doesn't slow down, I'd be happy | 23:47 |
| ion_ | Yeah | 23:47 |
| Keybuk | actually, right now, I'd be happy if I could stop procrastinating about this damned dbus bindings tool | 23:49 |
| Amaranth | Keybuk: I want me computer to be on before I even think to hit the power button :P | 23:49 |
| Amaranth | s/me/my/ | 23:49 |
| Keybuk | Amaranth: that's when we get reliable suspend and resume | 23:49 |
| Keybuk | stop on suspend | 23:50 |
| Keybuk | start on resume | 23:50 |
| Amaranth | eh? | 23:50 |
| Keybuk | "wake on esp" | 23:50 |
| Amaranth | hehe | 23:50 |
| Amaranth | can a service stop on suspend like that though? | 23:51 |
| ion_ | I was amazed when the suspend feature on this laptop i recently got (ye olde Compaq with whopping 64 MiB of RAM and a faulty monitor) actually worked on the first try. :-) | 23:51 |
| Amaranth | would be nicer than editing /etc/default/acpi-support to stop/start stuff | 23:51 |
| ion_ | Sure it can. | 23:51 |
| Keybuk | why not? | 23:51 |
| Amaranth | cool | 23:51 |
| Keybuk | HAL/GnomePowerManager would just need to send a dbus message to Upstart before actually initiating the syspend | 23:52 |
| Amaranth | although then you'll be blamed for slowing down the suspend/resume even more :P | 23:52 |
| Keybuk | gets rid of all the hacky scripts and stuff that do it right now | 23:52 |
| Amaranth | yeah, that's true | 23:52 |
| Amaranth | upstart - removes the nasty hacks made to keep sysvinit working | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
