#upstart 2007-06-01 <ribo> how do I get a proper serial console with upstart? <asdaf> Hi all <Keybuk> hi <reppel> Hi, is it possible to define something i call "systemup" which should be emited when two jobs are finished? <reppel> for instance "networking and fs" <Keybuk> within upstart? not directly <Keybuk> you can obviously run "initctl emit systemup" <reppel> yes but how do i know when both net and fs jobs have finished? <Keybuk> that's being worked on at the moment <reppel> ah ok thank you <AlexExtreme> hmm that profile syntax looks better ;) <Keybuk> heh <Keybuk> the primary advantage would be you can parse it with one function call and a table :) <Keybuk> and then we could have /etc/init.conf <Keybuk> profile foo <Keybuk> enable * <Keybuk> disable bar <Keybuk> end profile <Keybuk> job bar <Keybuk> .. <Keybuk> end job <Keybuk> if we wanted <AlexExtreme> yeah <AlexExtreme> i knew nothing about nih/config ;) <Keybuk> AlexExtreme: it's the code upstart uses for its own config file <Keybuk> seemed sensible to libraryfy it <AlexExtreme> yeah <Keybuk> at that point, you just need two functions, cfg_stanza_enable and cfg_stanza_disable ;) <Keybuk> and look at cfg_stanza_description for the code you need inside <AlexExtreme> cool, thanks <Keybuk> (call nih_config_next_arg () to get the job name, then nih_config_skip_comment () to guarantee no more args and move to the next line) <AlexExtreme> i'll play with it tomorrow <Keybuk> did you think much about the default or multi-profile stuff? <AlexExtreme> not much, i've been quite busy this afternoon <AlexExtreme> had one of my machines drop dead, needed to fix it up <Keybuk> badness <AlexExtreme> brb, dinner #upstart 2007-06-02 <ion_> Why not make enable * implicit in the Profiles spec? <AlexExtreme> ion_, you mean, everything enabled by default? <ion_> Just as if theres enabled * at the beginning of each profile, just make it implied. To override it, add disabled * at the beginning. <AlexExtreme> yes, in the test parser I wrote, if no value for * was explicitly defined, it would imply "enable *" * AlexExtreme should write that on the spec <AlexExtreme> added <ion_> In this example every job file would be taken into account apart from apache. The enabled * line should be removed from that one, right? <ion_> Or add a comment that the line isnt really needed. <AlexExtreme> changed <ion_> Nice <Keybuk> hi-ho <wasabi> howdy long time no seen <Keybuk> howdy <Keybuk> stranger <Keybuk> ;) <wasabi> so how's upstart been going. ;) <Keybuk> still stuck on complex-event-config <Keybuk> lol <wasabi> heh <wasabi> I dunno, everytime I come to this I think maybe it is too complex. :) <Keybuk> loll <Keybuk> we think that it would be nice if you could have one single getty job <Keybuk> instance <Keybuk> respawn <Keybuk> while tty-added tty[1-6] until tty-removed $TTY <Keybuk> exec /sbin/getty 38400 $TTY <wasabi> Maybe a simple service dependency thing is the best.hmmm <wasabi> oops <Keybuk> ? :) <wasabi> didn't mean to send that line. it was sitting in my buffer <wasabi> I was going to delete it. ;) <Keybuk> lol <wasabi> Nothing to see here, move along <wasabi> I don't really see why having one job for that is any better than 6 <Keybuk> a) neatness <Keybuk> b) solves the Xen problem (tty2-6 don't ever exist!) * Keybuk resumes attacking config file reloadin <Keybuk> this is trickier than it seems <Keybuk> since you need a list of configuration directories, <Keybuk> and for each of those a list of configuration files, <Keybuk> and for each of those a list of jobs you found there. <AlexExtreme> hmm <AlexExtreme> my new profile parser using nih/config seems to work <AlexExtreme> http://frugalware.org/paste/1475 <Keybuk> shiny <ion_> (offtopic) I bought a camera today. http://heh.fi/tmp/kuplaraama <wasabi_> Keybuk: Did you ever really come to some sort of conclusion about how tracking levels (period between events) works when reloading Upstart, or installing new job files? #upstart 2007-06-03 * AlexExtreme wonders if NihHash would be a better storage type for the list of profile entries <rgl> hi <rgl> AlexExtreme, why is this """When a job is disabled by the current profile, it still responds to events, it'll just not actually start. If the system is currently in a state when it can be running, and the profile is changed to one which allows it to be run, it'll start.""" ? <rgl> why to refuse to start a job? <AlexExtreme> because that's what disabling a job is? <rgl> I mean, if the admin wants to start a job that is not in the current profile, why should he be refrained from starting it anyways? <rgl> for me "disabling" is "disabling the service from being automatically started" <AlexExtreme> rgl, it would only be disallowed from starting if the profile specifically states that that job is disabled, and even then it could still be started manually <rgl> yes, I understood that. what I don't understant is why :D <rgl> "why you want to do that" <AlexExtreme> <rgl> for me "disabling" is "disabling the service from being automatically started" <AlexExtreme> that's exactly what it does... <Keybuk> sounds like you're both arguing for the same thing :) <AlexExtreme> you can still start it manually <rgl> ah :-) <rgl> sorry for the confusion :D <Keybuk> that makes the most sense to me as well <Keybuk> "disabled" jobs don't react to events, but still show up in lists, and can still be manually started/stopped <AlexExtreme> yeah <AlexExtreme> hmm <AlexExtreme> in terms of profiles, i'll be doing lookups by name quite often, both when parsing a profile and starting a job. so a hash would be more efficient <AlexExtreme> and i hadn't thought of using wildcards for job name matching. hrm <rgl> ah, so my email has something useful? :-) <AlexExtreme> yep :p <Keybuk> the interesting thing about Profiles, compared to the original Flags idea, is that Profiles are defined separately to Jobs <Keybuk> for Flags, the idea was that a Job listed the states it was enabled/disabled in <Keybuk> the thing I like about Profiles is that it's up to the sysadmin how Jobs are grouped <AlexExtreme> yes <AlexExtreme> IMO it's much more flexible <Keybuk> so this has got me thinking a bit <Keybuk> Profiles are fundamentally groups of Jobs <Keybuk> "these are the jobs that do things with networking" <Keybuk> "these are the jobs that do multi-user things" <Keybuk> "these are the jobs when the machine is acting as a web-server" <Keybuk> (I often used runlevel 3 in sysvinit for the latter, so I could turn on/off apache/postgresql/etc. which were expensive to run) <Keybuk> does that sound kinda right? <AlexExtreme> yeah <Keybuk> an interesting side-effect of the "disable means no auto-start" functionality is that if you disabled udev, then you inherently disable all jobs that react to udev events <Keybuk> so that's quite nice <rgl> can we please have multiple profiles active? :D <rgl> though, that goes against the word "profile", so maybe we should have job groups *G* <rgl> ("job groups" the name) <AlexExtreme> side note: i noticed the kbdrequest event earlier - what exactly is it useful for? <Keybuk> AlexExtreme: I think it's supposed to be "spawn a new getty" *shrug* <Keybuk> rgl: yeah, that's what I've been thinking <Keybuk> since a Profile basically acts as a group of Jobs <Keybuk> maybe we don't need to specify enable/disable in a profile <Keybuk> instead it just needs to include jobs by name <Keybuk> and then you can enable/disable a profile <AlexExtreme> this profiles idea gets more complicated by the day *g* <rgl> and have a directory with all the jobs in the profile (instead of a file; like I've said some of this day hehe) *G* <AlexExtreme> no <AlexExtreme> i will never, ever have that. it'd be a complete mess. we might as well just go back to /etc/rc*.d... <Keybuk> rgl: why would a directory be good? then a job couldn't be in multiple profiles <AlexExtreme> that'd be possible, of course, with nice symlinks all over the place <Keybuk> AlexExtreme: well, if a profile is just a list of jobs, and enabled/disabled, you just need to check whether any of the profiles the job is listed in are disabled <Keybuk> eww, symlinsk <Keybuk> symlinks are evil as a configuration mechanism <rgl> you chould just touch the file. <rgl> (no symlink) <Keybuk> empty files? <Keybuk> that's just as bad <g> <AlexExtreme> there'd be still little files everywhere <Keybuk> very djb-ish <AlexExtreme> yeah <AlexExtreme> that's what i hated with djb/runit :P <rgl> djb-ish is good for ya! <rgl> I love it :D <AlexExtreme> service == directory and scripts/files inside <AlexExtreme> why not just one file? <Keybuk> my Profiles musing went a bit further ,.. <g> <Keybuk> if a profile is a list of jobs, and if a profile can be disabled or enabled <rgl> its easier to admin using regular CLI tool? touch/rm vs using a command to parse the file and do that. <Keybuk> then you could link profiles to a state <g> <AlexExtreme> rgl, how is it easier? it'd be a complete nightmare for the distro developers <rgl> AlexExtreme, nightmare? why? <Keybuk> touch vs vi is pretty even <Keybuk> the modify command approach is better, since it can guarantee integrity <Keybuk> (what is the behaviour if you touch the name of a job that doesn't exist?) <rgl> Keybuk, its the same has using vi and inserting it in the profile file ;) <Keybuk> rgl: exactly, there's no admin difference <rgl> Keybuk, there is. to enable a service you have to use upstart-profile-enable-service service vs touch something <Keybuk> ? <Keybuk> no, you can use vi <AlexExtreme> or easier: <AlexExtreme> echo "enable myjob" >> /etc/init/profiles.d/myprofile <rgl> Keybuk, why did debian decide to use enabled-sites/ directories instead of using "Include" in the file? <rgl> AlexExtreme, and to remove? :D <AlexExtreme> sed -i '/enable myjob/d' /etc/init/profiles.d/myprofile <rgl> AlexExtreme, my point is, you have to use a command for doing it. but its a mater of taste *shrug* <rgl> AlexExtreme, obsioly, thats not that simple. <AlexExtreme> you have to use a command if you've got directories too <rgl> AlexExtreme, you have to skip comments, etc. <rgl> lets not paint the bikeshed anymore ;-) <Keybuk> rgl: how do you comment out the disabling of a service with your method? <rgl> Keybuk, humm, I was not thinking of disabling jobs. this was a "enable only" thing. if you want to disable the job, just rm the job from the profile. <AlexExtreme> take this as an example: <AlexExtreme> if a distro developer provided a job with a package and wanted that job enabled in all profiles by default <AlexExtreme> they'd have to go through each profile and add it in <Keybuk> rgl: no, I just want to comment it out for a while <Keybuk> you can't do that with the file technique <Keybuk> and you can't document why it's removed <Keybuk> # keybuk - think this is breaking networking - 02jun07 <AlexExtreme> surely it would be easier to just put it in /etc/event.d or whatever and have the profile "enable/disable *" lines handle it <Keybuk> # ntpdate <rgl> AlexExtreme, document? use a automated thing to administer your box? :D <rgl> err <rgl> that was for Keybuk :D <AlexExtreme> huh? <AlexExtreme> what has an "automated thing" got to do with anything? <rgl> AlexExtreme, with the "document" part that Keybuk said. <AlexExtreme> i still don't get what it's got to do with that <AlexExtreme> brb, lunch <Keybuk> anyway, it's my bikeshed, and we're using configuration files; not directories-o-symlinks or djb madness <g> <rgl> I was just saying that the "document" part could be addressed by your automated tool. (if you don't use one, yeah, it sux, and you can't document) <Keybuk> you can't document in the model you suggest though <rgl> Keybuk, fair enough :-) <Keybuk> you'd need another directory of documents about why things aren't in another one <AlexExtreme> btw Keybuk, it'd make sense to put all the profile stuff into a seperate source file (like profile.{c,h}) rather than sticking it onto the parsing stuff in cfgfile.c, right? if i were to put it in cfgfile.c it'd allow you to put job stanzas in profiles and vice-versa, which isn't what i want, really ;) <Keybuk> it should have a separate stanzas list, yes <AlexExtreme> k <Keybuk> that file is a little mixed up <Keybuk> since it has the parsing and watching code too <Keybuk> (which should be shared) <AlexExtreme> hmm, profile.c written. now to plug it in to the rest of upstart ;) * Keybuk keeps hitting namespace problems <AlexExtreme> with what? <Keybuk> right now we're relying on the filesystem to provide the namespace <Keybuk> if we allow people to define multiple jobs in one file, how do we enforce that? <Keybuk> (likewise for profiles) <AlexExtreme> hmm <Keybuk> obviously we have to solve this if we want people to be able to register jobs over the initctl socket <AlexExtreme> i'm not quite sure i understand <Keybuk> well <Keybuk> let's say I make /etc/init/jobs.d/foo <Keybuk> and I also make /etc/init/upstart.conf and put <Keybuk> job foo <Keybuk> ... <Keybuk> end foo <Keybuk> in it <Keybuk> which gets priority? <Keybuk> (and how do we stop them both fighting) <AlexExtreme> hrm <AlexExtreme> i would say the one in upstart.conf gets priority <AlexExtreme> take this as an example: <Keybuk> so the first one parsed? <AlexExtreme> a distribution provides a job called foo, and the user wants to override that job with their own version without editing the one provided by their distro <Keybuk> (assuming upstart.conf is registered first) <AlexExtreme> they could put their version in upstart.conf <AlexExtreme> and it would get priority <Keybuk> ok, and self-registered would take priority over that? <AlexExtreme> they could easily revert to the distros version by simply commenting out their version <AlexExtreme> yes <Keybuk> that makes it easy then <Keybuk> a Job just needs to know which CfgSource it was registered with <Keybuk> and when loading a job from a source, check the source is the same <Keybuk> though this means you can't move a job from one source to another <Keybuk> if you delete /etc/init.d/upstart.conf, the jobs.d/foo one wouldn't show up unless touched <AlexExtreme> it's not that big a problem, and if it could be solved by touching the other one, then it's a minor problem <Keybuk> I'd prefer it to be solved internally <Keybuk> we'd need a JobName structure that tracked, for a given name, what was available from each source, and whether each of those things had replacements <Keybuk> that's a bit sucky, since we'd need the same for Profile and State <AlexExtreme> hmm <AlexExtreme> say a job has been disabled in a profile, yet the sysadmin has started it manually. should the job respond to stop events? <rgl_> I think it should. <AlexExtreme> me too <Keybuk> yes <Keybuk> profiles should just affect start events <Keybuk> cf. job is running, and sysadmin disables the profile, it should still stop later <Keybuk> maybe it should stop immediately too * Keybuk tries to come up with a sensible filename for "job definition parsing" <Keybuk> in theory, we should be able to use the same pattern for "state definition" and "profile definition" <AlexExtreme> you mean source file name? <Keybuk> yeah <AlexExtreme> parser.c ? :P <Keybuk> doesn't say "job" though <Keybuk> so we'd have to put state and profile parsing in the same file <AlexExtreme> jobparse.c <Keybuk> and stateparse.c and profileparse.c ? <AlexExtreme> hmm. <AlexExtreme> a bit long :p <Keybuk> heh <Keybuk> I didn't realise there was a length limit <g> <AlexExtreme> meh ;) * AlexExtreme usually tries to keep it short and sweet <AlexExtreme> well, that's a start <AlexExtreme> the profile code compiled ;) <AlexExtreme> i'll test it in a minute :P <Keybuk> <g> <Keybuk> you're supposed to write the tests *first* :p <Keybuk> (not that I ever do) <AlexExtreme> :P <wasabi> Heh. I've never found TDD works on a budget. <Keybuk> I find that about 75% of my coding time is spent refactoring test cases <Keybuk> which is about the same amount of time I spent figuring out how I broke things <AlexExtreme> heh <AlexExtreme> ok, brb. if i don't come back, you'll know it hasn't worked :p <Keybuk> the net gain of course, is that the 75% now happens *before* I ship the tarball <Keybuk> AlexExtreme: just comment out the bits of main.c that assume pid()==1 :p <AlexExtreme> yeeep, i broke it :P <Keybuk> lol <AlexExtreme> somehow i'm getting an assertion failure on line 521 in string.c <AlexExtreme> how, i don't know, because i'm never calling the function that's it <AlexExtreme> *in <Keybuk> lol <Keybuk> what's the backtrace? <AlexExtreme> where does that come from? :p <AlexExtreme> core dump? <Keybuk> yeah <AlexExtreme> hmm <AlexExtreme> it would help if the FS was read write <AlexExtreme> hang on :p <Keybuk> test_cfgfile.c is annoying long <AlexExtreme> hmm <AlexExtreme> well the core dump was officially useless <AlexExtreme> init was compiled without debug symbols :P <AlexExtreme> ahhhh <AlexExtreme> i see what i did wrong :p <Keybuk> --disable-compiler-optimisations --disable-linker-optimisations --enable-warnings <Keybuk> :P <AlexExtreme> profile_get_job_status (job) << usually it helps to pass job->name to that function <AlexExtreme> let's try again ;) <wasabi> Keybuk: Yeah, which is great, when you're not on a budget. ;) <wasabi> Otherwise shipping the 75% is acceptable. Heh. <AlexExtreme> so it appears i'm managing to do something weird to job->cause <AlexExtreme> brb, dinner <Keybuk> woo, test passes <Keybuk> now to fix valgrind <Keybuk> easy; just a couple of "returning without freeing if -ENOMEM" bugs <AlexExtreme> it's interesting to note that i still get this assert failed if i revert all my changes <rgl_> how you guys test upstart? using UML? <Keybuk> odd <Keybuk> rgl_: "make check" <rgl_> how do I run upstart without being proc #1? <AlexExtreme> let's try the completely vanilla tree <Keybuk> rgl_: you can't at the moment, without patching the code <rgl_> Keybuk, so make check tests a running upstart? <AlexExtreme> no, it tests the code <Keybuk> rgl_: no, it's a suite of stuff that tests the code <Keybuk> unit tests, basically <rgl_> ah, no integration tests yet. ok. <AlexExtreme> ok, i'm getting this bug with a vanilla tree <AlexExtreme> Keybuk, want a backtrace? <Keybuk> sure <Keybuk> rgl_: define integration tests, in this case <AlexExtreme> Keybuk, http://frugalware.org/paste/1480 <Keybuk> I've never been clear exactly where unit and integration testing are supposed to be different <Keybuk> since pure unit testing supposes you can test just one function <Keybuk> (which you never can) <Keybuk> AlexExtreme: which upstart version? <AlexExtreme> it's latest bzr <AlexExtreme> 0.3.8 works fine <Keybuk> ah, interesting <Keybuk> * init/event.c (event_new): Start off with NULL args and env, to <Keybuk> match job (saves a few bytes). <Keybuk> (event_match): Watch for NULL arguments! <Keybuk> * init/tests/test_event.c (test_new): Check for NULL not alloc'd <Keybuk> heh <rgl_> Keybuk, test the whole shebang as a blackbox. like, have some jobs, kill a job, see if its restarted, and stff like that. also, test the "problem" I've mention a days before: edit job, start a service that is a symlink, and see it does not work. <Keybuk> AlexExtreme: if statement on job.c 1372 needs "&& job->cause->info.args" added <Keybuk> rgl_: that's System Testing <rgl_> Keybuk, isn't that the same as integration tests? <rgl_> (though, its the first time I've heard of system testing hehe) <Keybuk> well <Keybuk> usually you're supposed to have <Keybuk> Unit Testing -> Integration Testing -> System Testing <Keybuk> unit supposes you can test each individual function <Keybuk> integration is where you join functions together, and run scenarios through it <AlexExtreme> ok, let's test that <AlexExtreme> brb <Keybuk> system is when you have the finished system, and apply checks to make sure it works <Keybuk> the Upstart test suite is something of a combination of Unit (where possible) and Integration <Keybuk> frequently tests are running much of the Upstart code <Keybuk> e.g. we have tests to set up a socket, and all of the code to listen to it, then we poke commands into it and see how the states of jobs change, and what events are emitted, etc. <rgl_> ah alright :D <Keybuk> System Testing is when I install and reboot <Keybuk> and if it fails, then I don't get to my desktop, so I can't upload the tarball <g> <rgl_> hehe <rgl_> though, using UML could facilitate that (but for sure you known it hehe) <Keybuk> I don't know UML <Keybuk> or do you mean User-Mode-Linux? <AlexExtreme> I use VMware for that kinda thing :p <rgl_> oh yes, sorry. yes. user-mode-linux <AlexExtreme> mental note: it helps to apply the fix before testing it <Keybuk> yeah, I use vmware for some stuff <Keybuk> though mostly I just install it and see what happens <AlexExtreme> Keybuk, what line was it on (the if block to change)? <Keybuk> 1372 <Keybuk> is it bad to push incomplete code to main? :p <AlexExtreme> as long as i don't bzr pull :p <Keybuk> lol <Keybuk> you wouldn't be able to, you're diverged now, no? <AlexExtreme> true <AlexExtreme> if it works this time i'll commit it to a new branch <AlexExtreme> brb <AlexExtreme> OMG <AlexExtreme> It worked :P <AlexExtreme> bbl <AlexExtreme> https://code.launchpad.net/~alex-extreme2/upstart/profiles <AlexExtreme> night #upstart 2007-06-04 <HTSJacket> I'm having trouble understanding this sentence in the getting started page: This should be one of output (input and output from /dev/console), owner (as output and Control-C also sent the process) or none (the default; input and output to /dev/null). Can anyone explain what "as output and Control-C also sent the process" means here? <Keybuk> morning all <reppel> why upstart does not pass kernel cmdline argumments as env variables to jobs? <reppel> hi Keybuk <Keybuk> reppel: because it doesn't yet (missing feature) <reppel> Keybuk: ah ok <Keybuk> jobs should be able to select which variables they want to receive with "env VAR" in their definition <reppel> Keybuk: nice * Starting logfile irclogs/upstart.log <Keybuk> hmm <Keybuk> who needs config file code anyway? <shawarma> Does upstart have some sort of in-memory idea about which jobs exist? If so, how do I make it rethink that list? <Keybuk> yes <Keybuk> there's no way (yet) to make it reload that list <shawarma> I see. Hm. <shawarma> That kind of sucks. :) <Keybuk> why? <Keybuk> (do you need to make it reload) <shawarma> I want to have upstart manage a newly added daemon. <shawarma> So yes, I need to make it reload. <shawarma> Unless I'm missing something obvious? <shawarma> It's been known to happen.. :( <Keybuk> why not just write the file? :) <Keybuk> bet you if you do "initctl list", the new daemon's there <Keybuk> inotify is a wonderful thing <Keybuk> <g> <shawarma> Keybuk: It seems not? <Keybuk> which version of upstart/ <shawarma> oh.. <shawarma> Not making syntax errors in the job file helps a lot. <shawarma> :) <cort> how does it ensure that it only reads the file once it's been written? <cort> or can inotify tell you that the newly-created file has been closed <Keybuk> cort: IN_CLOSE_WRITE <cort> cool <Keybuk> (closed and written to) <shawarma> When does upstart consider a job to be started? <shawarma> I.e. without --no-wait, when will "start jobname" terminate? <Keybuk> depends whether it's a task or a service <shawarma> Since it's a deamon I want supervised, I expect I should pass it arguments to run in the foreground? <Keybuk> if it's a task, start will not terminate until the job terminates <Keybuk> if it's a service, start will terminate once the job is running <Keybuk> right <Keybuk> you should make sure it runs in the foreground <Keybuk> and make sure "respawn" is in the job definition <AlexExtreme> it helps not to leave duplicate values around in the profile from testing <g> <Keybuk> heh <Keybuk> I changed the job code today to not bitch about duplicate stanzas <AlexExtreme> heh <shawarma> Keybuk: Oh, so "respawn" tells it that it's a service? Got it. <Keybuk> shawarma: respawn tells it that it's a service that should be respawned <Keybuk> shawarma: "service" tells it that it's a service that should not be * AlexExtreme will have fun merging the changes in main to the profiles branch <shawarma> Keybuk: Oh, ok. <Keybuk> AlexExtreme: <g> did you look at them yet? <AlexExtreme> not in detail yet <Keybuk> it should make things a lot easier for you <Keybuk> you just need a parse_profile.c with a parse_profile() function <AlexExtreme> sweet <Keybuk> takes the usual file, len, pos, lineno parameters, and probably has stanza_*() functions and a table to parse that block of text <Keybuk> pretty much everything else will be handled for you <Keybuk> (watching the directory, tracking reloads & deletes, etc.) <AlexExtreme> nice * AlexExtreme reads through his commit mails <Keybuk> you get commit mails? <AlexExtreme> yeah <AlexExtreme> if you subscribe to a branch you can configure it to send you mails on new commits ;) <Keybuk> neat <Keybuk> does it attach diffs? <AlexExtreme> yep, as long as the diff is under a certain size <Keybuk> shiny <Keybuk> I never knew about that <AlexExtreme> The size of the diff (10342 lines) is larger than your specified limit of 1000 lines <AlexExtreme> yeah, i only found that feature the other day ;) * AlexExtreme likes launchpad <Keybuk> what diff was that?! <AlexExtreme> rev 693 <Keybuk> wow <Keybuk> no wonder my fingers hurt yesterday <AlexExtreme> :P <AlexExtreme> oh, 696 is bigger ;) <AlexExtreme> 2968 lines <Keybuk> 2968 < 10342 ? <AlexExtreme> whoops <AlexExtreme> misread it with an 0 on the end for some reason :p <AlexExtreme> s/an/a/ <AlexExtreme> so, with the new code, i would ignore duplicate values and overwrite the old value with the new one instead? <Keybuk> right <AlexExtreme> k <mbiebl> Keybuk: I spotted a small glitch. Patch is here: http://pastebin.ca/536963 <Keybuk> mbiebl: yeah, that'll be needed, thx <Keybuk> committed <AlexExtreme> brb, testing the NihHash-ified profile code <mbiebl> Keybuk: thx <AlexExtreme> /* FIXME: Read configuration */ << if we don't read the configuration, does this mean the current bzr doesn't work? :) <Keybuk> right * AlexExtreme will hold back on updating the profiles branch to the latest main then :p <Keybuk> 08:23 <Keybuk> is it bad to push incomplete code to main? :p <AlexExtreme> just checking in case you've made it working today <Keybuk> no, not yet <Keybuk> it's a complex problem that I want to solve <Keybuk> and I find it difficult to work in the afternoon, for some reason <AlexExtreme> heh <AlexExtreme> np <AlexExtreme> btw, i'm assuming we shouldn't disable jobs from automatically starting on the stalled event? <Keybuk> AlexExtreme: why not? <AlexExtreme> because say a user does "disable *" and doesn't enable any jobs specifically, the system will just hang at boot with no useful message. surely it should give them an opportunity to login and fix their blunder? <Keybuk> quest upstart% bzr diff -rtag:0.3.8.. | diffstat | tail -1 <Keybuk> 34 files changed, 7423 insertions(+), 6014 deletions(-) <Keybuk> whee <AlexExtreme> http://codebrowse.launchpad.net/~keybuk/upstart/main/changes << umm :P <AlexExtreme> 500 Internal error <AlexExtreme> The server encountered an unexpected condition which prevented it from fulfilling the request. <Keybuk> poked lp <AlexExtreme> k <Keybuk> AlexExtreme: heh, broken by having tags, apparently <AlexExtreme> lol * Keybuk is still trying to figure out the registry stuff <Keybuk> it's a little complex right now <Keybuk> the theory is: <Keybuk> - a hash table for each type (Job, State, Profile, etc.) <Keybuk> - each entry is a Name structure that has the name, a pointer to the current holder of that name, and a list of available entries with that name <Keybuk> when we parse a config file, we add all entries to the available list in their relevant namespace <Keybuk> then if the current holder of the name is replaceable immediately, we pick the new best current name #upstart 2007-06-06 <Keybuk> this whole configuration/namespace issue is hard :-/ <Keybuk> in fact <Keybuk> this is, if anything, more boring and tedious than the IPC code * rgl has no clue what the issue is <Keybuk> rgl: making it so upstart supports reloading its configuration <rgl> Keybuk, oh I imagine :/ <Keybuk> https://launchpad.net/upstart/+download <Keybuk> neat <Keybuk> codebrowse seems to work again, too <AlexExtreme> my connection would die just as i try to open that link, wouldn't it. <AlexExtreme> there we go <AlexExtreme> neat :) #upstart 2007-06-08 <Keybuk> meh, don't really have anything new to talk about for LCA 2008 :-/ <kylem> Keybuk, er, are you new at this? <kylem> you put in the abstract, *then* write the new code. <kylem> 8) <Keybuk> kylem: I'm still writing the code from last time <g> <kylem> lol. <AlexExtreme> Keybuk, talking of LCA, do you have a copy of your presentation from LCA2007? It's quite hard to read the text on the video <Keybuk> it should be linked on the lca website no? <AlexExtreme> no, the actual slideshow <AlexExtreme> i have the video here <AlexExtreme> just the text on the slideshow is all fuzzy :p <Keybuk> that's what i mean <Keybuk> oh, I see, the slides are a 404 * AlexExtreme didn't even notice there was a link to them :p <Keybuk> usual post-conference "not bothering to finish the website" syndrome there I think <AlexExtreme> yeah <Keybuk> unfortunately I can't seem to find a copy of the presentation! <AlexExtreme> darn <Keybuk> which is actually quite irritating <ion_> I dont think i downloaded it either. :-\ Perhaps someone reading the mailing list has a copy. <ion_> I did watch the presentation. <Keybuk> I have an old draft of it, not the actual presentation <Keybuk> hmm <mbiebl> AlexExtreme: Maybe google cache has it... <AlexExtreme> looks like they never had a copy of it on the site :/ <mbiebl> oh <AlexExtreme> google cache doesn't have it #upstart 2007-06-09 <mbiebl> This proposal looks awful: http://fedoraproject.org/wiki/FCNewInit/RC <ion_> Eww <cortana> egads <AlexExtreme> ewww @ the Fedora new RC thing <AlexExtreme> I saw the discussion on their mailing list about switching to an alternate init system, would you beleive that they were discussing shipping every init system by *default* and have scripts for each one in every package that needs one <ion_> http://heh.fi/tmp/saukonpuisto-panorama #upstart 2007-06-10 <Keybuk> #6 0x0804b322 in test_source_reload () at tests/test_conf.c:288 <Keybuk> 288 TEST_EQ_P (item->job, job); <Keybuk> (gdb) p job <Keybuk> $1 = (Job *) 0x0 <Keybuk> (gdb) p item->job <Keybuk> $2 = (Job *) 0x806c8b0 <Keybuk> (gdb) p item->job->name <Keybuk> $3 = 0x806c9c8 "tmp/test_conf.c-test_source_reload-213-12871/foo" <Keybuk> heh <Keybuk> oops <AlexExtreme> heh :p <Keybuk> hey Michael <mbiebl> Keybuk: hi <Keybuk> how goes it? <mbiebl> Fine, thanks. <mbiebl> How about you? <Keybuk> not so bad <Keybuk> making an attack on the new conf code today <mbiebl> Made a pull today and noticed that you were quite active the last couple of days ;-) <Keybuk> yeah, beware that the current code isn't actually working <Keybuk> ie. not finished <mbiebl> What's your aimed release date for 0.3.9? <Keybuk> no idea <Keybuk> soon <Keybuk> once the new conf code is working <mbiebl> Does that also involve a change in the directory layout? <Keybuk> maybe <Keybuk> if I carry that, I'll renumber it to 0.4 <Keybuk> /etc/event.d will become /etc/init/jobs.d at some point <Keybuk> but I may hold off and just use the new code to do /etc/event.d for now <Keybuk> (or even sneakily support both) <mbiebl> I'm currently preparing for Debconf (will be flying there on saturday) <Keybuk> cool <Keybuk> Edinburgh is a very pretty city <mbiebl> Hopefully I'll be able to convice the fellow DDs, which are so keen on the meta-init-script format, that it's imho not such a great idea. <Keybuk> meta-init-script? <mbiebl> There was some blogging and discussion a month ago about a meta-init-script format. <mbiebl> From which initscript for the existing init systems should be generated. <mbiebl> http://blog.incase.de/index.php/2007/04/17/init-script-generators/ <mbiebl> I'm pretty sure, such a system will not work. <mbiebl> We would end up with something that would be even worse than we have today with sysvinit. <ion_> *shiver* <mbiebl> imo a initsystem is something important like the package format of a distro. <AlexExtreme> fedora came up with a similar idea on their mailing list, i don't know what happened to it though, but instead of having a script generator they would simply provide a script in packages for most init systems. ugh <mbiebl> That's a maintenance night mare. <AlexExtreme> yep <mbiebl> Even the metascript idea is not much better there, because the testing will be a nightmare. <AlexExtreme> that's exactly what i was thinking as i read the thread <Keybuk> Fedora are being odd <Keybuk> cblizzard's post seems to think that starting things when you need them is a revelation * Keybuk knows for a fact that he was sitting in my LCA Upstart talk <mbiebl> And D-Bus all the way ;-) <Keybuk> dbus people still seem to think that system services are the way forward <Keybuk> "We have this great hammer ... I know this looks like a job for a screwdriver, but it works if we hit it hard enough with the hammer too!" <AlexExtreme> heh :) <ion_> Lets replace IRC with D-Bus. <mbiebl> I also think that this whole D-Bus system service activation is crazy. <mbiebl> Unfortunately the HAL guys are not much better in that respect. <mbiebl> As much as I value what HAL brought for the Linux desktop, <mbiebl> cramming everything into HAL, power management, disk formattting (shrug) etc, seems insane. <mbiebl> (at least to me) <Keybuk> they're not quite into HAL <Keybuk> they sit alongside it, exposing themselves as HAL methods <Keybuk> that makes some amount of sense <Keybuk> the alternative is something like network-manager, which is its own daemon, with own communication properties, etc. <Keybuk> using HAL for the communication actually makes it easier <Keybuk> network-manager could be a hal add-on that implements "change essid" type properties on network interfaces <Keybuk> which would make programming easier <Keybuk> the separation is about the same, since the communication is still dbus, and the daemon is still separate <Keybuk> you're just using a particular kind of dbus call (HAL methods) <mbiebl> Well, if you make NM a HAL addon, you also lose some good features: <mbiebl> The ability to start/stop it on its own. <mbiebl> separate logging <mbiebl> clear separation, so systems which don't use it, don't have to install it. <Keybuk> hal addons are seperate daemons, so they can be start/stop'd on their own, etc. <mbiebl> Really? Don't they have to be spawned from the hald process? <mbiebl> And the standard service management tools will not work with hal addons. <Keybuk> not sure whether they have to be or not <Keybuk> I think the communication is just dbus, so they don't need to be <Keybuk> ICBW <mbiebl> Doesn't matter. It's just me, rambling a bit ;-) <mbiebl> OT: Did you read this story: http://www.msnbc.msn.com/id/19088976?GT1=10056 <mbiebl> I really had to smile <ion_> Hehe <AlexExtreme> heh <ion_> In case someone didnt notice this one, ill rudely spam it again. http://heh.fi/tmp/saukonpuisto-panorama <mbiebl> cool. would make a perfect wallpaper for a 4-monitor xinerama setup ;-) <mbiebl> bbl <AlexExtreme> nice * Keybuk has patches to nautilus/compiz to make paranoma wallpapers work across multiple viewports <ion_> Do you make nautilus create a transparent background and compiz render the background? <Keybuk> yup <ion_> Thats great. <Keybuk> http://people.freedesktop.org/~racarr/nautilus.debdiff <Keybuk> you also need http://people.freedesktop.org/~racarr/libeel.debdiff <Keybuk> and the compcomm wallpaper plugin * AlexExtreme wonders when there will be a compcomm release <ion_> Ive thought thats the way to go forever. A wallpaper image could be replaced with a nice non-distracting animation, on which the desktop stuff would be composited. <wasabi> hah cool racaar did it <Keybuk> yeah he did <Keybuk> urgh <Keybuk> messyness has ensued in the "job replacement" code :-/ <theCore> is the cron-like functionality in Upstart got implemented yet? <theCore> nevermind <Keybuk> not yet <theCore> Keybuk: yeah, I understood that, when I saw "Events generated at timed intervals or scheduled times" under planned features <theCore> on the front page of upstart website <Keybuk> *nods* <Keybuk> File 'conf.c' <Keybuk> Lines executed:71.04% of 221 <Keybuk> conf.c:creating 'conf.c.gcov' <Keybuk> *sigh* <Keybuk> 29% to go * AlexExtreme really hates bugs <ion_> Heh * Keybuk really hates testing <theCore> Keybuk: you're not the only one <theCore> at least, testing pays off on the long run <Keybuk> truwe <Keybuk> ok, whew <Keybuk> the config code should now be roughly compatible with the old code again <Keybuk> (except that this new code is ready to support -HUP/initctl reload; and also has the necessary smarts to be modified to support job definitions in larger files and multiple overlapping sources of jobs) #upstart 2007-06-11 <asmlinkage> do the "start on" and "stop on" commands work in upstart 0.2.7-7 (Edgy's default version) <asmlinkage> I've written one main script that works fine, but a second script that uses start on and stop on to be started and stopped after the main script but upstart never starts or stops it when I start/stop the main daemon <AlexExtreme> hmm, I saw some commits that looked like the new config code should work now. am I right? <Keybuk> yup <Keybuk> you should be able to write a parse_profile.c in the manner of parse_job.c <Keybuk> and add bits to the enums/switches in conf.h/conf.c <AlexExtreme> hmm <AlexExtreme> i tested it when I saw those commits this morning and it didn't work, some assert failed messages that were going past so fast that I couldn't read them <AlexExtreme> a clean checkout from main, that is <Keybuk> which revno? <AlexExtreme> 720 <Keybuk> hmm <Keybuk> "make check" failed? * AlexExtreme runs it <AlexExtreme> hmm <AlexExtreme> works fine <AlexExtreme> let me try again <Keybuk> could be insufficient testing ;) <AlexExtreme> yikes, i cd'd up one dir too far before doing rm -rf upstart >< <AlexExtreme> oh well <Keybuk> oh yeah <Keybuk> it does kinda break, doesn't it <AlexExtreme> yep ;) <JK455> hi <JK455> i have a dumb newbie question about upstart <Keybuk> hi <Keybuk> sure <JK455> thx <JK455> how do i use it for an ordered shutdown <Keybuk> so an ordered shutdown is an interesting thing <Keybuk> in fact, shutdown in general is interesting <Keybuk> at the minimum, you're going to have an emitted event that indicates you want to shutdown <Keybuk> the compat/sysv uses "runlevel 0" and "runlevel 6" for this <Keybuk> you might use those, or call it "shutdown" <JK455> ok, <Keybuk> you'd then have some jobs that have "start on shutdown" <JK455> can it be dbus event ? <Keybuk> dbus => not right now, a dbus proxy is planned <Keybuk> (but not yet implemented) <Keybuk> one of the shutdown jobs can order a sequence of other jobs <Keybuk> e.g. you might just have a shutdown job that does the sequence <JK455> am not sure to understand : <JK455> you mean, having an event on all setted process for shutdown <Keybuk> no, just an emitted event <Keybuk> I'm not sure what you mean by setted process ? <JK455> for exemple, in my script i put that it have to stop on that event <Keybuk> right <JK455> like : stop on "shutd_event" <JK455> ok <Keybuk> yeah, that can stop running services * AlexExtreme has a "shutdown" job that starts on the runlevel 0 or runlevel 6 event, and then all the other jobs that i want to stop on shutdown have "stop on starting shutdown" <JK455> and i will respect all previously marked dependencies ? <Keybuk> AlexExtreme: that's actually an extremely good way to do it <Keybuk> since the shutdown script won't actually run until the jobs have stopped <JK455> i think not, right ? <Keybuk> JK455: upstart has no concept of dependencies <AlexExtreme> yeah, since the actual shutdown job's script will block until the jobs are stopped <Keybuk> AlexExtreme: *ahem* http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh?start_revid=scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh <AlexExtreme> hmm, is there an echo here? :p <JK455> ok, i have to wrote all events for repect of my own dependencies <AlexExtreme> ah, cool. that fixes it? <Keybuk> AlexExtreme: yeah, stupid mistake <AlexExtreme> k, i'll try it <JK455> and i were to wrote the piece of code that receives dbus message and use them as event, were would i had to start ? <JK455> "if i were" <Keybuk> JK455: how do you mean? <JK455> i would like to receive events by sending dbus messages to upstart <JK455> if i want to do that, do you have any tips for me ? <JK455> well, in fact, maybe i dont need that <AlexExtreme> brb, testing that fix <Keybuk> JK455: you'd need something linked with libdbus to receive the messages/events <Keybuk> and linked to libupstart to pass them on to upstart <Keybuk> (you can do the reverse too, the same way) <Keybuk> libupstart is in the upstart source code in the upstart directory <JK455> ok <Keybuk> util/initctl,c links to it to do everything <Keybuk> fundamentally, you'd match certain dbus messages and use UPSTART_EVENT_EMIT to send them on to upstart <Keybuk> and listen for UPSTART_EVENT messages from upstart, and send them across dbus <JK455> ok, great <JK455> maybe i will wrote it i we decide using it <JK455> thanks a lot for this informations <AlexExtreme> Keybuk: works fine now <AlexExtreme> (mental note: it helps to bzr pull *before* trying) <Keybuk> heh <Keybuk> woo <Keybuk> Keybuk 1 - Config code 0 <ion_> \/ <Keybuk> I now just have to write the tests for init.conf <AlexExtreme> so init.conf is now possible to implement? <AlexExtreme> uhh <AlexExtreme> so it's now possible to have an init.conf, is what i meant <Keybuk> AlexExtreme: in theory, yup <AlexExtreme> nice <AlexExtreme> hmm <AlexExtreme> some debian guy has sent something to upstart-devel about this meta initscript stuff <Keybuk> AlexExtreme: yeah was just talking to him on #debian-devel <Keybuk> well <Keybuk> ubuntu-devel <Keybuk> and not just <Keybuk> before doctor who, the f word, etc. <Keybuk> AlexExtreme: so the plan there is to have <Keybuk> /etc/init/init.conf (optional configuration file, overrides: <Keybuk> /etc/init/conf.d (directory of configuration files, overrides: <Keybuk> /etc/init/jobs.d (directory of job definitions) <Keybuk> config files can define jobs <Keybuk> e.g. <Keybuk> /etc/init/conf.d/some-random-conf could contain <Keybuk> job foo <Keybuk> exec /sbin/daemon -d <Keybuk> respawn <Keybuk> end job <Keybuk> which is equivalent (but higher priority than) the same text in /etc/init/jobs.d/foo <Keybuk> conf.d becomes useful when we can define profiles, states, etc. <Keybuk> in general, I expect distros to not use init.conf at all (useful for single-parse embedded systems) <Keybuk> to use conf.d rarely for complicated inter-twining defaults, and setting other configuration things that we define <Keybuk> and largely use jobs.d <Keybuk> (conf.d may make some more sense than states.d though, since you could just have an /etc/init/conf.d/udev that defined states for add->remove of all devices udev emits events for) #upstart 2007-06-12 <ion_> Sounds good. <madduck> Keybuk: is it just me or why did the installation of upstart just pull in a finger client? <madduck> are you using finger? <madduck> i am currently challenged by the task of authenticating users via unix sockets <madduck> http://lists.alioth.debian.org/pipermail/netconf-devel/2007-June/000128.html <madduck> and since upstart also uses unix sockets (i think), this attracted my attention. <madduck> anyway, if you or anyone has some input to the issue in the mailing list post, i would love to hear it. <madduck> but for now: sorry for spamming the channel <shawarma> madduck: I was recently made aware of SO_PEERCRED. <shawarma> madduck: Doesn't that solve your problem? <shawarma> -> /msg <madduck> someone else just said this <madduck> i am reading up on this now. -> /msg <Keybuk> madduck: I've no idea why it would pull in a finger client <madduck> shawarma: or #netconf/irc.debian.org <Keybuk> it shouldn't do, there's not one in the dependencies <madduck> Keybuk: i can't figure it out either. maybe it's the scottish beer in my head? <Keybuk> maybe <Keybuk> upstart uses SO_PEERCRED for authentication of commands <Keybuk> (one of the reasons it uses unix domain sockets and not a fifo <Keybuk> the other being the ability to pass file descriptors from initctl) <madduck> i am prototyping in python, so i hope it can do it. <madduck> i'll read up now. * Keybuk is catching up on some LCA talks :p <Keybuk> wasabi: in particular "Eat My Data: How everybody gets file I/O wrong" :p * Keybuk giggles at "gdb test_core" <Keybuk> freudian typo, that <Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070612135558-5cp54lvyxc5pwax5?start_revid=scott%40netsplit.com-20070612135714-innzwjnyivysns66 <ion_> Whee <AlexExtreme> \o/ <AlexExtreme> "Retain loading from /etc/event.d" << does that mean that it'll use jobs in both event.d and the new jobs.d? <Keybuk> yes <AlexExtreme> cool, that'll make upgrading easier ;) <Keybuk> they'll fight over job names right now <AlexExtreme> that's no problem for me, really <AlexExtreme> anyway, /me gets on with porting profiles to the new code <AlexExtreme> <ot>hmm, i like your new blog theme</ot> <Keybuk> the port should be quite easy, since now most of the hard work is taken care of for you by conf.c <AlexExtreme> yep <AlexExtreme> brb, testing latest bzr code <Keybuk> 732 is current <AlexExtreme> yep, got that <AlexExtreme> seems to work. although, moving all the jobs to jobs.d from event.d before booting the new /sbin/init wasn't one of my greatest ideas :p <AlexExtreme> had to sync and reboot -f <Keybuk> lol <AlexExtreme> Keybuk: should CONF_PROFILE also go into the ConfItemType enum in conf.h? <Keybuk> yup <Keybuk> actually, you'll want that to be CONF_PROFILE_DIR, no? <Keybuk> and then add a case for it and parse directories of profiles? <Keybuk> oh <Keybuk> right, CONF_PROFILE_DIR in ConfSourceType <Keybuk> and CONF_PROFILE in ConfItemTypoe <Keybuk> :p <AlexExtreme> ok <AlexExtreme> :) <AlexExtreme> hmm <AlexExtreme> Keybuk: is it right that there's a Job entry specifically defined in the ConfItem struct? <Keybuk> it's in a union <Keybuk> so there should be a Profile *profile there as well <AlexExtreme> ahh <Keybuk> so in the appropriate case bits you refer item->profile <AlexExtreme> right, forget i said anything :p #upstart 2007-06-13 <AlexExtreme> trying to code shortly after you wake up never works too well <Keybuk> morning <Keybuk> yeah I find that <AlexExtreme> i'm trying to work on this profiles code and my brain just says "uhh?" :p <Keybuk> have a bananananana :p <AlexExtreme> :D <AlexExtreme> oh well, bbl * Keybuk tackles the problem of namespace collision <Keybuk> too many structs :-/ <Keybuk> conf_sources -(hash)-> ConfSource -(hash)-> ConfFile -(list)-> ConfItem -> job/state/etc. <Keybuk> to track names, I'd need <Keybuk> namespace -(hash)-> Name -(list-> job/state/etc. <Keybuk> http://people.ubuntu.com/~scott/conf.jpg <Keybuk> :-( * Keybuk wonders whether objects of different types should share namespaces <Keybuk> e.g. should states and jobs share a namespace? <wasabi> states and jobs? <wasabi> states are jobs, no? <Keybuk> no <wasabi> you mean something other than what I was thinking you did, then <Keybuk> an example of a state is the period between tty-added and tty-removed for the same $TTY <Keybuk> this state can have multiple concurrent instances, since you can have multiple $TTYs <wasabi> Hmm. This is all getting very confusing. I like dit when you needed one file per tty. :0 <wasabi> It made the idea of a state easy: while job-name <Keybuk> heh <Keybuk> I like the idea of one file for all ttys <Keybuk> since they're identical <wasabi> Just being identically doesn't make it automatically a case to combine. <wasabi> identical <wasabi> What was wrong with our initial idea of jobs themselves defining named states? <Keybuk> doesn't work for the tty case <wasabi> Actually, I guess I don't really even know what I'm talking about anymore. Ya'll have probably done a lot of work since I was last in on it. <Keybuk> or the network interface case <Keybuk> it works on paper, but not for the use cases it's actually needed for <wasabi> Explain the tty case? <Keybuk> network interface is less controversial, so let's use that as an example <wasabi> Okay, that. ;0 <Keybuk> we have a pair of events with a common variable <Keybuk> interface-up eth0 <Keybuk> interface-down eth0 <Keybuk> so we can define the pairing and name that, say, interface-is-up <Keybuk> interface-up ... interface-down $IFACE <Keybuk> so when any interface comes up, the state is true <Keybuk> and when that same interfaces goes down, the state becomes false <Keybuk> ok? <wasabi> ok. <Keybuk> computers have multiple interfaces <Keybuk> we don't just want to track the first one that we see, we want to track them all <Keybuk> so when we see "interface-up lo", the state is true "for lo" <Keybuk> we might next see "interface-up eth0", now the state is true "for lo" and "for eth0" <Keybuk> next we might see "interface-down eth0" <Keybuk> this only matches the second half of the "for eth0" true state, so that state becomes false <Keybuk> now the state is only true "for lo" <Keybuk> by thinking in this way, we can answer the questions <Keybuk> is the state true for any interface (any network interface is up!) <wasabi> I'd start with a network job, which only started when Any interfaces were up, and stopped itself when the last interface went down. You can then depend on the start/stopped of that job to define a state where any interaface is up. <Keybuk> is the state true for a specific interface (or any non-lo interface) <Keybuk> wasabi: but that involves defining a job that tracks the up/down events it receives, no? <wasabi> Yes, it does. <Keybuk> how would you define a job that was running while any interface, apart from lo, was up? <wasabi> It would start on any interface up, and stop on any interface down. And the pre-stop handler would check if ALL interfaces were down, if not, it wouldn't really stop. <wasabi> In code. <Keybuk> the nice things about having first-class states is that you don't need to do that <Keybuk> upstart can track that for you <Keybuk> in fact, we then get to do things like <Keybuk> "is the set of paths that are mounted a subset of the following list?" <Keybuk> so upstart itself can track the problem of the writable filesystem <wasabi> interesting. <wasabi> Not sure if that's completely
{'channel': 'upstart', 'month': 6}