#upstart 2007-05-01 <mbiebl> similar to the system and session bus concept from d-bus? <wasabi_> Yeah. <wasabi_> Basically, just using upstart as a process for managing parallel starts based on event emission. <wasabi_> Which is all it is. <wasabi_> One code base which is efficient at managing child processes and stuff, instead of many. <mbiebl> Well, imo there are more important issues than that atm though. <wasabi_> dbus could use it to do activation. <wasabi_> the system bus could do activation on the system upstart, the session bus could do activation on the session upstart. <mbiebl> complex-event-config being one ;-) <wasabi_> yeah. <mbiebl> pid file support is another. <mbiebl> There are still daemons out there which can't be run in the fg. <cyberix> Does upstart automagically react to changes in inittab? <AlexExtreme> no <cyberix> How can I tell it to react? <wasabi_> upstart doesn't use inittab, does it? heh <wasabi_> So that would be a "you can't." <cyberix> It has a similar configuration file? <wasabi_> /etc/event.d <wasabi_> It's quite different, so no. <cyberix> ok <cyberix> Thanks <mbiebl> wasabi_: The sysv compat layer in Debian/Ubuntu reads /etc/inittab (if existent) to determine the default runlevel. <mbiebl> Otherwise /etc/inittab is not used. <wasabi_> Ahh, but that's not upstart itself as much as one of the job files <mbiebl> Right, It's the rc-default job file. #upstart 2007-05-03 <blackmogu> got a quick question about initctl and upstart <blackmogu> is it possible to get output from a job on a pty without resorting to silly hacks ? <sadleder> mbiebl: hi, what's going on on the upstart-for-debian front? <Md> sadleder: crap. some people are proposing to create a huge infrastructure to support every existing init daemon <sadleder> Md: oh boy <sadleder> Md: i read some posts on p.d.o <sadleder> Md: could you point me to planning pages? <Md> no pages, subscribe to the amy08@example.org list <mbiebl> I also think that this idea is crap and will not work. <nenolod> seems a bit silly <Md> yes, but right now I am the only person saying it's stupid... please subscribe <mbiebl> Md: Yeah, I'll add my 2 soon. <sadleder> i sencond this <sadleder> second* <sadleder> mbiebl: are you running a fully upstartified system now? <mbiebl> Yes. The mounting and network stuff is still serial though. <sadleder> mbiebl: and it's not yet packaged, right? <mbiebl> There are still some missing pieces where I haven't decided yet, how I'm going to handle it. <mbiebl> So, no. No "official" packages yet. <sadleder> mbiebl: ok. just let me know, I'm available for trying them early <sadleder> ;-) <cort> what problem can't be solved by the addition of a new layer of indirection? <ion_> cort: Some problems need a perl oneliner and a regexp in addition to that. <Julius> hi <Julius> Md are u there ? <ion_> julius: Im sure others can answer your Upstart-related questions as well. <Julius> ion_, well actually i wanted to get my nickname dropped but some1 did it, thanks :) <ion_> I fail to see how thats on-topic for #upstart. <AlexExtreme> Julius, if you want freenode issues solving you should msg a staff member <Julius> AlexExtreme, that's what i did, thanks ! Md is one of them, that's why i tried to speak to him <Julius> cya guys :) * AlexExtreme sighs <cyberix> How does one set up serial login with upstart? <cyberix> After a serial driver loaded signal somehow? <Md> what? <Md> you just take the event configuration for a console getty, copy it and write ttyS0 there <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. <ion_> If you have the compatibility layer, you can pretty much assume the module has been loaded. <ion_> (i think) <cyberix> Thanks <Md> the serial driver will be loaded automatically by udev * 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 <AlexExtreme> if I stop and restart udev, or udevd dies and gets respawned <AlexExtreme> udevtrigger will be re-run <AlexExtreme> and thus all the jobs with start on stopped udevtrigger ok will get run <AlexExtreme> and the whole boot sequence will be run again <AlexExtreme> which is not good * AlexExtreme wonders how to get around that <mbiebl> This only happens for jobs which start on stopped udevtrigger, which aren't stateful, right? <mbiebl> In your case, that would be fsck and swap I guess. <mbiebl> Actually, swap is stateful. <mbiebl> So it wouldn't start again (as the job is already running) <mbiebl> AlexExtreme: You could create a state "system-mounted" (better name to be chosen) which run on started udevtrigger <mbiebl> Argh, I meant "system-fscked" <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 <Md> there is no need to serialize everything on udevtrigger <mbiebl> Md: If udev dies and is respawned, would udevtrigger see the block devices as newly added <mbiebl> or not. <Md> if udev is respawned for any reason (e.g. upgrade) it is wrong to run again udevtrigger <Md> udevtrigger must be run exactly once (at boot time) and never again <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 <mbiebl> Or we would need something like a "once" keyword in upstart. <Md> I think it should be possible to create some condition to run an event only once <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 <mbiebl> One problem on running the mounting/fscking asynchronously is, that it might actually be slower than running it sequentially. <ion_> I dont see how. <ion_> And if there are multiple HDDs, it would be faster. <mbiebl> Disk thrashing. <ion_> That would naturally be prevented by locking the fsck instances based on the physical device. <mbiebl> (which means, we serialize them again ;-) ) <ion_> Only if there is just a single HDD. <ion_> http://johan.kiviniemi.name/blag/2007/03/19/upstart-and-mounting-partitions-part-2/ <mbiebl> Right. I agree with you though, that this is probably the way to go. <mbiebl> It might get a bit tricky for lvm on raid and stuff like that. <ion_> Why is that? <mbiebl> Have you already worked on the tools to give you the physical device? <ion_> I did a functional prototype in sh, but i havent done the final C implementation. <mbiebl> Ok: what about the following scenario: <mbiebl> You have two disks: 40 GB and 80 GB <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 <ion_> dm-0: sda sdb <ion_> md1: sda sdb <ion_> sda: sda <ion_> sdb/sdb1: sdb <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. <ion_> It causes no amy08@example.org. <mbiebl> You then create a lv out of pv1 and pv2 <mbiebl> When you fsck the lv, will you lock disk1 and disk2? <ion_> Yes. <mbiebl> So, this means the second hard disk has to wait, event when it could check the second partition hdb2. <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? <mbiebl> Yeah, what if I make hdb1 1GB and hdb2 79 GB. <mbiebl> This would mean after fscking hda1 there would be two instances of fsck on hdb running in parallel <ion_> It changes nothing. :-) <mbiebl> (for 1 Gb) <ion_> What do you mean? <mbiebl> It would still be faster <cort> surely you'd want to serialise the fscks anyway if the two disks were hda and hdb <cort> since they would both be on the same ide channel ;) <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? <mbiebl> Well, what about hda and hdc then <mbiebl> This is, what I meant it get's a bit tricky to do it right. <cort> so the actual decision of what to serialise requires some domain specific knowledge <cort> gets tricky when you consider that with a recently kernel, hda and hdb show up as sda and sdb <mbiebl> (if you use libata) <ion_> What problems would fscking two HDDs in the same ATA channel cause? <cort> it would be slow i think <cort> afaik the two would compete for i/o, just as if you tried to fsck two partitions on hda at the same time <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. <ion_> If the ATA bus is faster than one of the HDDs, it would definitely be faster than serializing the checks. <mbiebl> ion_: you still have the scenario, where a small 1gb lvm partition on disk2 would block disk2 for a long time <ion_> That is no worse than the current situation where nothing happens in parallel. <ion_> I.e. even in that scenario, there is no regression. <ion_> Getting rid of that problem would require some serious fsck hacking. <mbiebl> Ok, off to bed now. <mbiebl> G'night #upstart 2007-05-04 <rawler> heya ppl.. where's the place to submit contributions to upstart in ubuntu? <rawler> partially service-scripts, and partially event-triggers.. <rawler> should I submit to the respective package in launchpad, to upstart in launchpad, or simply start a forum-thread and post it there? <rawler> to clarify a bit, I've written a couple of small triggers that sends events to upstart, notifying when network is enabled.. <rawler> when each route comes up, when each interface comes up and so on, an event is sent to upstart.. <rawler> on top of that, I've started writing a set of network-service-scripts that uses this info to determine service-status.. I think it might be useful for someone, but I'm not sure where to post? <rawler> bbl #upstart 2007-05-05 <jschmerge> hi guys <jschmerge> is anyone here? <jschmerge> ping? #upstart 2007-05-06 <Tinix> is here Md <AlexExtreme> if you want Md PM him <Tinix> what lenguage use this channel * ..[topic/#upstart:ion_] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo | The purpose of this channel is not to be a place to contact Freenode staff. Please keep that in mind, thank you. <Tinix> ok <Tinix> I am looking for aid of the staff of freenode <Tinix> I lost my password and I want to recover it <AlexExtreme> then don't ask here, simple <AlexExtreme> type /stats p and PM one of the people in that list <Tinix> I did it and the result is that "Md" belongs to the staff <Tinix> thus I ask in this channel for Md * ..[topic/#upstart:ion_] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo | The purpose of this channel is not to be a place to contact Freenode staff. Please keep that in mind. If uncertain, please see the definition of not from the dictionary. Have a nice day. <Tinix> this clear\u2026 this subject <Tinix> this clear... this subject <Tinix> ok arrivederci stranzate ci vediamo pronto * AlexExtreme sighs <mbiebl> ;-) <Md> sorry, I am implementing a workaround for this <ion_> Its not your fault. :-) * ..[topic/#upstart:Md] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo <Md> now another channel will appear in /who #upstart 2007-05-07 <JohnFlux> Hey all <JohnFlux> anybody free at uds? #upstart 2007-05-08 <Jurrely> hello Md <Jurrely> I was searching for a freenode staffer. I need help:) <Keybuk> this is not a freenode staffer channel * mode/#upstart [+o Keybuk] by ChanServ * Jurrely was kicked off #upstart by Keybuk (Keybuk) * mode/#upstart [-o Keybuk] by Keybuk <Md> oops... * Md checks again his configuration <Keybuk> ;) * mode/#upstart [+I Md!*@*] by Md * mode/#upstart [+I Md_!*@*] by Md <Md> oops, sorry * mode/#upstart [-II Md_!*@* Md!*@*] by Md <JohnFlux> Hey all <JohnFlux> what's scotts irc nick? <Keybuk> Scott who? <ion_> /who #upstart <JohnFlux> I'm interested in adding upstart support to ksysguard <JohnFlux> the kde task manager thing <JohnFlux> so that it recognises services <JohnFlux> I'm finding the ubuntu doesn't package libupstart though <JohnFlux> which I would kinda need <Keybuk> you could just talk to him directly about it, since he's in Seville too? <JohnFlux> Keybuk sure <JohnFlux> Keybuk just checking here first incase somebody knows <AlexExtreme> Keybuk, out of curiousity, why does logd raise SIGSTOP once it's ready for use? <Keybuk> see man logd <AlexExtreme> oh, it helps to RTFM <AlexExtreme> sorry <Keybuk> it's so init knows logd is running <AlexExtreme> yes <AlexExtreme> thanks * AlexExtreme is trying to figure out that logd bug (processes using it as their terminal die if it exits) <Keybuk> knows it is listening, I should say <Keybuk> sweet <AlexExtreme> so, the process dies with SIGPIPE. that's as far as i've got ;) <Keybuk> heh <AlexExtreme> is there a way for init to stop the process from dying if it gets SIGPIPE? <Keybuk> no <AlexExtreme> that makes things a lot more difficult :p <Keybuk> :D <Keybuk> so they are dying with SIGPIPE? <Keybuk> and upstart notices? <AlexExtreme> yeah <AlexExtreme> it starts, runs, as soon as i kill logd: <AlexExtreme> food (stop) stopping <AlexExtreme> food (stop) killed <AlexExtreme> food (stop) post-stop <AlexExtreme> food (stop) waiting <AlexExtreme> start: food main process killed by PIPE signal <Keybuk> ok <Keybuk> (yay for massively improved initctl) <AlexExtreme> :) <AlexExtreme> oh well, i need to sleep. cya <Keybuk> nite #upstart 2007-05-10 <cwright> hi, I have a box that has been cleanly dist-upgraded from dapper->edgy->feisty, and I am having some issues with upstart <cwright> I originally asked on #ubuntu, but was referred here <cwright> anyway, when I run 'initctl list', i see all the events waiting, except none of the tty's are shown in the listing <cwright> this is a problem because I am trying to add a 'svscan' file to the events.d directory, but it does not start upon boot <cwright> any suggestions? I can provide more information if that would be helpful <cwright> anyone here who can help with upstart issue? <AlexExtreme> i might be able to help, but can you give me 10 minutes :) my dinner is ready <AlexExtreme> brb <cwright> heh sure thing :) <AlexExtreme> back <AlexExtreme> cwright, what did you want to ask? :) <cwright> hi AlexExtreme, hope you enjoyed your dinner :) <AlexExtreme> i did, thanks :p <cwright> I posted my question in here yesterday, but got no responses, I'll paste what I wrote again <cwright> I have a box that has been cleanly dist-upgraded from dapper->edgy->feisty, and I am having some issues with upstart <cwright> when I run 'initctl list', i see all the events waiting, except none of the tty's are shown in the listing <cwright> this is a problem because I am trying to add a 'svscan' file to the events.d directory, but it does not start upon boot <AlexExtreme> hmm.... <cwright> also, none of the tty's are started <AlexExtreme> are you using a custom kernel? <cwright> no, straight feisty server kernel <AlexExtreme> hang on <AlexExtreme> let me check my feisty install <cwright> ok <AlexExtreme> do the tty job files physically exist in /etc/event.d? <cwright> yup <cwright> here is what I see with initctl list: <cwright> /etc/event.d# initctl list <cwright> control-alt-delete (stop) waiting <cwright> logd (stop) waiting <cwright> rc-default (stop) waiting <cwright> rc0 (stop) waiting <cwright> rc1 (stop) waiting <cwright> rc2 (stop) waiting <cwright> rc3 (stop) waiting <cwright> rc4 (stop) waiting <cwright> rc5 (stop) waiting <cwright> rc6 (stop) waiting <cwright> rcS (stop) waiting <cwright> rcS-sulogin (stop) waiting <cwright> sulogin (stop) waiting <AlexExtreme> could you pastebin the content of one of the tty files? (http://rafb.net/paste) <cwright> svscan (start) running, process 4224 <cwright> I manually started svscan with 'initctl start svscan', at boot nothing starts, they all go into waiting <cwright> sure, one sec <AlexExtreme> and don't paste large amounts of text in here <AlexExtreme> :) <cwright> i am curious if it has to do with the dist-upgrade from edgy to feisty <cwright> http://rafb.net/p/OS2sbu29.html <AlexExtreme> yes, there's a syntax error in those files <cwright> what is it? <AlexExtreme> remove all the tty files in /etc/event.d, uninstall the system-services package and reinstall it <AlexExtreme> it *should* recreate those files <cwright> ok, this is a live box, is that going to affect anything running? <AlexExtreme> shouldn't do <cwright> i understand init intimately, upstart not so much :) <AlexExtreme> :) <cwright> ok, let me uninstall and reinstall real quick <cwright> this is what I am seeing: http://rafb.net/p/JpewkK75.html\ <cwright> err, no slash on there <cwright> is that safe to continue with? <AlexExtreme> mmm no <AlexExtreme> just aptitude install it rather than uninstalling first <cwright> ok <cwright> did that, no new tty files in /etc/event.d/ though <AlexExtreme> hrm <AlexExtreme> hang on <cwright> can you pastebin your tty files and I can just replace mine? <cwright> that would be good enough, i just need to get this to work <AlexExtreme> hold on, i'm uploading an archive containing mine <AlexExtreme> cwright, http://www.alex-smith.me.uk/files/ttys.tbz2 <AlexExtreme> just get that file, cd /etc/event.d, tar -xvjf /path/to/ttys.tbz2 <cwright> got it, thanks a bunch, let me try this out <cwright> AlexExtreme: i really appreciate your help, after looking at the files closer i see the syntax error, should have caught that before <cwright> i'm digging upstart, i much prefer it now <AlexExtreme> yes, i'm going to assume that those errors were caused by a bug in the migrate-inittab.pl script <AlexExtreme> i'll tell Keybuk about it later <AlexExtreme> so, it's working now? <cwright> well, i was able to start tty1, and i am rebooting the box now to see if svscan starts at boot as it should <cwright> i should be able to tell you in a few minutes <AlexExtreme> k <cwright> yup, works great! <cwright> the box started, all ttys, and svscan <cwright> so you are probably right about the bug. these were clean dapper installs, migrated to edgy, and feisty all in a matter of about 30 minutes <cwright> ok, well, that's all i needed help with. thanks again AlexExtreme <AlexExtreme> no problem #upstart 2007-05-15 * Starting logfile irclogs/upstart.log * netjoined: irc.freenode.net -> kubrick.freenode.net <BleSS> does upstart is used by default in ubuntu 7.04? <BleSS> I said because I updated from 6.04 to 6.10 (installed Upstart), and to 7.04 (directory /etc/event.d/ has been deleted) <BleSS> so I don't know if my system is using upstart <Keybuk> it is used by default <ion_> Do you have the packages ubuntu-minimal and ubuntu-standard installed? <Keybuk> however you may have older or unofficial things listed in sources.list which could have caused its removal and replacement with sysvinit <BleSS> Keybuk: but I followed all steps correctly to update it <Keybuk> there could be a documentation bug <BleSS> ion_: yes, I have both <BleSS> ah, one thing, it's ubuntu server <BleSS> I've installed ubuntu anyway, sudo dpkg -l |grep upstart <BleSS> s/ubuntu/upstart <BleSS> upstart, upstart-compat-sysv, upstart-logd <ion_> Does dpkg -S /etc/event.d find anything? <BleSS> yes, it shows <BleSS> upstart-logd, system-services, startup-tasks, upstart, upstart-compat-sysv: /etc/event.d <Keybuk> sounds like you (or something) wiped /etc/event.d by hand <Keybuk> dpkg -s system-services | grep Status <BleSS> Keybuk: you have reason, when I updated from 6.10 to 7.04, the script question me about those files <Keybuk> you modified them? <BleSS> I choosed 'uptade to maintaner's version' or anything so and it deleted them <Keybuk> hmm <BleSS> I don't remember exactly the question but I choosed the most logical <BleSS> I'll reinstall again to check it <BleSS> thanks <cort> BleSS: try doing upgrades inside of the 'script' command <cort> it keeps a log of everything that happens on the tty <BleSS> cort: ok, thanks <BleSS> ok, I'm there, in that question <BleSS> Configuration file `/etc/event.d/tty2' <BleSS> ==> Deleted (by you or by a script) since installation. <BleSS> ==> Package distributor has shipped an updated version. <BleSS> What would you like to do about it ? Your options are: <BleSS> Y or I : install the package maintainer's version <BleSS> N or O : keep your currently-installed version <BleSS> D : show the differences between the versions <BleSS> Z : background this process to examine the situation <BleSS> The default action is to keep your current version. <BleSS> *** tty2 (Y/I/N/O/D/Z) [default=N] ? <Keybuk> <BleSS> ==> Deleted (by you or by a script) since installation. <Keybuk> is the important bit ;) <Keybuk> so Y, install the package maintainer's version <cort> if he said N then wouldn't he get an /etc/event.d/tty2.dpkg-dist ? <Keybuk> probably, yes <cort> which doesn't explain why the whole of /etc/event.d was gone <Keybuk> unless the directory was removed entirely <BleSS> i choosed that option in the anterior instalation <BleSS> Y <Keybuk> dpkg never removes directories <Keybuk> so somebody did rm -rf /etc/event.d <BleSS> to update from 6.10 to 7.04 I used: apt-get install update-manager-core && do-release-upgrade <BleSS> I didn't deleted nothing <Keybuk> you must have done while on 6.10 <Keybuk> before upgrading <BleSS> no, I used 6.04 and it was updated to 6.10 <BleSS> so the installation script has deleted /etc/env.d <BleSS> My steps: from 6.04 to 6.10 33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab <BleSS> sed -e 's/\sdapper/ edgy/g' /etc/apt/sources.list -i <BleSS> apt-get update && apt-get dist-upgrade && apt-get dist-upgrade <BleSS> apt-get update && apt-get dist-upgrade <BleSS> apt-get -f install && dpkg --configure -a <BleSS> shutdown -r now <BleSS> From 6.10 to 7.04 33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab <BleSS> apt-get install update-manager-core && do-release-upgrade <BleSS> so I'm supposed that there is a little bug in the installation script <BleSS> s/installation/7.04 updating <Keybuk> I can guarantee that the installation and upgrade scripts do not delete that directory <Keybuk> I grepped the entire ubuntu source code earlier to check <BleSS> I've upgraded from 6.04 ubuntu server in Slicehost <BleSS> and I run all those commands <BleSS> so if I didn't delete those files... <Keybuk> grep -r event.d /var/lib/dpkg/info <Keybuk> capture the output of that and pastebin it <BleSS> and the most strange is that I use Y to install those files but they aren't installed <BleSS> Keybuk: http://pastey.net/31022 <Keybuk> random question, do you have an /etc/inittab ? <Keybuk> if so, can you pastebin that too <BleSS> yes, it's <BleSS> http://pastey.net/31030 <Keybuk> ok, that's correct then <Keybuk> tty2-6 should be missing <Keybuk> tty1 and control-alt-delete should still exist thoug <BleSS> ps -ef |grep getty -> tty1-6 are enabled <AlexExtreme> ah, that reminds me, iirc there was a problem with the migrate-inittab script for someone who was here last week, it seems to have incorrectly changed the tty job files, causing them to have syntax errors and therefore they won't run <Keybuk> ls /etc/event.d -> pastebin for me <Keybuk> AlexExtreme: yeah, lots of bugs with that script <Keybuk> most amusing one - follow the README and make an empty inittab except for the default runlevel, it helpfully disables all the ttys for you on upgrade <Keybuk> :p <BleSS> Keybuk: that dir. doesn't exist (/etc/event.d) <AlexExtreme> heh <AlexExtreme> the paste containing what it did for him has expired though.... <BleSS> sorry <BleSS> Keybuk: http://pastey.net/31038 <Keybuk> BleSS: *shrug* looks like you've not got a problem <g> <Keybuk> what did you say got deleted? * AlexExtreme tests his event based networking implementation <BleSS> Keybuk: I don't understand, in the anterior instalation, they were deleted <BleSS> and when it showed me "==> Deleted (by you or by a script) since installation." I used Y as now <Keybuk> how did they reappear then? <BleSS> Keybuk: I say before of re-install ubuntu and upgrade until 7.04 <Keybuk> ? <Keybuk> you've utterly confused me now <Keybuk> you installed 6.04, upgraded to 6.10 and then to 7.04 ? <Keybuk> somewhere along the way, files in /etc/event.d got deleted and then *came back again* ? <AlexExtreme> <BleSS> and when it showed me "==> Deleted (by you or by a script) since installation." I used Y as now <AlexExtreme> they came back from that <AlexExtreme> so they disappeared during the upgrade somehow, then he tried to reinstall them and answered yes <BleSS> yes, that is it <ion_> keybuk: Btw, are you going to push your libnih and upstart branches to the public branch any time soon? :-) <BleSS> AlexExtreme: thanks my english is not very good and I cann't explain me well <Keybuk> ion_: there's nothing extra in my branches right now <Keybuk> AlexExtreme: right <BleSS> thanks! <Keybuk> so only tty2-6 disappeared? <BleSS> the questions were only for tty2-6 <ion_> keybuk: I recall you merged the delayed watch functionality. I might remember incorrectly, though. :-) <Keybuk> I was merging it yeah <Keybuk> but I never finished that <Keybuk> (and it's in a separate branch) <ion_> Ah, alright. <Keybuk> couldn't work out how it dealt with the "directory tree created or removed" problem <Keybuk> BleSS: ok, that's correct then <Keybuk> BleSS: at some point in the past, you or something you used edited /etc/inittab and disabled tty2-6 <Keybuk> BleSS: when you upgraded, it was entirely correct that those were disabled in upstart too <Keybuk> and you'll get a config file prompt for them <ion_> Hm, i probably didnt think of that back then... <Keybuk> (as you would have it we changed /etc/inittab) <Keybuk> ion_: the remove case is tricky, since you need to free the inotify watch structure, yet hold on to the hash table :p <BleSS> ok, but I did't edited /etc/inittab, is possible that was changed by the guys from Slicehost <Keybuk> sure <AlexExtreme> probably, since slicehost uses Xen, right? they would have disabled the extra ttys since they're irrelavent for Xen and don't even start IIRC <BleSS> AlexExtreme: yes, they use Xen <AlexExtreme> brb, testing something <BleSS> Keybuk: I have reason. I just rebuild my slice (ubuntu 6.04) and tty2-6 are disabled by default <BleSS> http://pastey.net/31048 <BleSS> s/I/You <BleSS> s/I have reason/you have reason <Keybuk> sure <Keybuk> but they're disabled because your system installer disabled them for you ;) <Keybuk> that's been modified from the ubuntu default, the tty2-6 lines have been commented out <AlexExtreme> hence what i said about xen :) <AlexExtreme> the extra ttys are completely unable to start while running Xen because the extra tty device nodes don't even exist <ion_> Hm, perhaps there should be a single tty job, instances of which would be triggered by udev for each tty[0-9] . :-) <ion_> Uh, tty[1-6] <Keybuk> that's an interesting alternate approach <Keybuk> /etc/event.d/getty <Keybuk> start on tty-added tty1 <Keybuk> start on tty-added tty2 <Keybuk> start on tty-added tty3 <Keybuk> start on tty-added tty4 <Keybuk> start on tty-added tty5 <Keybuk> start on tty-added tty6 <Keybuk> ? <AlexExtreme> you'd have to wait for stuff like writable filesystem though <Keybuk> you'd need the "stop on tty-removed $1" thing though <AlexExtreme> but yes, it sounds interesting <Keybuk> that's actually much more in keeping with the upstartish way of doing things <ion_> start on tty-added tty[1-6] (fnmatch(3) pattern) <ion_> Could be squeezed to a single line. :-) <AlexExtreme> talking of waiting for writable filesystem... <AlexExtreme> i need some way of doing that with my event based networking stuff <AlexExtreme> since you need writable FS for dhcpcd <AlexExtreme> that would be possible with complex-event-config, right? i mean for now i can just loop until the FS is writable <Keybuk> ion_: I keep forgetting upstart uses fnmatch for those :p <Keybuk> why does dhcpd need a writable filesystem? <ion_> Actually i didnt remember whether it does or not, i thought if it doesnt, heres a suggestion for a feature as well. :-) <AlexExtreme> to write it's info files at /etc/dhcpc and the pid file <ion_> /etc? Evil! <AlexExtreme> well technically dhcpcd 3 uses /var/lib <AlexExtreme> but i patched it to use the old paths until i migrate the network utils to use the new paths (which i'm gonna do in a few mins :p) <Keybuk> the whole "complex event" thing is getting tricky to see through the fog #upstart 2007-05-16 <Keybuk> yup <Keybuk> definitely <Keybuk> after much consideration <Keybuk> we want to replace tty* with a single instance job :) <AlexExtreme> what were the reasons for deciding that? (just curious) <Keybuk> it's just neater and more upstartish <AlexExtreme> fair enough :p <Keybuk> solves the "but I don't have ttyN" Xen problem <Keybuk> start a tty when you get the event for it, combined with other events <AlexExtreme> ah yeah <AlexExtreme> so you won't get an event from udev for all the other ttys when using xe <AlexExtreme> *Xen <Keybuk> this is actually a really interesting case <Keybuk> we have a pair of events from udev, ADD /class/tty/* -> REMOVE /class/tty* <Keybuk> between these, we know that /dev/* exists for a tty-class device <Keybuk> so we can say that a tty exists, and which tty that is <Keybuk> and we want the getty job "bound" to that <Keybuk> ie. each instance refers to one of the underlying devices, and has the information about those available <Keybuk> but that also needs to be intersected with another sequence of events <Keybuk> "the period during which a user can login" <Keybuk> this is a complex calculation based on things like /etc/nologin existing, ldap being running (for local ldap auth), nscd, nfs (home dirs), dirs being mounted, etc. <Keybuk> and I think that Upstart should be able to calculate this event itself, rather than farming it off to some other process? <AlexExtreme> yes <Keybuk> perhaps I need to take lots of mind-altering drugs, and sit in a tent on the beach with a nice fire going, until my spirit guide comes to me and tells me how to do that :p <ion_> :-) <AlexExtreme> :D <Keybuk> scheme interpreter? :p <JohnFlux> Keybuk: just out of interest, will kdm etc be able to ask for the password etc before the user is able to login <JohnFlux> Keybuk: since it takes a long time for the user to enter a password <ion_> (job 'tty1 ((start-on "runlevel [2-5] ") (stop-on "runlevel {0,1,6}") (respawn) (exec "/sbin/getty 38400 tty1"))) <Keybuk> ion_: heh <Keybuk> ion_: I'd rather like the native jobs to not refer to the runlevels <ion_> Yeah, i just took a random file from my current /etc/event.d and converted it. :-) <Keybuk> JohnFlux: kdm can do whatever it likes ;) <Keybuk> ion_: the tricky thing is defining how events interact to form states <Keybuk> you'd probably want dynamic event interaction too <JohnFlux> btw I was looking at the upstart files <JohnFlux> it would be really nice to allow you to write "start after stopping apache" etc <Keybuk> ie. "depend on path-mounted ... path-unmounted /usr if getmntent -q -f -d /usr <JohnFlux> so using "after" and "before" instead of "on" <Keybuk> JohnFlux: the whole start on/stop on thing is likely to be changing for 0.5 <Keybuk> so the new language may be nicer <JohnFlux> "after stopping" and "before starting" is much more readable than "on starting" <JohnFlux> oh okay <Keybuk> "after" has semantic meaning though <Keybuk> do "after starting apache" things get run after those things with "on starting apache", etc. <Keybuk> (and we also have planned temporal events, e.g. start 10m after starting apache") <ion_> start 1m before startup <Keybuk> ion_: a proposed implementation on my desk by 9am, please <Keybuk> ;) <ion_> :-) <Keybuk> (actually, that would be easy to implement -- you'd delay startup by 1m) <ion_> Hehe, yeah <dg> what's the recommended way to run something as a different user from an upstart script? <mbiebl> dg: upstart doesn't implement that functionality yet. <mbiebl> So you have to use "su" <dg> ah #upstart 2007-05-17 <Keybuk> *yawn* * Keybuk had some interesting thoughts today <AlexExtreme> oh? <Keybuk> so the problem I've been having is trying to understand how to define when a job is running <Keybuk> and also define for instance jobs when instances are spawned and destroyed <Keybuk> which involves quite complex combinations of events <Keybuk> and I've been increasingly wondering whether events are the right things to track, and whether we should instead deal with states <Keybuk> e.g. rather than "initctl emit tty-added tty1", you'd "initctl set tty-exists tty1 true" or something <Keybuk> (since then jobs would become just lists of and/or around states) <Keybuk> but after some thought, I've decided against that <Keybuk> because we are really receiving events, and trying to fob off turning them into states to the emitter is a bit crap <AlexExtreme> right <Keybuk> so having decided that upstart should still receive events <Keybuk> that means upstart has to deal with turning events into states <Keybuk> and so far I've been trying to define these states through Job <Keybuk> this, I think, is wrong <Keybuk> instead I think we should make State a first class <Keybuk> and have a way to describe a State, with reference to one or more Events <Keybuk> which means Job would just make reference to a State in which it was running <Keybuk> then instance jobs could optionally just have two State *, one for when instances exist, and the other for when those instances are running <Keybuk> e.g. the getty job <Keybuk> instances exist for each state tty-added ... tty-removed for a unique $TTY <Keybuk> and those instances are *running* for the "user can login" state (defined elsewhere) <Keybuk> this makes Job rather simpler <AlexExtreme> sounds good <Keybuk> in fact, I'm considering splitting Job up a bit more, so that the dealing with instances and replacement jobs is at a higher level clas <Keybuk> at the very least, we'd have Job -> State -> Event <Keybuk> and we have a good grip above on how to define State <ion_> Sounds good indeed. <Keybuk> it's a combination of periods of events <Keybuk> each item has an Event to be matched, and a pointer to the the EventEmission that matched it <Keybuk> events on the right-side of the period should be able to reference the emission in the left-side <Keybuk> e.g. tty-added tty[1-6] -> tty-removed $TTY <Keybuk> this therefore implies that the state has a value at any given time <Keybuk> which is the environment of any left side not cancelled out by a right side <Keybuk> so we can pass that on to the job <Keybuk> once the rhs is filled, we can discard the emission on the left since that needs to happen again <Keybuk> so we actually just need three pointers, start_event, stop_event and emission <Keybuk> and not bother retaining the emission for the stop event, since that just cancels the start one <Keybuk> we then just need boolean things <Keybuk> AND, OR, NOT for those structures <Keybuk> and AND and OR for the start/stop event trees <ion_> Fever ftw. <Keybuk> the thing causing me difficulty is <Keybuk> - telling a job which events happened in the tree <Keybuk> - positional arguments <Keybuk> any thoughts? <AlexExtreme> nope, sorry. my brain isn't working too good today <AlexExtreme> i'll have a think about it though <Keybuk> the only thing I could come up with was <Keybuk> - walk the tree in-order <Keybuk> - for each open state, push the event name into the list, and its positional arguments <Keybuk> - then pop the first event name, place in UPSTART_EVENT <Keybuk> so UPSTART_EVENT is the first event at the top of the tree <Keybuk> $1..$n are the arguments to that event <Keybuk> followed by "--" followed by the name of the next event, and that ones positional arguments <Keybuk> quite programming intensive <Keybuk> but I suspect it won't be a problem, since the only things caring will probably be tasks or state-based instances <Keybuk> and those will have only one or two events in their list <Keybuk> so for most people, $UPSTART_EVENT and $1...$n will be sufficient <Keybuk> e.g. <Keybuk> block-device-added ... block-device-removed $1 or partition-added ... partition-removed $1 <Keybuk> sounds ok? <AlexExtreme> yes <Keybuk> we'd probably end up needing separate files to define states in <Keybuk> maybe just /etc/upstart.conf or something <Keybuk> and obviously name them <Keybuk> and since jobs are now tied to states, not events, we'll have to rename /etc/event.d :p <AlexExtreme> rename it? shit. :p oh well, i suppose i can rebuild my entire upstart repo... ;) <Keybuk> lol <Keybuk> it's always been a temporary name * Keybuk has never liked it <AlexExtreme> how about 'upstart.d' ? :) <AlexExtreme> jobs.d? <Keybuk> I'd been trying to avoid using "upstart"'s name in its config files <Keybuk> it may be inevitable though <Keybuk> I wanted /etc/init.d ... but someone already used that <AlexExtreme> i would say init.d <AlexExtreme> heh <AlexExtreme> but it's used already ;) <Keybuk> likewise /etc/rc.d <Keybuk> (but then rc.d is kinda old) <AlexExtreme> frugalware still uses rc.d for it's sysv stuff (but we were originally based on slackware, so... ;)) <AlexExtreme> hmm :) there's a response from Mike Saunders (an LXF writer) on that post you made @ your blog <Keybuk> yeah I saw <Keybuk> I disagree with him <Keybuk> I think that the point of printed magazines is to have a single line of opinion <Keybuk> an editorial direction <AlexExtreme> me too <Keybuk> otherwise what do they give us that the online press doesn't? <AlexExtreme> right <AlexExtreme> there's one thing that's been annoying me with LXF recently <Keybuk> what's that? <AlexExtreme> they've been reviewing beta releases as the final product, and only mentioning in small print that it's the beta <Keybuk> their time-to-print seems extraordinarily long <Keybuk> I've noticed that before with them <Keybuk> their NEWS is amazingly out of date <AlexExtreme> yeah <Keybuk> could have /etc/service.d /etc/task.d and /etc/state.d <Keybuk> bit overkill though <AlexExtreme> yeah <Keybuk> why is it always ".d" anyway? <AlexExtreme> i prefer a central location rather than files dotted in a few directories over the place <AlexExtreme> dunno, i've always wondered that <Keybuk> difficult to google for ;) <Keybuk> it seems to have stemmed from when a file was turned into a directory <Keybuk> /etc/rc -> /etc/rc.d <AlexExtreme> probably the .d stands for directory <Keybuk> and it vaguely implies that if you concatenated all the files together, it's equivalent to just having a single file <Keybuk> which means that the /etc/event.d use would be "invalid" <Keybuk> since the name matters <Keybuk> but then the same is true for /etc/pam.d <AlexExtreme> and dbus' system.d <Keybuk> we do need to separate out jobs and states though <Keybuk> maybe <AlexExtreme> btw, will the replacement-initscripts spec *definitely* get implemented for gutsy? <Keybuk> no <Keybuk> it's strongly possible though <Keybuk> the only thing standing in the way is this complex event config problem <AlexExtreme> well, if you need any help with that just ask, i'll try to help with decisions if i can <Keybuk> see above ;) <AlexExtreme> :) #upstart 2007-05-19 * Starting logfile irclogs/upstart.log <keir> how long until upstart makes a difference in boot time? #upstart 2007-05-20 <Keybuk> refactoring is such great fun <ion_> Heh <AlexExtreme> why's that? :) <Keybuk> cleaned up event.c a little bit <AlexExtreme> cool <Keybuk> got rid of the evily named EventEmission structure <Keybuk> (that's now just Event) <Keybuk> (and what was Event is now EventInfo) <Keybuk> also added some ref-counting stuff, so we can keep Event information around after it's been handled (since it populates environment, etc.) <Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070520120917-6yanaj1t0a1ej3zd?start_revid=scott%40netsplit.com-20070520121451-6273as3mqxmumuai#init/job.c <ion_> * should be releaed and the event should be freed. <ion_> test_event.c <Keybuk> :-) <Keybuk> next thing to figure out is what the difference between Jobs and States means <Keybuk> * should they be configured in different directories? <Keybuk> or should they be the same, just without processes specified <Keybuk> - if different, how do we avoid name clashes? <Keybuk> - if the same, how do we prevent "start STATE" from working? <Keybuk> and what happens if you turn a file from a job to a state or vice-versa? <AlexExtreme> if it's the same, can't you prevent start STATE from working by having init work out whether it is a state, and if it is chuck back an error and bail out? <AlexExtreme> or is it not possible to work out? <ion_> Perhaps the use cases should be considered to determine that. <ion_> That is, what Keybuk said. <Keybuk> what I want to avoid is having the entire Job structure around for a State <Keybuk> otherwise, what's the difference? <Keybuk> I can see two easy ways to do that <Keybuk> one is to have a states hash, as well as a jobs hash, and have something evil in cfgfile.c that returns State instead of Job if there's no processes configured, etc. <Keybuk> but you'd then have to look in both hashes all the time <Keybuk> the other way would be to get rid of the jobs hash <Keybuk> instead have a "registry" <Keybuk> that'd probably have several levels <Keybuk> 1) configuration directory (e.g. /etc/??, ~/.??, etc.) <Keybuk> 2) filename <Keybuk> 3) state or job found there <Keybuk> and hash at (3) <Keybuk> that way, a file that defines both a state and a job (ie. an ordinary job) would be able to used as either a state or a job <Keybuk> but a file that defined just a state could only be used as a state <Keybuk> also that makes -HUP easy ;P <Keybuk> and I could move all the "replacement" stuff into that <Keybuk> (though when do you replace a State file?) * Keybuk ponders <Keybuk> I guess the major question is: does it make sense to let sysadmins manually start/stop a "state" ? <Keybuk> e.g. if you've defined "user-can-login" as a state <Keybuk> (or writable-filesystem, filesystem-and-networking, etc.) <AlexExtreme> i don't think it makes sense, really. they aren't processes, so you should really be able to start/stop them. and if you have a case where a state hasn't really been reached, yet the sysadmin still starts it, it could cause some problems <AlexExtreme> so in the long run it'd be less problematic, IMO <ion_> I cant think of a state a sysadmin would need to start or stop manually. I cant think clearly with this flu in addition to my usual symptoms, though. :-) <Keybuk> hmm <Keybuk> so better question, should you be able to have a pre-start and/or post-stop script for a state? <AlexExtreme> hmm <AlexExtreme> i'm not sure... <AlexExtreme> i can't really think of a use case for that <ion_> How about having a process ping a remote host every once in a while and set a network-reachable state based on the pong? <AlexExtreme> at the moment we can create a job without a main process, just a pre-start and post-stop. are those states or are they still jobs? <Keybuk> exactly <Keybuk> use case: runlevel-2 state that sets utmp on the way in? <AlexExtreme> hmm <AlexExtreme> yes <Keybuk> user-can-login state that removes /etc/nologin on the way in, touches it on the way out? <AlexExtreme> yep <Keybuk> I can think of examples that are "nice" <Keybuk> and can't think of any counter-reasons why it should be forbidden <ion_> Yeah, definitely. <AlexExtreme> yep <Keybuk> which means that "State" would need the same internal state machine as "Job" <Keybuk> along with the ability to define processes, and their environment <Keybuk> so the difference between a state and a service is purely semantic <Keybuk> that makes things much easier, since it answers the questions like how to decide when to replace a state definition with one from an updated config file <ion_> Defining states just as jobs without a main process follows the KISS principle. <Keybuk> yeah <keir> i have a possibly rude question: how long until upstart begins shrinking boot time via parallel process start, etc? <AlexExtreme> it already can do <AlexExtreme> it'll *probably* be available in ubuntu 7.10 <keir> i don't mind long boots on my desktop, but they are killer on my laptop <keir> especially since suspend is broken <Keybuk> it's interesting how hating the first normally co-incides with being affected by the 2nd :p <keir> heh <keir> i dream of fresh-install XP SP2 boot times for ubuntu <keir> now that os boots fast! <Keybuk> only the first time ... <cortana> but if you add up all the times you _have_ to boot it, i wonder which one eats a larger chunk of one's life <keir> true! but i used to run it on my laptop for old games <keir> i only had FF and the games installed <keir> i always got very jealous when it would boot up in 15 seconds or so <cortana> it's a good thing that winodws boots in about 20-25 seconds <cortana> i have to reboot about 3-4 times ususally to get my keyboard to work <Keybuk> Upstart's primary goal isn't to make boot faster <keir> Keybuk, i know <Keybuk> it's too make it more reliable and robust <cortana> there is a totally random 75% chance that my keyboard will _not_ work on any given boot into xp :( <Keybuk> as well as provide more flexibility for what's actually running <keir> Keybuk, it'd be great if that was a side effect :) <Keybuk> we just happen to also think it will speed it up * Starting logfile irclogs/upstart.log <quitte> hi. has anyone tried compiling upstart using uclibc? I get this error:child.c: In function 'nih_child_poll': child.c:141: error: 'WEXITED' undeclared (first use in this function) WNOWAIT is also undeclared * Starting logfile irclogs/upstart.log <quitte> now I'm getting undefined reference to `inotify_add_watch. do you happen to know what is missing in uclibc for that,too? <Keybuk> sys/inotify.h <quitte> hmm. that should comefrom the kernel, not uclibc? <Keybuk> the libc still has to define the syscall <quitte> ah <quitte> it's already there. what is this nih thing? <Keybuk> it's the standard library that upstart uses <Keybuk> like glib, or something #upstart 2007-05-21 <quitte> #define HAVE_SYS_INOTIFY_H 1 is in config.h. I'm out of ideas. maybe you can see a problem in the patch here: http://bugs.uclibc.org/view.php?id=917 ? <Keybuk> you need the functions in your uclibc as well as the headers <quitte> the kernel headers are in place,too. <Keybuk> yeah, you still need the stub functions though <Keybuk> the header declares the existance of the function, but not the function <Keybuk> you can probably just copy the syscall stuff into a header and inline it <Keybuk> like the nih/inotify.h thing does <quitte> hmm. I hardly understood what you said. but I'll have a look at nih/inotify.h <quitte> ok looking at it didn't give me any clue. * Starting logfile irclogs/upstart.log <|Lupin|> Hello, everybody <|Lupin|> I am joinning the chan because it looks like upstart does not log the bot messages in /var/lob/boot, I am wondering why... <Keybuk> |Lupin|: we had some last-minute issues with logd <Keybuk> it turns out that when it isn't running, processes that try to output to stdout die <Keybuk> ie. the shell running the shutdown scripts <|Lupin|> so ? <|Lupin|> Actually there is a file called /etc/event.d/logd <|Lupin|> it contains a line saying <|Lupin|> console output <|Lupin|> Does one have to change this line to have hte output redirected to a file rather than to the console ? <|Lupin|> More in general, I can't find any documentation about the synta of the files under /etc/event.d <Keybuk> the console X line does indeed set where the input/output of a job goes; you set jobs to "console logged" to have them use logd, except this is disabled in the code <Keybuk> the lack of documentation is semi-deliberate, since the syntax isn't stable yet <|Lupin|> ok <|Lupin|> Keybuk: In fact what I would really like is to be able to have everything appearing on the screen at boot gathered in a file so that I can read it. Is this possible ? <|Lupin|> Or perhaps would it be more simple to switch back to sysvinit ? <Keybuk> there's various interesting ways to do that <Keybuk> the logd trick is to set the console to a set of sockets that are intercepted by a daemon <Keybuk> the disadvantage is obviously that without the daemon, the trick doesn't work <Keybuk> an alternate trick is to use TIOCCONS to capture "console output" <Keybuk> the disadvantage to that is that you don't know which service is doing the output <|Lupin|> Keybuk: oh indeed the daemon is not installed... <Keybuk> (the other disadvantage to the logd trick is that with ordinary sockets, you don't have a tty, which can adjust the behaviour) <|Lupin|> Keybuk: I think I don't mind loosing the name of the service, as a temporary solution. But how can this solution be implemented, concretely, please ? <Keybuk> there's not an easy answer available right now <|Lupin|> Hmm... <Keybuk> it turns out to be a more difficult problem <|Lupin|> If the system remains in text mode, will I be able to rean the console with shift-pagep / shift-page-down ? <Keybuk> yes <Keybuk> you're obviously relying on the kernel ring-buffer size there <|Lupin|> yes <|Lupin|> I am wondering how I can keep the system in text mode.. ? <|Lupin|> is it a matter of runlevel ? <|Lupin|> I believed so, but runlevels 2, 3, 4 and 5 seem to run gdm... <Keybuk> remove gdm symlinks from one of the runlevels <|Lupin|> is it all I have
{'channel': 'upstart', 'month': 5}