#upstart 2006-12-18
<zorglu_> q. i just heard 'rumors' saying that upstart may become incompatible with sysvinit initscript soon ? is there any fact behind that ?
<Keybuk> in Ubuntu, we always intend to support sysvinit scripts through the same compatibility jobs we do now
<Keybuk> there's no reason to every drop them
<Keybuk> legacy applications will continue to ship them, and the cost of supporting them is almost zero
<zorglu_> cool thanks
<zorglu_> for what it worth, i just read a web site and the design seems nice 
#upstart 2006-12-19
<_ion> keybuk: In http://upstart.ubuntu.com/wiki/ComplexEventConfig, it is said that and/or has higher precedence than until. Wouldn't that mean that 'from foo until frodo or from bar until bilbo' is equal to 'from foo until (frodo or (from bar until bilbo))'?
<Keybuk> _ion: I dunno, I'm a bit fuzzy about how that works :p
<Keybuk> I wrote what seemed to be right, but I think it's wrong
<Keybuk> that spec's still in drafting until I'm sure
<Keybuk> when it comes to precedence, I just remember that "division and multiplication beat subtraction and addition, for everything else, use parens"
<_ion> I started writing a parser based on the draft using racc (a yacc-ish parser generator for ruby) and i noticed '(from foo until (frodo or (from bar until bilbo)))' in debug output, that's why i asked. :-) Of course i realize it's still a preliminary document.
<_ion> Btw, have you considered using bison for parsing the config files? It would make defining and modifying the grammar quite easy, especially with the more complex rules.
<_ion> (Hmm, have i already asked this before?)
<Keybuk> I originally used bison/yacc
<Keybuk> and the code it generated was huge, and difficult to get it to work right
<Keybuk> it was easier to just write the parser by hand
<Keybuk> it's not that large after all (just the cfg_next_token function, really)
<_ion> Ok.
<gbutler69> On Ubuntu 6.10 can one create a config that will cause Upstart to start/stop in.telnetd as needed (instead of running inetd/xinetd)?
<gbutler69> Anyone?
<Keybuk> not in 6.10, no; the upstart version there has no facility to replace inetd
<_ion> racc is quite nice, there's a backend class (written in C for speed) in the ruby standard library; the generated parser files don't contain extra crud, they just subclass Racc::Parser.
<_ion> I'll try to get the graphviz thingy done some day. :-)
<gbutler69> KeyBuk: Thanks....that's what I was looking for? Out of curiosity, when will this support exist (planned)?
<Keybuk> gbutler69: ubuntu 7.10, I would guess
<Keybuk> it's not planned for upstart 0.3, which is aimed for Ubuntu 7.04
<gbutler69> KeyBuk: OK, thanks....
<Keybuk> that's not to say it won't happen, if someone codes it
<Keybuk> of course
<gbutler69> That was my next question....
<gbutler69> Need a volunteer to work on that?
<Keybuk> patches are always welcome
<gbutler69> OK...I think I'll start taking a look at it....probably won't get to it much until after the Holiday though....:)
<Keybuk> I'm hoping to get some upstart hacking done over the holiday
<Keybuk> will be my main chance to do it
<gbutler69> Should "upstartd" just listen for connections in place of "inetd/xinetd" or should replacement "indetd" be create that is part of the "upstart" package and it triggers the "connection received on port XX" events?
<gbutler69> Any vision for this yet?
<Keybuk> (...vague gut feeling: pid #1 shouldn't have net connections :p)
<gbutler> If I want to work on the "replace inetd functionality" for upstart, where should I begin documenting/proposing the how, why, and what?
<gbutler> I'd like to start work on the spec for Upstart handling "inetd" events/traffic. 
<gbutler> I can't seem to figure out the "Upstart Wiki" thing though. How does one go about editing/adding specifications to it?
<_ion> The wiki and the mailing list are good starting points.
<wasabi_> I'm not totally sure it's worth replacing inetd.
<wasabi_> I mean, honestly, inetd works fine.
<wasabi_> Or xinetd, whichever one you want.
<wasabi_> I doubt any of us want to tackle that complete code base (again)
<wasabi_> Maybe scott just can't wait, though. =)
<gbutler> wasabi_: Yes, I agree. I created a "lauchpad" entry and a spec placeholder. For the "Rationale" I put a lot of questions which basically all equate to, "Do we REALLY want upstart to replace inetd/xinetd?"
<gbutler> I figure it enough "Rationale" can be found, then maybe it's worth doing....but, as I sat trying to think of reasons, I couldn't come up with anything other than, "We'd like upstart to be the central place for Job Control".
<ced_> hey
<ced_> where can i find the upstart manual? man upstart does not return anything
<AlexExtreme> hmm
<AlexExtreme> IMO inetd functionality shouldn't be added
<_ion> Why not?
<AlexExtreme> it's a bit dangerous to have process 1 handling internet connections - if there was security flaw, it would be easy to bring down the system
<AlexExtreme> correct me if i'm wrong, though
<_ion> Since when is process 1 going to handle network connections?
<AlexExtreme> if inetd functionality is added...
<_ion> It's not as if it's going to be added to /sbin/init :-)
<_ion> init just launches stuff based on events.
<AlexExtreme> hmm
<AlexExtreme> :P
<AlexExtreme> <Keybuk> +(...vague gut feeling: pid #1 shouldn't have net connections :p) << Keybuk said the same ;)
<_ion> I believe everybody has that feeling. :-)
<_ion> keybuk: 'on foo and bar'  will upstart accumulate received events that match, and change the goal to 'start' when foo_received & bar_received == true? Will the accumulation of those events then be stopped until the goal is 'stop' again?
<Keybuk> yes to the first part
<Keybuk> when "foo" occurs, that node in the graph will be TRUE
<Keybuk> and when "bar" occurs, that node in the graph will also be TRUE
<Keybuk> the "and" parent node of both is TRUE only once both children are TRUE
<Keybuk> I'm not sure what the next bit suggests?
<_ion> I mean:
<_ion> on foo and bar
<_ion> stop on quux
<_ion> Let's 'foo', 'bar' are received, and then 'quux' is received.
<_ion> +say
<Keybuk> right
<Keybuk> the goal will be stop, job will be stopped
<Keybuk> the complex tree will be TRUE, but won't be evaluated, so won't cause the goal to change yet
<_ion> What i meant with the second question is that after the goal is set to stop, the state of 'on foo and bar' should be false again, until foo and bar are received again, right?
<Keybuk> no
<Keybuk> the state is TRUE
<Keybuk> both events have occurred, as prescribed
<_ion> All right.
<Keybuk> to explain why
<Keybuk> imagine foo is "fhs-filesystem-up"
<Keybuk> and bar is "network-up"
<Keybuk> and quux is "network-down"
<Keybuk> if the job is stopped when the network is down, you don't want to have to wait until the filesystem goes down and up as well
<Keybuk> you just want it restarted when the network comes up
<Keybuk> the way to cause the tree to be reset to FALSE is to use "untilo"
<Keybuk> (foo and bar) until quux
<Keybuk> now, when quux occurs, the other side of the tree is explicitly set to false
<Keybuk> foo and bar both have to occur again
<_ion> So the boolean value of 'on fhs-filesystem-up and network-up' will be calculated when (and only when) either 'fhs-filesystem-up' or 'network-up' is received, and if it amounts to TRUE, the goal will be changed to start?
<Keybuk> yes
<_ion> Ok, now i understand it. :-)
<Keybuk> the tree is evaluated upwards each time a node is changed
<_ion> Is 'on fhs-filesystem-up and network-up' equivalent to 'start on fhs-filesystem-up and network-up'?
<Keybuk> err?
<Keybuk> no
<_ion> Sorry, i don't see the difference. I've probably misinterpreted or misread something from the complex-event-config doc.
<Keybuk> that would match an fhs-filesystem-up event with the arguments "and" & "network-up" ?
<_ion> Hmm.
<_ion> How to match something with the argument 'and' from an 'on' or 'until' expression? :-)
<Keybuk> what do you want to match
<Keybuk> describe the state
<_ion> That was just a hypothetical example. What i'm really thinking is making 'and' a reserved word  something that can't be matched  and changing the 'start on' expression to what is defined as 'on' in complex-event-config. Perhaps make it possible to match a reserved word as follows: start on foo "and" bar
<Keybuk> the trouble is that the complex expression also defines when things stop
<Keybuk> not just when they start
<Keybuk> so "start on network-up until network-down" makes no sense
<Keybuk> which is why we decided it was separate from start on/stop on
<_ion> I thought it was "from network-up until network-down"
<Keybuk> like I said, it makes no sense to allow that for start
<Keybuk> from/on are just syntactic sugar
<Keybuk> network-up until network-down
<Keybuk> (where until is the joining operator)
<Keybuk> network-up until network-down and fhs-up until fhs-down
<Keybuk> block-device-added and network-up until network-down
<Keybuk> ^ block device added while there's a network
<Keybuk> the complex config is intended to be a discreet thing to start on/stop on
<Keybuk> with the latter just "easy options"
<_ion> Ok, i see.
<Keybuk> maybe it's not clear in the spec
<Keybuk> or maybe it just doesn't make sense for it to behave this way
<Keybuk> the problem we wanted to avoid was this:
<Keybuk>   start on network-up and fhs-filesystem-up
<Keybuk>   stop on network-down and fhs-filesystem-down
<_ion> So basically 'on' and 'from' are just ignored, but they are necessary in the beginning of a line?
<Keybuk> on startup, both network-up and fhs-filesystem-up happen
<Keybuk> then the network goes down, so network-down happens
<Keybuk> (err, that latter should be "stop on network-down OR fhs-filesystem-down", sorry)
<Keybuk> so the job stops
<Keybuk> but the "network-up and fhs-filesystem-up" bit is still TRUE (those events have both happened)
<Keybuk> so if you get fhs-filesystem-down followed by fhs-filesystem-up
<Keybuk> the job will get started, despite the network not being up
<Keybuk> that's what "until" is for
<Keybuk> "network-up until network-down" explicitly states that the fact network-up has happened is forgotten once network-down happens
<Keybuk> and once you have that, you can't easily express that in terms of start or stop
<Keybuk> because it says both
<_ion> Thanks for explaining.
<Keybuk> does that make sense?
<Keybuk> is it crack?
<_ion> I agree with almost everything, only the syntax could be a bit cleaner IMHO. I'd replace 'on' and 'from' with 'SOMESTANZA <expr>' where expr is a combination of '<event>', '<expr> and <expr>', '<expr> or <expr>', '<expr> until <expr>', 'with <job>'. Also 'with <job>' wouldn't be a valid line without the 'SOMESTANZA' in front of it.
<Keybuk> ok
<Keybuk> what's a suitable SOMESTANZA?
<_ion> Still thinking of that. :-)
<_ion> It should be short and self-descripting.
<Keybuk> the language for that syntax has caused us issues :)  e.g. "and" behaves more an intersection
<Keybuk> where as "A until B and C until D" in English implies a union
<Keybuk> and the English "A until B or C until D" implies a difference :)
<_ion> Actually, 'on' *is* quite good, but IMHO it should not be allowed inside <expr>, and 'from' being an alias for it causes confusion.
<_ion> I would change
<_ion> from network-up until network-down
<_ion> and from fhs-mounted until fhs-unmounted
<_ion> to:
<_ion> on network-up until network-down \
<_ion>     and fhs-mounted until fhs-unmounted
<_ion> Or instead of using a \ put the expression (after 'or') in parenthesis.
<_ion> I mean after 'on'
<Keybuk> is 'from' not better than 'on' ?
<_ion> I think there should only be one stanza, no aliases. I'm not sure whether it should be 'on' either. The syntax should allow any of the following:
<_ion> FOO some-event
<_ion> FOO network-up until network-down and fhs-mounted until fhs-unmounted
<_ion> FOO with apache or with httpd
<Keybuk> and get rid of "stop on" entirely?
<_ion> "start on <event>" and "stop on <event>" would still be there for simple event config, but "FOO <expression>" would be added for complex event config.
<_ion> line : 'start on' EVENT | 'stop on' EVENT | 'FOO' expression | ... ;
<_ion> expression : EVENT | expression 'and' expression | expression 'or' expression | expression 'until' expression | with JOB | '(' expression ')' ;
<_ion> Or something like that.
<Keybuk> ok
<Keybuk> that's pretty much what I was going for :)
<Keybuk> just gotta pick a FOO
<Keybuk> and get rid of the on/from bit
<_ion> Whoops, s/with/'with'/
<Keybuk> the reason for allowing multiple 'on's was to allow:
<Keybuk>   on foo and
<Keybuk>   on bar
<Keybuk> without requiring
<Keybuk>   on foo and \
<Keybuk>   on bar
<Keybuk> (ie. \ avoidance)
<_ion> Perhaps ignore a newline after and/or/until/with?
<_ion> FOO network-up until network-down and
<_ion>     fhs-mounted until fhs-unmounted
<Keybuk> perhaps
#upstart 2006-12-20
<_ion> summon Keybuk
<Amaranth> _ion: dang that usually works
<_ion> Darn.
<_ion> I just missed him.
<_ion> Hi Keybuk
<Keybuk> heyhey
<_ion> Here <http://johan.kiviniemi.name/software/bzr/upstart-ruby/upstart/cfgfile.y> is some preliminary parser code for this <http://johan.kiviniemi.name/software/bzr/upstart-ruby/testcfg> syntax.
<_ion> When the final syntax has been decided, i'll write the graphviz thing using that.
<Keybuk> cool
<_ion> I still haven't been able to come up with a good replacement for 'FOO'. :-)
<Keybuk> heh, me neither
<Keybuk> or event.d
<_ion> Perhaps someone at the mailing list would have a flash of creativity, after which we'd wonder why we weren't able to think of such obvious names.
<Seveas> /etc/state?
<Keybuk> Seveas: also contains services and tasks
<Seveas> /etc/upstart/{services,tasks,...] /?
<_ion> Seems like somewhat arbitrary difference for splitting them to different directories.
<_ion> /etc/upstart/services/foo and /etc/upstart/tasks/foo  what to do with 'start foo'?
<Seveas> /etc/tehpowah/
<Keybuk> /etc/init.d would be perfect, but it's already used :p
<_ion> :-)
<_ion> /etc/upstart would be quite good, but then what to do if we ever want to add configuration files for upstart, e.g. to define profiles?
<_ion> /etc/upstart.d?
<Keybuk> yeah, I've wanted to reserve "upstart" for config, etc.
<Keybuk> is ".d" appropriate?
<Keybuk> the ".d" is a weird thing :)
<_ion> Having the directories /etc/upstart and /etc/upstart.d would be quite confusing. :-)
<Keybuk> indeed
<Keybuk> /etc/abc.d
<Keybuk> /etc/substance.d
<Keybuk> (perhaps too literary)
<_ion> /etc/shizzle
<_ion> That would be difficult to forget. ;-)
<Keybuk> it could be worse
<Keybuk> an early name for "upstart" was "whend"
<Keybuk> complete with a logo of a woman in an apron
<cortana> so, can i delete /etc/inittab on an edgy machine?
<Keybuk> cortana: yes
<cortana> cool
<Keybuk> the only thing you'll lose is the "default runlevel" setting
<cortana> thought so, thanks
<_ion> "whend", hehe.
#upstart 2006-12-21
<Keybuk> o/~ I hate debugging
<Keybuk> *stretches*
<AlexExtreme> you know what? i've just switched to kde :P
<Keybuk> from?
<AlexExtreme> gnome
<AlexExtreme> have you ever had problems with gnome getting so unbelievably slow that it takes 10 minutes to download 15 emails?
<Keybuk> no?
<Keybuk> which mail client?
<AlexExtreme> thunderbird, but it's something to do with gnome because thunderbird is fine when run from other desktops
<_ion> I've tried KDE every now and then for a long time, and never found it nice enough to use. :-)
<_ion> Perhaps KDE 4 will change that. :-)
<AlexExtreme> anyway, this is a bit off topic... ;)
<AlexExtreme> yes, i'm looking forward to kde4
<AlexExtreme> brb
#upstart 2006-12-22
* Starting logfile irclogs/upstart.log
<_ion> We could rename /etc/event.d to /etc/
#upstart 2007-12-19
<mdales> morning
<mdales> what's the last moment I can have a job stop on shutdown on an ubuntu system? would it be on stopped rc0?
<ion_> http://ircimg.org/img/15762.gif
<quitte> hi. is upstart usable without sysvinit compatibility? is there a way to shutdown or reboot the system without sysvinit compatibility?
<quitte> couldsomeone hit me with a cluebat? I'm looking at /etc/rc0.d/S90halt. I thought that S meant start the script. but for start this script is a noop?
<mdales> quitte: read http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
<mdales> IIRC all scripts in rc0.d are sent stop, not matter what their name
<quitte> right. thanks. I fail to see why that is done,though.
<quitte> does ubuntu have any more scripts in event.d than the ones directly linked from the upstart.ubuntu.com page?
<mdales> quitte: pass
<mdales> quitte: I'm new to it all too, I just thought you mgiht find that info helpful
<quitte> yes. it definately was. I'm new to it myself. as it seems to be quite easy to write event scripts and found upstart in experimental I thought I might finally giveit a try.
<mdales> morning Keybuk 
<quitte> of course I immediately got stuck. Are there any plans about handling filesystems? It'd be nice if upstart were looking for both the device and the mountpoint. and as soon as both exist mounts the filesystem.  
<Keybuk> hey
<Keybuk> quitte: we're still working on a lot of the ideas for that kind of thing
<Keybuk> Upstart is still very much in development
<mdales> but is already pretty spiffy
<mdales> :)
<quitte> yes. the ideas are great. unfortunately it sounds as if it wasn'T complete eough to be a full sysvinit replacemet even for embedded devices with a very limit set of services
<Keybuk> it can replace sysvinit
<Keybuk> but it can't yet replace sysv-rc
<quitte> but I bet I'd have equal trouble with launchd
<Keybuk> many people confuse the two
<quitte> ah. I did, too
<Keybuk> it has all of the features of the sysv init daemon
<Keybuk> but does not yet have the ability to order the starting of tasks and services
<Keybuk> so you still need something like sysv-rc
<Keybuk> (ie the /etc/rc?.d directories)
<quitte> meh. well I guess I could use a single eventfile for every filesystem until you guyscome up with a solution.
<quitte> are subdirectories supported to group the files?
<Keybuk> yes
<Keybuk> you could always help with the solution ;)
<quitte> I could make it print hello world on the screen and even make it as for your name
<quitte> hmm. waiting for a file to exist isn't possible, yet?
<Keybuk> right
<quitte> :( I shouldn'T have watched the launchd techtalk. 
<Keybuk> oh?
<Keybuk> I haven't seen that?
<Keybuk> is it new?
<quitte> no. 20.7.
<AlexExtreme> <Keybuk> 15:25:33> +but does not yet have the ability to order the starting of tasks and services << i've done it ;)
<AlexExtreme> although in a pretty hackish way
<AlexExtreme> and no event based mounting/networking etc
<Keybuk> how did you do it?
<AlexExtreme> wait, do you mean just convert to a native upstart bootup without sysvinit scripts, or something else?
<Keybuk> yes
<AlexExtreme> yes to which one?
<Keybuk> the first one
<AlexExtreme> didn't you see what I did for frugalware?
<Keybuk> no...
<Keybuk> or I did, and I forgot
<AlexExtreme> let me find it
<AlexExtreme> http://ftp.frugalware.org/pub/other/upstart-jobs/upstart-jobs/
<AlexExtreme> that's the base jobs, there's some stuff elsewhere for other packages like dbus and friends, which I can't find
<Keybuk> you're using a single mount script?
<AlexExtreme> yes, as far as I can tell there isn't a good way to do it better, atm
<AlexExtreme> which is why I said it's a bit hackish
<Keybuk> *nods*
<AlexExtreme> but, i probably won't work on that anymore, seeing as I no longer develop for frugalware ;)
<Keybuk> oh, how comes?
<AlexExtreme> you forget stuff, i told you a while ago
<AlexExtreme> i wanted to work on my own projects a bit more, plus I have a lot of school work these days, so I don't get a lot of time for other stuff
<AlexExtreme> plus it annoyed me a little that they were so concerned about dumb little things like how the output of the bootup looked (that dodgy "initmsg" stuff in the jobs I linked before)
<AlexExtreme> i mean, it's ok to make it look "friendly", but they were more concerned about it than it actually working...
<AlexExtreme> anyway, </rant> ;)
<quitte> Keybuk: I just read th states blueprint and I may have a suggstion. wouldn't it make sense to have every event result in a state? for example events.d/hostname was successfully executed resultsin a state hostname is set?
<quitte> also if changing /etc/hostname caused an event that events.d/hostname registered for the hostname could be changed by just changing the file 
#upstart 2007-12-20
<foolano> ih
<foolano> hi
<Keybuk> hi
<foolano> is there any way to be notfied when upstart decides to stop respawning a job because the respawning is too fast?
<Keybuk> start on stopped foo failed respawn
<Keybuk> (ie. the "stopped" event for "foo" (the job) will have "failed respawn" as arguments)
<foolano> thx, gonna try that
<foolano> works like a charm
<foolano> this namespace thing is great
<foolano> i lived in the past when i used runit :P
<foolano> one more thing:
<foolano> according to the doc: Respawning will not generate a special set of events, instead it will generate the same sequence as a restart: stopping, starting and then started.
<Keybuk> right
<Keybuk> say squid crashes
<Keybuk> you'll get
<Keybuk>   stopping squid failed main
<Keybuk>     EXIT_SIGNAL=SEGV
<Keybuk>   starting squid
<Keybuk>   started squid
<foolano> ok
<foolano> i'd need to distinguish between a restart from a crash and a restart forced by the user
<Keybuk> restart from a crash will say "failed"
<Keybuk> restart by user will say "ok"
<Keybuk> ie.
<Keybuk>   stopping squid ok
<Keybuk>   starting squid
<Keybuk>   started squid
<Keybuk> (user runs "stop squid; start squid")
<Keybuk> it's ok, because it was expected to exit
<foolano> gonna use that
<Keybuk> start on stopping squid
<Keybuk> script
<Keybuk>   if [ "$2" = "ok" ]; then
<Keybuk>     # normal restart
<Keybuk>   elif [ "$2" = "failed" -a "$3" = "respawn" ]; then
<Keybuk>     # respawn limit hit
<Keybuk>   elif [ "$2" = "failed" ]; then
<Keybuk>     # crashed or terminated
<Keybuk>     # check $EXIT_STATUS or $EXIT_SIGNAL
<Keybuk>   fi
<Keybuk> end script
<foolano> great
<foolano> that's all i need :)
<foolano> thx a lot 
<foolano> Keybuk: the above script never enters into the last elif
<foolano> if my daemon has the respawn option
<foolano> if i comment it out it enters
#upstart 2007-12-21
<ion_> Another tech talk about git: http://youtube.com/watch?v=8dhZ9BXQgc4 (http://chi-v14.chi.youtube.com/get_video?video_id=8dhZ9BXQgc4)
<Keybuk> ion_: somewhat off-topic for here? :)
<ion_> Yes. :-P
<Keybuk> git is nasty
<ion_> Iâve fallen in love with it. :-)
<Keybuk> really, why?
<Keybuk> I've yet to see anything it can do that other distributed vcs's can, except make me feel like I'm back in the dark ages of revision control (the Arch days)
<ion_> It makes branches soooo nicely. I also like how you can âaddâ files to the next commit while developing something and then finally do the commit. In the others, youâd have to collect the list of files to be committed while running the actual commit.
<Keybuk> makes branches nicely?
<Keybuk> nicer than "cp -a" ?
<ion_> Hugely nicer than having each branch in a separate directory, adequately nicer than âbzr switchâ.
<Keybuk> it's identical to "bzr switch" isn't it?
<Keybuk> (assuming the branches share the same repository)
<ion_> Basically, but with a nicer UI.
<Keybuk> IME, the git UI is the worst thing about it
<Keybuk> like why would you ever want to make changes to something and not have them committed?
<Keybuk> which is the default behaviour of git
<ion_> Debugging lines
<Keybuk> so by default, most of the code you write is debugging lines
<Keybuk> and you want to only commit rarely?
<ion_> I just like how it works more. Not everyone might.
<Keybuk> that's a very kernel-optimised use case <g>
<ion_> git commit -a isnât very hard to write when you want what e.g. âbzr commitâ does.
<Keybuk> I find the bzr model of "shelve the debugging lines while commit" much nicer
<ion_> I also find it subjectively faster than bzr, but i havenât done any actual benchmarking.
<Keybuk> that was certainly true of network operations for older bzr versions
<Keybuk> I don't think it's been true for a while
<Keybuk> my main problem with git is it's optimised to assume that most of the operations you do are merges
<Keybuk> and that you rarely commit any changes you make to the source tree
<Keybuk> which is totally the opposite of any normal code tree
<Keybuk> almost all changes I make are to be committed, and I rarely get any to merge :)
<Keybuk> so git makes it harder for me to work with it
<Keybuk> and why use something that makes it hard when there are easy alternatives that are just as powerful
<Keybuk> I also like that bzr is written in a simple language like Python
<Keybuk> which makes it delightfully extendable
<Keybuk> there's bzr plugins to give you git-like commit workflow
<Keybuk> and bzr plugins to add rebase, etc.
<Keybuk> but because they're written as extensions to the bzr code, they feel like you're still using bzr
<Keybuk> they still work the same way
#upstart 2007-12-23
<schorpp> Md hi, I need some short info from You :)
<schorpp> Dec 02 23:21:59 *       Md (i=md@freenode/staff/md) has joined #linuxtv
<schorpp> Dec 02 23:24:53 <Md>    after (I think) upgrading the X server (to 7.3), anything which tries to access my saa7134 analog card (I tried xawtv, tvtime and even mplayer) fails with VIDIOC_DQBUF. any clues?
<schorpp> Dec 03 00:09:31 <Md>    buggy kernel, not X. upgrading to 2.6.23 fixed it
<schorpp> Q: which kernel version have You got running before?
<schorpp> i need to find this patch to fix saa7146 capture
<odla> i am running debian sid and i just installed upstart from experimental and i'm curious if i need to do anything special to get it to work?
<Md> no
<odla> Md: thanks
#upstart 2008-12-15
<sadmac2> ion_: ping
<ion_> sadmac: pong
<sadmac2> ion_: I just pushed a new version of the state machine
<sadmac2> ion_: it has some minor behavioral tweaks, and an example file with a real world demo of sorts
<sadmac2> (just a small example of drive mounting. designed to be played with more than just run)
<sadmac2> Keybuk: If you want to look at it, its a solution to your infamous mounting scenario
<Keybuk> pushed?
<sadmac2> Keybuk: git://fedorapeople.org/~sadmac/upstate.git
<Keybuk> do you have a description of what it does?
<Keybuk> or do I have to learn ruby?
<sadmac2> Keybuk: that mailing list post I made still describes the general idea.
<Keybuk> I didn't really understand that :p
<sadmac2> Keybuk: well shit :D
<Keybuk> you need to explain things better for people who can't read your mind :p
<sadmac2> Keybuk: its not a matter of mind reading. its a matter of having an unhealthy addiction to category theory ;)
<Keybuk> you're the only person on the planet with that :p
<sadmac2> the only one that universities let out of their math department basement
<sadmac2> Keybuk: well, you have states
<Keybuk> those kind of people never tend to leave university
<sadmac2> Keybuk: states are 1) a name, 2) a series of parameters in the name=value format
<sadmac2> true
<Keybuk> can you post to the ML?
<Keybuk> I'm doing other things right now, and don't log IRC
<sadmac2> Keybuk: good point
<Keybuk> (other things including a kernel patch that will make my world truly made of awesome, and solve one of my big upstart problems - which of course means it'll be rejected, but hey :p)
<sadmac2> Keybuk: what patch?
<Keybuk> 'tis a secret until it goes on lkml
<sadmac2> hmm
<sadmac2> we just tried waitfd, so....
<sadmac2> I'm guessing its that ring buffer dealie
<ion_> sadmac: Alright, the example works.
<ion_> Now if i only understood it. :-)
<sadmac2> ion_: well, the first 3 lines create states
<sadmac2> ion_: arguments are:
<sadmac2> name
<sadmac2> list of events that trigger it
<sadmac2> list of dependencies
<sadmac2> list of parameters that have to come from something other than dependencies (the event causing the state to come up, or the user if the user is starting it)
<sadmac2> that list of parameters can be like [a, b, c] or it can have little sub groups like [a, [b,c], c]
<sadmac2> the sub group means "at least one of these"
<sadmac2> Event::Epsilon is an event that happens any time it might cause something. So saying a state comes up on Event::Epsilon basically means it comes up whenever it can
<sadmac2> Event.new takes 2 arguments, a name of the event, and arguments
<sadmac2> for events that we're using for comparison, the arguments can have regex values
<sadmac2> so if the state starts on Event.new("Can_Mount", {:mount_str => /.*/}) it means the Can_Mount event will start it provided it has a mount_str argument, and that argument can have any value
<sadmac2> ion_: with me?
<ion_> Yeah, i think :-)
<sadmac2> ion_: try adding and removing stuffs from the events list to make more drives
<ion_> Iâm not sure i understand the output.
<sadmac2> ion_: red states are down, green states are up
<sadmac2> Firefox's spell check is british
<sadmac2> colors->colours
<sadmac2> friggin u
<sadmac2> ion_: has it all become wonderously clear now?
<ion_> Sorry, no. :-)
<sadmac2> ion_: anything I can do to help...
<sadmac2> at least until I hit lunch in 5mins :D
<Keybuk> sadmac2: how does this solve mounting?
<sadmac2> Keybuk: the example demonstrates it
<Keybuk> sadmac2: I have to install ruby then?
<sadmac2> Keybuk: ah, don't have it?
 * sadmac2 notices a glitch in the example
<sadmac2> pushed fix
<sadmac2> Keybuk: in the new state machine, you have a state for each fstab line, and a state for each device which udev notes to be present, and a mounted state that depends on those two
<sadmac2> Keybuk: and the parameters are properly collated depending on which are available
<sadmac2> Keybuk: the devicekit_hd state has blkdev, uid, and name properties (or whatever parameters you want to mount on)
<sadmac2> Keybuk: and the fstab state has one or more of those 3
<sadmac2> Keybuk: the mount state will only take a given pair of them as dependencies if their like-named arguments agree
<sadmac2> Keybuk, ion_: http://screwyouenterpriseedition.blogspot.com/2008/12/new-upstart-state-machine.html
<sadmac2> part 1 of many
<suihkulokki> curious name for blog =)
<ion_> sadmac: Thanks, will read.
<sadmac2> suihkulokki: I like it
<ion_> sadmac: Thanks for using red and green, which are hard to tell apart for some of us. :-P
<ion_> sadmac: I suggest making the âupâ ones bold.
<sadmac2> ion_: not a bad idea. that green doesn't read too well.
<suihkulokki> hmm. so say, if we'd have a state "offline()" or more precisely "rfkill()"
<suihkulokki> in what case would the state be up or down ?
<sadmac2> suihkulokki: we haven't gotten that far yet :)
<sadmac2> suihkulokki: the important thing to understand for that part is that they can be up or down, and that this doesn't effect their equivalence relation.
<sadmac2> s/relation/class/
 * sadmac2 wonders if anyone would have called him on that
<Keybuk> ok, so a state has a name, some parameters, and is either up or down
<Keybuk> I didn't understand the "mathy idea"
<sadmac2> Keybuk: ok, so there are only a certain number of valid values for name
<sadmac2> Keybuk: on a given system, you'll have dbus, gnome-session, etc.
<sadmac2> Keybuk: hypothetically, though, there's infinite possibilities for the parameters
<sadmac2> Keybuk: and a state exists for every one
<sadmac2> Keybuk: the point is, we don't talk about whether a state "exists" or not in this paradigm. It always exists. period.
<sadmac2> Keybuk: we talk about whether its running.
<Keybuk> states are jobs
<Keybuk> jobs have any environment
<Keybuk> there's no difference between a job not existing and not running
<sadmac2> Keybuk: that's what allows us to get away with it :)
<Keybuk> ?
<sadmac2> Keybuk: the principle is there to make it easier to talk about the workings of the mechanism
<Keybuk> so what I just described matches what you were describing?
<sadmac2> Keybuk: in a sense. it'd be more accurate to say that what you described was an implementation detail. Like the preface said, I'm just describing behavior.
 * Keybuk gives up
<sadmac2> Keybuk: you might be thinking too concretely. There's really no such things as jobs for this model :)
<sadmac2> Keybuk: this is something you put information into, and you get out a list of things that should be running
<sadmac2> and even that depends on you interpeting it that way.
<Keybuk> so there's no point me reading anything you write?
<Keybuk> fair enough
 * Keybuk goes
<ion_> Now, now
<Keybuk> seriously
<Keybuk> we're trying to write a replacement init daemon that's easy for sysadmins to use
<Keybuk> the O'Reilly book on Upstart does not need to have "all this book assumes is that you have several PhDs in advanced mathematics and number theory" in the introduction
<Keybuk> a sysadmin or distro maintainer will be thinking in terms of jobs
<Keybuk> (or at least services and tasks)
<Keybuk> so their requirements, dependencies, etc. need to be explained in that language too
#upstart 2008-12-16
<sadmac2> Keybuk: http://screwyouenterpriseedition.blogspot.com/2008/12/new-upstart-state-machine-part-2.html
<sadmac2> ignore what you didn't understand from the last post
<sadmac2> This should be simple enough
<ion_> sadmac: Concrete examples would be easier to grasp.
<sadmac2> ion_: that's part 4 :)
<ion_> Actual use cases instead of thystate and crunchy
<sadmac2> ion_: I don't want to redesign this thing again. Part of that means that rigor is very important to me.
<sadmac2> I want this thing to be perfectly defined. Its only its /presentation/ that has to be perfectly comprehensible.
<ion_> Explaining it in a way we mere mortals understand shouldnât require changing the design. :-)
<sadmac2> ion_: it doesn't :)
<sadmac2> ion_: but designing it in a way mere mortals understand requires changing the design every time someone says "well what about this?"
<sadmac2> ion_: the fact is mere mortals don't have to know how it works for most values of "how it works"
<sadmac2> ion_: relational databases: "put shit in tables," "Use joins"
<sadmac2> ion_: that's a piss-poor picture of the relational model, but its almost enough to not screw up with postgres
<ion_> Please give us the piss-poor picture of your design. :-)
<sadmac2> ion_: you have states. they are either on or off. they can require others to be on before they come on. they can be made to come on upon certain system events, whenever their dependencies are satisfied, or automatically.
<sadmac2> ion_: there's another process that will start a service whenever a particular state is on
<Keybuk> what about the process that sets the state based on the service?
<sadmac2> Keybuk: when does that happen?
<Keybuk> what else would you set states from?
<sadmac2> devicekit signals, user request, etc
<sadmac2> events
<Keybuk> D-Bus signals (like those from DeviceKit) are very definitely events, not states
<Keybuk> I think the most common case is dependencies on other jobs
<sadmac2> right
<Keybuk> with the second most common case being the existing of particular D-Bus objects
<Keybuk> (which is defined as the period between two well known events with common parameters)
<sadmac2> still with you
<Keybuk> though defining D-Bus signals is just a world of ugh
<sadmac2> the split beetween Pid 1 (the service manager) and Pid X (the state machine) is what I want to firm up the most
<Keybuk> from dbus(NAME=org.freedesktop.DeviceKit, PATH=/org/freedesktop/DeviceKit, MEMBER=org.freedesktop.DeviceKit.DeviceEvent, 1="add") until dbus(NAME=org.freedesktop.DeviceKit, PATH=/org/freedesktop/DeviceKit, MEMBER=org.freedesktop.DeviceKit.DeviceEvent, 1="remove", 2=$2)
<sadmac2> Keybuk: we can probably macrify a lot of that. especially for something like devicekit that we'll be hitting up all the time
<sadmac2> from US_DEVKIT(1="add") until US_DEVKIT(1="remove", 2=$2)
<Keybuk> of course, that requires from/until to match the right side against the left
<Keybuk> which is pretty essential
<sadmac2> Keybuk: I think we probably had it right before
<Keybuk> before?
<sadmac2> Keybuk: from have_device(%1) until lost_device(%1)
<Keybuk> right
<sadmac2> Keybuk: where have_device and lost device are something that is specifically sent to the state machine
<Keybuk> while <STATE>  -- defines a match on STATE
<sadmac2> and causing those events due to whatever is SEP
<Keybuk> from EVENT until EVENT  -- defines a match on a state defined as EVENT ... EVENT (rhs of a state matches against left)
<Keybuk> before <STATE> -- defines a match on the opposite side of the STATE transition to while
<sadmac2> whoa. do we need that?
<Keybuk> omgyes
<Keybuk> while ~= started -> stopping
<Keybuk> before =~ starting -> stopped
<sadmac2> oic
<sadmac2> I kind of like the idea of specifying the state names for each of these
<sadmac2> foostate while otherstate
<sadmac2> let me explain why:
<Keybuk> but you're inherently specifying the state name
<Keybuk> because you're writing it in the job file ;)
<Keybuk> or the state definition file ;)
<sadmac2> Keybuk: that's my issue
<sadmac2> Keybuk: I want to dissociate states from files
<sadmac2> Keybuk: consider replacing runlevels.
<sadmac2> Keybuk: we have a series of states, defined however, but none of them have auto
<Keybuk> I don't want to replace them, I want to kill them dead :)
<sadmac2> Keybuk: well, we need some way to group services based on what kind of system the user wants running
<Keybuk>   /etc/init/docked:
<Keybuk>     while service1
<Keybuk>     while service2
<Keybuk>     while service3
<Keybuk> docked is true if they're all running
<Keybuk> and you can start/stop docked manually to enter/leave that state
<sadmac2> ah, damn
<sadmac2> I don't think in terms of pulling the dependencies well yet :)
<Keybuk> of course, you might arguably want to separate the dependencies from the requirements
<sadmac2> Keybuk: you might want them to come from another place
<sadmac2> /etc/init/docked-foopkg: error: file not found
<sadmac2> yum install foopkg
<sadmac2> /etc/init/docked-foopkg:
<sadmac2> docked while fooservice
<Keybuk> makes it hard to find out what docked is
<Keybuk> you have to grep multiple trees of files
<sadmac2> Keybuk: we have to support that case somehow though
<sadmac2> Keybuk: also, that case kind of demonstrates why "while" might be a poor choice
<sadmac2> it reads "whe are docked while fooservice is running"
<sadmac2> which feels particularly backward for that state
<sadmac2> I propose "implies"
<sadmac2> docked implies fooservice
<sadmac2> brb lunch. my backlog should contain you if you keep going :)
<ion_> For that,
<ion_> /etc/init/foo:
<ion_> while docked
<sadmac2> ion_: that means the opposite
<sadmac2> ion_: that means whenever you started foo, the system would enter the docked state
<ion_> I propose it doesnât. :-)
<sadmac2> ion_: then what goes in /etc/init/docked?
<ion_> from devicekit-said-dock-connected until devicekit-said-dock-disconnected
<sadmac2> ion_: so foo gets while foo; auto
<ion_> Huh?
<sadmac2> ion_: while docked; auto
<sadmac2> ion_: sorry
<sadmac2> hmm... a implies a
<sadmac2> how do tautological states behave?
<ion_> Whatâs this auto thing?
<sadmac2> ion_: a state doesn't start just because its deps are satisfied unless auto is specified
<sadmac2> ion_: otherwise its deps satisfied + got event
<sadmac2> The more I describe this state machine the more I realize its a great deal more powerful than I thought :)
<sadmac2> Its can do some things I didn't think of
<sadmac2> mount_state(dev: %1, mountpoint: %2) { action: mount $dev $mountpoint }
<sadmac2> ^^ignore that...
<sadmac2> mount_state(dev: %1, mountpoint: %2, type: %3) { action: mount -t $type $dev $mountpoint }
<sadmac2> mount_state(dev: %1, mountpoint: %2, type: funkyfusefs) { action: funkyfusemounter $dev $mountpoint }
<sadmac2> its like haskell, but in a good way
<sadmac2> ion_, Keybuk: http://screwyouenterpriseedition.blogspot.com/2008/12/new-upstart-state-machine-part-3.html
<sadmac2> ^^practical examples included (start reading when you see fstab lines)
#upstart 2008-12-17
<Keybuk> sadmac2: unless I'm mistaken
<Keybuk> you've not described anything new, just used a different language to describe what we were already talking about
<Keybuk> *and* haven't actually solved the filesystem mounting "problem" as defined
<Keybuk> lit. that it is not possible to do native upstart mounting of filesystems _without_parsing_fstab_to_create_the_states/jobs_
<Keybuk> also you don't appear to solve the /usr/local must be mounted after /usr issue (but there's no pitfall either, since you parse fstab you can work out whether you need a dep)
<sadmac2> Keybuk: that its mostly the same is a good thing. Most of what's new is the rigor: its very meticulously defined. The other new thing is the very freeform way deps work. st(a: 1, *) -> b() and st(c: 1, *) -> d() means st(a: 1) depends on b(), st(c: 1) depends on d(), and st(a: 1, c: 1) depends on b() /and/ d()
<sadmac2> Keybuk: for the mountpoint issue we can just add one dep: mounted(mountpoint: %1) -> file_exist(name: %1)
<sadmac2> that state would have to be a bit special internally but its not hard to write
<Keybuk> but you do have to preparse fstab
<sadmac2> Keybuk: I don't know that a lot of that information is defined anywhere else. You could rely on disklabels being equal to the mountpoint, but that's not good
<Keybuk> still doesn't help
<Keybuk> so we still need a binary to parse fstab and create upstart states/events/jobs for the information there
<Keybuk> which is pretty much where I got to :p
<Keybuk> the only real question is how much of that binary is logic only
<Keybuk> and how much is implementation
<Keybuk> ie. does it just say "when you see blah, run the upstart job blah"
<Keybuk> or does it actually define what the upstart job is (fsck on ...)
<sadmac2> Keybuk: I don't think we need a binary
<sadmac2> Keybuk: its just a few calls to getmntent()
<Keybuk> so you need a binary
<sadmac2> Keybuk: why put that in another application? its 3 lines of code
<Keybuk> where else would you put it?
<Keybuk> it's not something I'd want to hardcode into init
<sadmac2> Keybuk: it could essentially go in the state machine
<Keybuk> only if init parses fstab
<Keybuk> which is just wrong ;)
<sadmac2> Keybuk: ah, but the state machine isn't /in/ init anymore, remember?
<Keybuk> especially if you wanted to develop a system that did rely on lvm labels, or btrfs, etc.
 * Keybuk still doesn't think that's possible
<sadmac2> its more than possible. its easy
<sadmac2> Init only needs 2 dbus methods (strictly speaking. there may be good cause for more):
<sadmac2> init.run(handle, script, script_on_fail)
<sadmac2> init.stop(handle)
<sadmac2> when a state comes up that corresponds to a job, it calls init.run("name_of_state(args: foo)", "exec /sbin/mytask", "emit failed job=$HANDLE")
<sadmac2> when the state machine gets a failed event, it downs the state matching the job argument thereof
<sadmac2> you're probably not putting /enough/ in userspace the way you're picturing it. Pid 1 is now just a glorified bash shell with really good session management
<sadmac2> (and dbus instead of stdin)
<Keybuk> you know that pid 1 is in userspace, right? :p
<Keybuk> I don't see what your split buys us, except a much more complex code base
<sadmac2> Keybuk: yeah, whatever the hell you call it :)
<sadmac2> Keybuk: the split is good for separation of concerns. From outside of the two, jobs are states, but from within, the state machine doesn't really know there's such a thing as jobs and the service manager doesn't know anything about states
<Keybuk> but it doesn't work ;)
<Keybuk> the two become so closely coupled, that you're inherently more inefficient by having the split
<sadmac2> Keybuk: They're pretty decoupled the way I set it up abouve
<sadmac2> *above
<Keybuk> pid 1 would have only one method
<Keybuk> exec()
<Keybuk> takes a command, returns a handle
<Keybuk> that handle/object would have only one signal complete()
<Keybuk> and only one method stop()
<Keybuk> complete would say what exit code, or signal, etc.
<Keybuk> stop would send TERM/KILL
<Keybuk> -- 
<Keybuk> which means it's incapable of doing anything on its own
<Keybuk> the pid 2 would have the full state machine
<Keybuk> but to do anything has to invoke all the methods and listen to signals on 2
<Keybuk> on 1, even
<sadmac2> it can't do anything automated on its own
<Keybuk> this does not make anything simpler, it makes it much more difficult
<sadmac2> it costs little to invoke those methods
<Keybuk> it costs impossibly more than just having a C method call to do it
<Keybuk> bear in mind as well that pid 1 is the pid that knows about forks and children dying
<sadmac2> right
<Keybuk> so even a status() call needs additional methods/signals to talk between the two
<Keybuk> I don't see that this makes anything better
<sadmac2> status is either starting,started,stopping,or stopped
<sadmac2> that works from the previous mechanism
<sadmac2> the state machine only thinks about the service being in two of those: started and stopped
<Keybuk> so pid 1 needs a state machine
<Keybuk> in fact, pid 1 needs *the* state machine
<Keybuk> so what is pid 2 doing? :p
<sadmac2> pid 2 = generate a list of what is supposed to be running. pid 1 = make the system reflect that, and scream when this is impossible.
<Keybuk> I don't think you're buying anything by separating the two
<Keybuk> except complexity for no good reason
<sadmac2> I want the two to be decoupled in the design.
<sadmac2> If they're in the same process or not.
<Keybuk> they're decoupled in the *current* design (0.3/0.5)
<Keybuk> they're in different .c files, after all
<sadmac2> if you look at the state machine as nothing but mathy bits and lights turning red and green; that is to say if you ignore the fact that programs are supposed to be started/stopped in relation to it, you should be able to add /exactly/ 3 things to it and have it able to manage services
<sadmac2> 1) rising edge actions: some arbitrary piece of code that is run when a state becomes up
<sadmac2> 2) falling edge actions: the same run when a state becomes down
<sadmac2> 3) fail-on events: the ability to have an event cause a state to go from up to down /without/ running the falling edge actions
<Keybuk> err
<Keybuk> but we're not writing a mathy state machine
<Keybuk> we're writing something that programs are started and stopped by
<Keybuk> I think it's dangerous to try and think the two are unrelated
<sadmac2> the state machine is unrelated to the services in the sense that the strings and integers you use in your program are unrelated to the electrical charges on the bits of sillicon in the box under your desk.
<Keybuk> you mean they're the same thing?
<Keybuk> which I think is my point
<sadmac2> I don't think they're the same thing. In a sense the first doesn't even exist.
<Keybuk> services *are* the states
<sadmac2> for some value of services
<sadmac2> states don't have a pid, or a vm area, or a task_struct, or signal handlers....
<sadmac2> states are conditions. they are true or false values
<sadmac2> you shouldn't need any system calls to set something to true or false
<Keybuk> it being true is dependant on syscalls having been run
<Keybuk> likewise it becoming false again is also dependant on that
<sadmac2> true
<sadmac2> but states don't /fail/
<sadmac2> they can become false for any of umpteen reasons
<sadmac2> but there's no real "break"
<Keybuk> I think you're thinking too much in terms of mystate and thystate
<Keybuk> you need to think about dbus and apache
<sadmac2> mystate and thystate is a trivial problem
<sadmac2> dbus and apache are not
<sadmac2> but making dbus and apache /appear/ like mystate and thystate is
<sadmac2> so its two trivial problems or one complicated one
<Turl> any way to speed up ubuntu boot process? I'm open to testing new things
<Keybuk> roll it down a hill?
<ion_> Overclock the modem.
<sadmac> Value Add!
<mbiebl_> Keybuk: hi
#upstart 2008-12-18
<sadmac2> Keybuk: ping
<Keybuk> evening
<sadmac2> evening
<sadmac2> Keybuk: when you said you weren't planning to start working on Upstart again until "Next Year," was that the next year that starts 2 weeks from now or the one 365 days away?
<Keybuk> 2009
<sadmac2> Keybuk: somewhere between the two then?
<Keybuk> right
<Keybuk> releasable version of 0.10 targeted for ~October next year
<Keybuk> which pretty much aligns it with DeviceKit as well
<sadmac2> nice
<sadmac2> Keybuk: I think I'm going to re-prototype the state machine. I can do it in python (which you can read) or I can do it in C (which can not only be read, but serve as copy-pasta for the actual system).
<Keybuk> being able to read it would be handy
<Keybuk> I don't really want to have to learn ruby just so I can see what you're doing differently to me (if anything)
<sadmac2> yes :)
<sadmac2> ruby is fairly easy to read usually, but the state machine I wrote is kinda asshole-ish
<sadmac2> it does scary things.
<Keybuk> ruby is only easy to read if you know ruby ;)
<sadmac2> plus in describing the state machine I actually ended up improving it, so it isn't quite an accurate example anyway
<sadmac2> its a subset of what I described, but its missing some properties
<sadmac2> (and it will actually be simpler to implement taking those ideas into account)
<geiseri> is anyone here versed in upstart?  i am trying to migrate a inittab line to upstart and it flat out wont work.
<geiseri> x:23:once:/bin/su root -l -c "/bin/bash --login -c startx >/dev/null 2>&1" <- this is the exact line
<sadmac> geiseri: what do you have so far?
<geiseri> one sec, let me copy it into pastebin
<geiseri> http://paste.ubuntu.com/88079/
<geiseri> it just seems to fail silently
<geiseri> is there a place to look and debug it?
<sadmac> geiseri: silent failure is often due to a syntax error.
<sadmac> geiseri: I believe it will show up in /var/log/messages
<geiseri> ah, okay let me check there
<geiseri> what should i be looking for, i cant really see anything there
<geiseri> does my syntax i pasted look remotely correct?
<sadmac> geiseri: it looks about right
<sadmac> geiseri: you can try init=/sbin/init -v on your kernel command line to get lots of noisy output
<geiseri> sure, its an embedded box, so its a bit sluggish on startup :D
<sadmac> heh
<geiseri> that is interesting, i saw the ttys startup via the screen output, but my Xorg one was not started.
<geiseri> do i have to set the mode on it to a specific value?
<geiseri> oh wait syslog as something
<mbiebl> Keybuk: what are your plans regarding upstart 0.5.x and the next ubuntu release?
<geiseri> sadmac: here is the output http://paste.ubuntu.com/88088/
<geiseri> it looks like it keeps starting and stopping Xorg because its exiting?
<ion_> Redirect the scriptâs output to a log.
<geiseri> just do a exec /bin/su detos -l -c "/usr/bin/startx" 2>&1 >> logfile?
<ion_> Seems about right.
<geiseri> k
<ion_> The 2>&1 probably should be after the >>
<geiseri> okay this is strange... it cannot seem to write the log file
<geiseri> ah, typo :P
<geiseri> http://paste.ubuntu.com/88110/ <- here is the log.. .its strange its identical to when i start it up manually except for line #48
<geiseri> it looks like something it killing the server before it gets out of the gate
<ion_> Did you try the entire script manually, including the su invocation?
<geiseri> yes, it works
<ion_> Try setting PATH manually in the script.
<ion_> Hm. Was there a stanza for path in Upstart?
<geiseri> did i miss that?
<geiseri> i still think its strange that it starts but then exits right away... you think if it was a failed library or something it would scream.
<ion_> Also try startx -- -verbose 10 -logverbose 10
<ion_> (i pulled the 10 out of my ass)
<geiseri> http://paste.ubuntu.com/88117/ <- okay this looks interesting...
<geiseri> could not get file descriptor of the console?
<ion_> Try adding âconsole ownerâ to the job file.
<geiseri> just at the top of the job file?
<ion_> Yeah, at any line.
<geiseri> okay testing it again :)
<Keybuk> mbiebl: I don't think I have any
<mbiebl> Keybuk: so no further "upstartification" of init scripts for jaunty?
<mbiebl> What bits do you consider missing, for doing so?
<Keybuk> mbiebl: indeed
<Keybuk> well, the fact that upstart 0.5 doesn't work?
<geiseri> ion_: okay this is really strange, i can startx via the console as the detos user, but i get the "X: user not authorized to run the X server, aborting." message
<mbiebl> Keybuk: could you be more specific?
<Keybuk> mbiebl: it doesn't solve the problems that need to be solved to move init scripts to upstart
<Keybuk> it's still a pain in the arse to express when they should be running
<Keybuk> and common problems are almost impossible without changes
<mbiebl> Even if you started with a top-down approach?
<mbiebl> I don't think services like smartd, hald etc, need a complex start dependency
<mbiebl> i.e. rc2 could be implemented using native upstart jobs imo
<Keybuk> hal needs to be started by d-bus activiation but only while dbus is running
<Keybuk> (and brought up automatically)
<geiseri> ion_: now if i set the Xwrapper.conf to allow anyone to start X it now works... why could that be?
<ion_> I have no idea.
<mbiebl> maybe hal was a bad example.
<geiseri> ion_: what  was the console owner line suppose to do?
<sadmac> mbiebl: there is a bit more that could be done with it, but why?
 * geiseri wonders if he needs to run something like mingetty to get a console before X starts.
<sadmac> mbiebl: its all going to have to be redone again once we fix the model
<mbiebl> sadmac: service monitoring?
<mbiebl> seeing, which service is running?
<Keybuk> most init scripts have a "status" option
<sadmac> mbiebl: its a pretty high cost to convert any large number of scripts
<mbiebl> Keybuk: but that is a hack, imho
<Keybuk> sure, but it works okish
<Keybuk> I can spend my time doing useful work to make Ubuntu boot faster, and improve upstart
<Keybuk> or I can spend it converting things to upstart now
<mbiebl> sadmac: what would we have to change (for a service like smartd)?
<mbiebl> do you have plans to completely change the config format?
<sadmac> mbiebl: yes
<mbiebl> oh
<sadmac> mbiebl: the changes will make upstart semantically different. the config format won't even be expressing the same meaning
<Keybuk> well, that depends
<mbiebl> sadmac: is there a summary / roadmap, what the current plans are?
<Keybuk> not yet
<mbiebl> I'm quite surprised by what you say
<sadmac> mbiebl: http://screwyouenterpriseedition.blogspot.com has some (still controvertial) details on things I've been thinking about (top 4 posts)
<Keybuk> (you get an award if you can understand his blog posts
<Keybuk>  lit. you get to explain them to the rest of us :p)
<sadmac> Keybuk: take a look at the most recent of those. Events shouldn't have any surprises in store, but still.
<mbiebl> ;-)
<Keybuk> mbiebl: the summary of the change is actually quite simple
<Keybuk> right now jobs are:
<Keybuk>   start on <some event expression>
<Keybuk>   stop on <some event expression>
<Keybuk> this will change to:
<Keybuk>   while <some state expression>
<ion_> geiseri: It opens /dev/console instead of /dev/null as std{in,out,err} for the job and does a magic TIOCSCTTY ioctl (not sure if itâs needed here). :-)
<Keybuk> a good, simple, example would be a dbus apache service
<Keybuk>   start on started dbus and started apache
<Keybuk>   stop on stopping dbus or stopping apache
<Keybuk> vs.
<Keybuk>   while dbus and apache
<Keybuk> except, the big difference is that if you restart apache, your service will actually be restarted
<Keybuk> with the start on/stop on model, your service would simply be stopped
<geiseri> ion_: it looks like really what i need to do is edit the XWrapper.config file... its an embedded system with no ttys so it shouldnt be a problem.
<mbiebl> hm, right, as you would be waiting for the dbus started event
<Keybuk> exactly
<mbiebl> so, the new mantra is "states" not events anymore
<Keybuk> well
<Keybuk> states are still based on events
<Keybuk> you'll get states for jobs for free
<Keybuk> and you can define states based off other states
<Keybuk> or off events
<Keybuk> you can combine them in jobs too
<Keybuk>   on control-alt-delete
<Keybuk>   while multi-user
<Keybuk> --
<Keybuk>   on battery-low
<Keybuk>   while docked
<Keybuk> etc.
<Keybuk> jobs can't be started if their while clause is not true
<mbiebl> any roadmap for this kind stuff?
<Keybuk>   or if their while clause cannot be made to be true
<Keybuk> the latter gives us dependency behaviour
<Keybuk>   while apache and mysql
<Keybuk> start foo
<Keybuk> will start apache and mysql as well
<geiseri> ion_: thanks for the help anyway.
<sadmac> Keybuk: I think for the conf file format we should use a sort of python-style syntax
<sadmac> foostate(arg1: %arg):
<sadmac>      while bar
<sadmac>      on baz
<sadmac> Keybuk: this means we can do the break a state across files thing, and keeping states in one file only adds 1 line to the file
<sadmac> Keybuk: so it pushes the decision to distro maintainers
<Keybuk> but I don't want to break a state across files
<sadmac> Keybuk: /you/ don't
<Keybuk> that's the advantage of being the author :p
<sadmac> Keybuk: and this doesn't hurt you much if you choose not to
<Keybuk> it hurts compatibility between distributions
<sadmac> there's no such thing
<Keybuk> there should be
<Keybuk> brb
<Keybuk> distributions shouldn't *need* different upstart job files for the same service
<Keybuk> upstream authors should feel confident in shipping them in their own tarballs
<sadmac> but they'll have them anyway
<sadmac> no two distributions even install apache in the same folder
<sadmac> (and oh dear lord help us if anyone put it where upstream says you should)
<Keybuk> I thought we all put it in /usr
<Keybuk> with the config in /etc/apache2 ? :)
<Keybuk> you'd be surprised how much commonality there actually is these days
<sadmac> Keybuk: its in /etc/httpd here
#upstart 2008-12-19
<sadmac> Keybuk: and it "belongs" in /usr/apache/conf if upstream has their sya
<sadmac> *say
<Keybuk> oh, that's right, you guys rename it for some inexplicable reason
<sadmac> Keybuk: so do you.
<Keybuk> we call it apache2
<sadmac> yep. Its not supposed to be.
<sadmac> its supposed to just be apache, and (scarier) its not supposed to be in etc
<Keybuk> ok, true, it should be apache
<Keybuk> but apache is apache 1.x
<sadmac> Keybuk: the plot thickens...
<sadmac> Keybuk: at any rate, its already getting ugly this idea of distro-compatible scripts
<sadmac> Keybuk: if you force them to be in one file, you are going to see people do things with sed that you can't unsee
<sadmac> in package post-install scripts
<mbiebl> sadmac: I think simple/trivial scripts could surely be cross-distro
<mbiebl> acipd, smartd, 
<mbiebl> atd ...
<sadmac> mbiebl: well they're welcome to, but we aren't talking about simple, trival scripts. We're talking about /all/ scripts
<sadmac> this is blanket policy
<Keybuk> things have to be upstream
<Keybuk> because if they're not upstream, then we have to maintain them as a divergence from Debian
<Keybuk> and that hurts
<Keybuk> if they're uniform, then upstream can put them in the tarball
<Keybuk> and Debian takes Upstart through the back door
<sadmac> someone's going to be taking it through the back door alright :)
<sadmac> I don't think it will happen
<sadmac> even still, I think the python syntax will make more sense anyway with the new state machine
<Keybuk> depends
<Keybuk> I actually have a vague theory about being able to specify multiple things in one file
<Keybuk> like if you're defining apache, you should be able to put the daily log rotation job in there too
<Keybuk> so one bit defines the daemon, then you define a different while/on clause, with a different task/service attached
<sadmac> Keybuk: the way it is now, you could have:
<sadmac> foostate(bar: baz):
<sadmac>     when something
<sadmac> foostate(bar: bang):
<sadmac>     when something else
<sadmac> Keybuk: and those conf items could apply to two different states /or both apply to the same state/
<sadmac> Keybuk: foostate(bar: baz) will get the first when, foostate(bar: bang) gets the second, foostate(bar: baz, bar: bang) gets both
<ion_> Real-life examples would be so much nicer. :-)
<sadmac> ion_: there's actually a good IRL one in the blog posts for this particular case
<sadmac> mount(...):
<sadmac>     (mount stuff here)
<sadmac> mount(type: nfs, ...):
<sadmac>     when network
<sadmac> mount(type: somefusefilesystem, ...):
<sadmac>     (non-standard mount command used)
<ion_> Much better. :-)
<sadmac> the stuff under the first mount line applies to /all/ mounts.
<sadmac> the latter two apply only to mounts of a particular filesystem type
<Keybuk> though that optimises the uncommon case again
<sadmac> Keybuk: its not terribly expensive
<Keybuk> assert ( cost == 0 );
<sadmac> Keybuk: the reason I allow the state machine to behave this way is because it would cost me extra effort not to. I'd have to explicitly state it was impossible.
<sadmac> cost < 0
<Keybuk> err
<Keybuk> I only care about the cost to a user
<Keybuk> like I said, we're writing an init daemon here
<Keybuk> not a math paper
<sadmac> in terms of implementation details its easier to write
<Keybuk> if the implementation is harder, but gives a better user experience, I'd rather go with the harder implementation
<sadmac> I see this only as a gain
<sadmac> I see no disadvantage other than semantics of files, which I have no interest in preserving
<Keybuk> it makes the files harder to understand
<Keybuk> you need to know more about what's going on under the hood
<Keybuk> you can't just do
<Keybuk> cat > /etc/init/some_service
<Keybuk> while ...
<sadmac> It looks pretty obvious to me
<Keybuk> exec ...
<Keybuk> ^D
<sadmac> this is what you do to mount a filesystem
<sadmac> this is what's different if its nfs
<sadmac> this is what's different if its a funky filesystem
<Keybuk> but it isn't obvious
<Keybuk> what the hell is the stuff before the :
<Keybuk> is that the while clause?
<sadmac> name of state, arguments to state
<Keybuk> while ...:
<Keybuk>   ...
<Keybuk> exactly, you suddenly force everyone to define a state to define a service
<Keybuk> I don't like that
<sadmac> if jobs /are/ states, that's kind of inherent
<Keybuk> let's use a simple example then
<Keybuk> how would you define the job for the dbus session bus daemon?
<sadmac> dbus_session_daemon(%session):
<Keybuk> it runs for each instance of the x-session state
<sadmac>     when x-session(id: %session)
<sadmac>     auto
<sadmac>     exec /usr/bin/dbus-session
<Keybuk> ok
<Keybuk> instead of exec, use eval - that puts the $DBUS_SESSION_BUS_ADDRESS into the job's environment
<Keybuk> that environment variable is required for anything that depends on dbus_session_daemon
<Keybuk> modify the definition, and show a job that depends on dbus_session_daemon and gets that address
<sadmac> dbus_session_daemon(%session):
<sadmac>     when x-session(id:....
<Keybuk> no ...s :p
<sadmac>  /* blah blah, skip to last line*/
<sadmac> ok
<sadmac> dbus_session_daemon(%session):
<sadmac>     when x-session(id: %session)
<sadmac>     auto
<sadmac>     eval DBUS_SESSION_BUS_ADDRESS=%session /usr/bin/dbus-session
<Keybuk> I don't understand your eval line there, could you explain it?
<sadmac> it substitutes %session for the session argument
<Keybuk> err, but DBUS_SESSION_BUS_ADDRESS is printed *by* dbus-session
<Keybuk> that was my point
<Keybuk> you run dbus-session, grab its stdout, and you get something that looks like an envvar
<sadmac> ah, I misunderstood the question
<Keybuk> interestingly, your model is like 0.5 in its treatment of instances
<Keybuk> in that you have to explicitly define what makes a job unique
<Keybuk> in your case there, you have to say that it's unique per value of %session
<Keybuk> I assume that if you try and start one, you have to give a value for %session
<Keybuk> I'm guessing that:
<Keybuk> singleton():
<sadmac> Keybuk: if you start it manually yes
<Keybuk>   exec foo
<Keybuk> can only be run once?
<Keybuk> you can't start multiple copies
<sadmac> no
<Keybuk> no you can't, or no you can?
<sadmac> you can't
<sadmac> you could do something like:
<sadmac> singleton(%_nonce_):
<sadmac>     exec foo
<sadmac> where nonce would be some unique ID that would be filled in for you.
<Keybuk> ok
<Keybuk> so let's say you wanted to run a service in a chroot
<Keybuk> or a group of services
<Keybuk> you'd have to add %chroot to everything?
<sadmac> depends.
<sadmac> if they all run in the same chroot then definitely no
<Keybuk> why no?
<Keybuk> I mean have a second copy of everything across two chroots
<Keybuk> for the record, btw, my equivalent would look like:
<Keybuk> while x-session
<Keybuk> eval /usr/bin/dbus-launch --sh-syntax
<Keybuk> export DBUS_SESSION_BUS_ADDRESS
<Keybuk> while dbus-session-bus
<Keybuk> exec /usr/bin/dbus-session-service
<Keybuk> err
<Keybuk> while x-session
<Keybuk> eval /usr/bin/dbus-launch --sh-syntax
<Keybuk> export DBUS_SESSION_BUS_ADDRESS
<Keybuk> --
<Keybuk> while dbus-session-bus
<Keybuk> exec /usr/bin/dbus-session-service
<Keybuk> --
<Keybuk> gap between the two jobs got lost there :p
<sadmac> you have to define 2 states?
<Keybuk> one for the dbus session bus
<Keybuk> the other for the service you want to run on it
<Keybuk> they're services, not states, in my model
<sadmac> oh
<sadmac> right
<sadmac> ok, seeing that I can answer your question
<sadmac>     when x-session(id: %session)
<sadmac> wait...
<sadmac> dbus_session_daemon(%session):
<sadmac>     when x-session(id: %session)
<sadmac> shit. too quick on the copypasta
<sadmac> dbus_session_daemon(%session, %busaddr):
<sadmac>     when x-session(id: %session)
<sadmac>     auto
<sadmac>     busaddr := exec /usr/bin/dbus-launch --sh-syntax
<sadmac> dbus_session_service(%busaddr):
<sadmac>     when dbus_session_daemon(%busaddr)
<sadmac>     auto
<sadmac>     exec DBUS_SESSION_BUS_ADDRESS=%busaddr /usr/bin/dbus-session-service
<Keybuk> I think my way is easier :)
<sadmac> I don't
<ion_> In this case, Keybukâs syntax wins.
<sadmac> ok
<sadmac> Keybuk: how do you express the mounting case?
<Keybuk> there's not enough info in yours to tell
<Keybuk> could you expand yours a little
<sadmac> let me flesh them out
<sadmac> mount(%mountpoint):
<sadmac>     when file-exists(%mountpoint)
<sadmac> damn!
 * sadmac needs an irc line editor
<Keybuk> I just use vi and paste ;)
<sadmac> yeah, doing that way now
<sadmac> mount(%mountpoint, %devname): when file-exists(%mountpoint) exec mount %devname %mountpoint
<sadmac> mount(auto: true): auto
<sadmac> wow. fail
<sadmac> mount(type: nfs): when network()
<sadmac> mount(type: ntfs, %mountpoint, %devname): exec ntfs3g-mount %mountpoint, %devname
<sadmac> ok, that, but with linebreaks
<sadmac> mount(%mountpoint, %devname): when file-exists(%mountpoint) exec mount %devname %mountpoint
<sadmac> mount(auto: true): auto
<sadmac> mount(type: nfs): when network()
<sadmac> mount(type: ntfs, %mountpoint, %devname): exec ntfs3g-mount %mountpoint, %devname
 * sadmac goes to file a bug against IRSSI
<Keybuk> hmm
<sadmac> I'll pastebin it then
<Keybuk> surely that's wrong
<Keybuk> according to your own blog
<Keybuk> mount(type: nfs): ...
<Keybuk> simply creates a state where type = nfs
<Keybuk> it doesn't bind that to any dependant states
<Keybuk> what you mean is
<sadmac> Keybuk: no
<Keybuk> mount(%type):
<Keybuk>   when ... type=nfs ?
<sadmac> Keybuk: no
<Keybuk> no?
<sadmac> mount(type: nfs) means that the below config items apply to all mount states such that type = nfs
<sadmac> Keybuk: and you never create states in my model
<sadmac> Keybuk: you just say when they'll be on
<Keybuk> oh, I see
<sadmac> Keybuk: the syntax on my blog was designed to facillitate mathiness. It won't always resemble this
<Keybuk> err
<Keybuk> so each ...(): is like a while clause?
<Keybuk> so
<Keybuk> dbus_session_daemon(%session):
<Keybuk>   ...
<Keybuk> defines both the dbus session daemon
<Keybuk> *and*
<Keybuk> something that depends on the dbus session daemon?
<Keybuk> to simplify
<Keybuk> I want food to run
<Keybuk> (heh)
<Keybuk> foo(...):
<Keybuk>    exec /usr/sbin/food
<Keybuk> now I want bard to run along side that
<Keybuk> I could either do
<Keybuk> bar(...):
<Keybuk>    when foo
<Keybuk>    exec /usr/sbin/bard
<Keybuk> or
<Keybuk> foo(...)
<Keybuk>    exec /usr/sbin/bard
<sadmac> Keybuk: those are slightly different in one way. notice how I kept the auto keyword?
<Keybuk> yes, I didn't get that
<sadmac> Keybuk: in your first writing, it is possible to bring up foo, then bring up bar, but bringing up bar will always bring up foo.
<Keybuk> right
<Keybuk> but it means there's two different ways to make one job run with another
<sadmac> Keybuk: in your second example, both executables shadow the same state, so they are completely non-independant
<sadmac> Keybuk: the second is a bad idea
<Keybuk> I'd place a bet now that the second is what most people will write ;)
<Keybuk> in fact
<Keybuk> I'd bet you that what most people will write is:
<Keybuk> runlevel2(...):
<Keybuk>    exec my daemon
<sadmac> Keybuk: let me translate my dbus one into english
<sadmac> dbus_session_daemon(%session, %busaddr):         // For a state dbus_session_daemon with arguments session and busaddr of any value
<Keybuk> oh, I think I actually understand how your model works now :)
<Keybuk> it's quite neat
<sadmac> ok.
<sadmac> let me stop there, because I might confuse you again :)
<sadmac> tell me what you've found
<Keybuk> you define states
<Keybuk> and you define things to be done when a given state is true
<Keybuk> "jobs" are the latter
<Keybuk> the former are done by things like initctl I guess
<Keybuk> so your fstab example works because you define states for the items in fstab
<Keybuk> and the jobs defined items that are processed when those things are true
<Keybuk> foo(...):
<Keybuk>    exec foo
<Keybuk> foo(...):
<Keybuk>   when ...
<Keybuk>   exec bar
<Keybuk> actually adds the when to both?
<Keybuk> the when introduces the dep to foo, not to the short clip of things-to-be-done-when-foo-is-true, right?
<sadmac> assuming the (...) is the same for both
<sadmac> right
<ion_> pe025244  * sadmac goes to file a bug against IRSSI
<sadmac> ion_: yeah, I should go do that
<ion_> How about turning paste_join_multiline off?
<sadmac> ion_: good idea!
<Keybuk> I think the problem you're going to have is explaining your model in such a way that people don't do
<Keybuk> runlevel2():
<Keybuk>    exec my_service
<Keybuk> because the simplest paragraph
<Keybuk> "BLAH: exec..." defines a service to be run while the BLAH state is true
<Keybuk> is going to tell people to do exactly that
<sadmac> Keybuk: there is some issue there, and some of it can be fixed with more syntax, but fortunately you and I will control most of the initial usage of this :) I think that once my terse and formal self is out of the room and you open up a system defined this way and actually look at the examples it will become clear
<sadmac> Keybuk: in the long run I don't think its terribly difficult for a sysadmin to do, even if the short term might include a bump or two. It should become natural over time.
<sadmac> I like about this one that common sense does work quite a bit better for it than for many other models I've played with.
<Keybuk> I'd be interested to see if you could write an example page of the "writing a service" documentation
 * Keybuk likes writing end-user documentation as a design method
<sadmac> I could do that.
<sadmac> Keybuk: one of the big goals here was actually to be mathematically rigorous, and for a good reason. We're doing this rewrite because we kept finding out things about the previous mechanism that hadn't occured to us.
<sadmac> It may be an up hill battle explaining the minutiae of this thing, but no one will /EVER/ tell me something about it that surprises me. Its definition is thorough and complete.
<sadmac> notting: you missed Keybuk suddenly understanding what I've been yammering about for the past 2 months :)
<geiseri_> hey, how do i change the order of things in the event.d directory, i am on intrepid and my event broke because it needs to wait for hal to start.
<geiseri_> on started hal  <- is this what i should have there?
<geiseri_> if hal is the rc.d step?
#upstart 2008-12-20
<sadmac> Keybuk: http://en.wikipedia.org/wiki/File:Principia_Mathematica_theorem_54-43.png
#upstart 2008-12-21
<ion_> http://ubuntu.de/
<sadmac> ion_: wth
<Keybuk> It's a Circus
 * sadmac noticed
<Keybuk> there's an Ubuntu Cola too
<sadmac> I always end up finding that horse thing when I look at ubuntu
<Keybuk> that horse thing?
<sadmac> I found a stable called Ubuntu
<sadmac> then theres ubuntu.org, which redirects here: http://www.ubuntu.upc.edu/
<Keybuk> sure
<Keybuk> they've always owned ubuntu.org
<Keybuk> even before we came along
<sadmac> what's the name of the markup language pydoc uses?
<Keybuk> is there one?
<sadmac> yeah, and its got some funky name
<Keybuk> *shrug*
<Keybuk> never heard of a name
<Keybuk> or even of a standard markup language for it
<sadmac> Keybuk: reStructured Text
<sadmac> its a PITA because if you don't know that name, you can't find shit on the internet about how to write pydoc
<Keybuk> oh, that's a fairly standardish one isn't it?
<Keybuk> I don't think it's a pep standard for pydoc
<sadmac> Keybuk: all the python people around me say use it, and it doesn't seem like you have to do anything interesting to make pydoc parse it
#upstart 2009-12-14
<ion> keybuk: Some small fixes, https://code.edge.launchpad.net/~ion/ubuntu/lucid/mountall/lucid
<ion> keybuk: Also an autoreconf commit is needed at some point.
<Keybuk> I've been committing autoreconf as I go
<Keybuk> it builds here ;)
<ion> conf/Makefile.in doesnât install the new conf/mounted-* files even though conf/Makefile.am was updated.
<Keybuk> oh, I probably didn't test that yet
<ion> Before making the $MOUNTPOINT guard change, i hosed my virtualbox test machine by running âstart mounted-tmpâ without thinking. find happily proceeded to delete files under /. ;-)
<Keybuk> lol
<Keybuk> that's pessimal
<Keybuk> I shall take a look
<Keybuk> just catching up with e-mail atm
<ion> Iâm not sure if iâm doing the right thing in the âHandle remounts againâ commit, but it does make my VM boot again. The âNow supports multiple filesystem types listed in fstabâ commit caused mounted () never to be called after the successful remount of /.
<Keybuk> oh, hmm
<Keybuk> yeah that's probably a bug
<Keybuk> because forcing parse_mountinfo() won't reflag it as mounted
<Keybuk> this whole filesystem thing is a hard problem <g>
<Keybuk> though I'm happy that more code is moving out of mountall again now - fits the idea better that it'll be a tool to parse files and auto-generate upstart jobs from them
<ion> Yeah
<ion> Also, i finished Voyager last night. Next up: Enterprise.
<Keybuk> my god
<Keybuk> you brave man
<ion> Iâve been watching all Star Trek series in the original air date order.
<ion> Yes, even TAS.
<ion> It was hilariously bad.
<Keybuk> I watched DS9 end-to-end
<Keybuk> I had thought that I hadn't watched much of it before
<Keybuk> but in practice, it's turned out that I had watched almost all of the first six seasons
<Keybuk> right
<Keybuk> that's me caught up on e-mail and bugs now
<Keybuk> I shall have breakfast then look at your branch, ion
<Keybuk> ion: around?
<ion> keybuk: Around.
<Keybuk> ion: still around? :)
<ion> Yeah
<Keybuk> so I've merged a couple of your patches, but not most of them
<Keybuk> 196: I don't see what this patch does
<Keybuk> from what I can tell, this would hide valid errors that should break the hook script
<Keybuk> the stated aim is to handle the file not existing, but the [ -f ... ] && on the front *already*does*that*
<Keybuk> no?
<ion> [ -f /etc/motd.tail ] && whatever when /etc/motd.tail doesnât exist â false && whatever â false â the script dies with set -e
<Keybuk> no it doesn't
<ion> Ah, sorry.
<Keybuk> -e will only terminate the script on statuses that you do not check
<Keybuk> otherwise it'd terminate on every "if" or "while"
<Keybuk> http://www.opengroup.org/onlinepubs/009695399/utilities/set.html
<ion> I just looked at sh -ec '[ -f /etc/motd.tail ] && cat /etc/motd.tail' and saw it returning 1. I should have added â; echo fooâ to it to make sure and not just assume.
<Keybuk> -e  When this option is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value >0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit.
<Keybuk> "and is not a part of an AND or OR list" being the key bit
<ion> Yeah
<Keybuk> 198 I've done in a different way
<Keybuk> 199 was fixed already but not pushed
<ion> Yeah, you fixed remounts better indeed.
<Keybuk> 201 I just don't agree with
<Keybuk> if I'd wanted to fix the hooks to only be possible to run with certain mountpoints, I would have just hardcoded the paths instead of actually using $MOUNTPOINT :)
<Keybuk> if people run those by themselves, and screw up, that's their own funeral <g>
<ion> Alright. But it might be non-obvious to sysadmin that a âstart mounted-tmpâ might delete everything. How about a [ -n "$MOUNTPOINT" ] check?
<Keybuk> if sysadmins are going around starting random jobs without even reading them, that's their own fault
<ion> Ok
<ion> Is dying if a connection to plymouth fails the right thing to do?
<Keybuk> that being said, Upstart should have more of a facility for "required arguments"
<Keybuk> ion: yes, I think so
<Keybuk> otherwise mountall won't be able to get help from the user
<ion> Ok
<wasabi> So. Ever considered a feature in Upstart to parse /etc/init.d files and build a bunch of jobs in a rc.* namespace? :)
#upstart 2009-12-15
<temoto> Hello. What does task keyword mean?
<temoto> couldn't find any complete documentation btw
<sadmac> temoto: task means that you're defining something that runs to completion, not a continuously running service
<sadmac> temoto: so, fsck for example. You expect it to finish. It doesn't run forever.
<temoto1> sadmac: thanks. What about documentation?
#upstart 2009-12-16
<Keybuk> Non-root users get strange output when they run initctl which tries to get information from system dbus.
<Keybuk>  $ initctl list
<Keybuk> initctl: Name "com.ubuntu.Upstart" does not exist
<Keybuk> sadmac_: ^ really?
<Keybuk> WFM
<plautrba> Keybuk: it's current state in fedora now
<plautrba> and "strange" means that it should say something like you need to be root or someting
<Keybuk> no
<Keybuk> strange means that it should work
<Keybuk> quest scott% initctl list | head -2
<Keybuk> avahi-daemon start/running, process 948
<Keybuk> mountall-net stop/waiting
<plautrba> I agree that it should work
<Keybuk> you don't have to be root to use commands like list, status, etc.
<temoto1> How to run upstart in user home?
<temoto1> I had a day of pain trying to run upstart in debian lenny, without installing it system-wide.
<Keybuk> temoto: just install there and use init=/home/temoto/sbin/init ?
<temoto> Keybuk: without installing it system wide, also implies without touching existing init system :)
<temoto> i could write a line into inittab or something, that's not the point
<Keybuk> right
<Keybuk> you don't need to
<Keybuk> ./configure --prefix=$HOME/upstart
<temoto> troubles were in just starting it
<Keybuk> then when you boot, init=/home/temoto/upstart/sbin/init
<Keybuk> on the kernel command-line
<Keybuk> it'll look for config in /home/temoto/upstart/etc/init obviously
<Keybuk> so you'll have to provide some
<Keybuk> otherwise it won't do much
<temoto> i don't want to replace init
<temoto> but that's not the point
<Keybuk> then you're in the wrong place
<Keybuk> Upstart isn't a word processor ;)
<Keybuk> it's a replacement for init
<temoto> i wanted it to manage separate user jobs.
<Keybuk> it's not designed to do that
<temoto> ah
<Keybuk> it must be pid 1
<Keybuk> you can comment out the code that requires it
<Keybuk> but you lose things like daemon supervision and stuff
<temoto> well init says you can run telinit and it doesn't want to be pid 1
<temoto> but i actually had troubles with dbus connection
<temoto> it says /com/something is unknown
<temoto> i did sudo ~/upstart/sbin/telinit 2
<Keybuk> I think you're confusing yourself
<temoto> Does that loose daemon supervision?
<Keybuk> telinit simply communicates with the init daemon
<Keybuk> it's identical to running "initctl emit runlevel RUNLEVEL=2 PREVLEVEL=$(runlevel)"
<temoto> That's why it couldn't connect to /com/something?
<Keybuk> just easier to type
<Keybuk> yes
<Keybuk> the thing it couldn't connect to was Upstart
<temoto> Thanks :)
<Keybuk> something was "com.ubuntu.upstart"
<temoto> Yeah.
<temoto> Thanks for explanation.
<temoto> Maybe it deserves to be mentioned on website.
<Keybuk> why?
<Keybuk> Upstart is a replacement for Init
<Keybuk> if the website listed everything that Upstart wasn't, it'd take months to download
<temoto> Maybe it's more obvious that Upstart is not a game and less obvious that you can't run supervisor part without replacing Init. I just proposed, if no, then no, fine. Thanks for explanation anyway.
<Keybuk> "Upstart is an event-based replacement for the /sbin/init daemon"
<Keybuk> (the first sentence on the website)
<Keybuk> I just don't get how people can read that, and think that they can use Upstart without replacing /sbin/init ;)
<temoto> What about documentation on stuff like `task' ? Does it exist anywhere? sadmac explained it, but i couldn't find.
<Keybuk> I mean
<Keybuk> that's like asking whether you can run HURD as a normal user :p
<Keybuk> temoto: yes, in the man page
<Keybuk> man 5 init
<temoto> Great, thanks.
#upstart 2009-12-17
<erUSUL> what is the correct way to disable gdm starting (Xserver) on boot. what is the equivalent of Â« sudo update-rc.d -f gdm remove Â» ?? found this http://ubuntu-ky.ubuntuforums.org/showthread.php?t=1322949
<erUSUL> but it is way to hacky 
<erUSUL> s/to/too/
<ion> Comment out the âstart onâ stanza.
<erUSUL> ion: that's what the forum entry says... but that's too hacky isn't it ?
<ion> Or make /etc/X11/default-display-manager an empty file
<ion> Whatâs hacky about it?
<erUSUL> ion: directly editing long conf files ;)
<ion> Thatâs how you configure stuff. :-P
<erUSUL> ion: ok; there si no "good" way yet.. i spected someting like:
<erUSUL> sudo upstart-config disable [options] [service_name] 
<erUSUL> or the like
<ion> And what would that do? It would change the configuration somewhere.
<plautrba> or it could rename job file to not end with .conf
<erUSUL> plautrba: that would suffice ? that's less hacky in my book
<erUSUL> plautrba: just sudo mv /etc/init/gdm.conf /etc/init/gdm.conf.disabled
<plautrba> erUSUL: but you won't be able start that job even manually
<erUSUL> that's way more palatable for me
<erUSUL> ouch!!!
<ion> Why not just uninstall gdm if you donât want it?
<erUSUL> that's not the question. you may want to disable a service for many reasons... what when apache is managed by upstart? you wont be able to disable it starting at boot ? your only option will be to remove it?
<ion> Comment out the âstart onâ stanza.
<erUSUL> ok;
<erUSUL> fair enough.
<erUSUL> thanks for all the help. have anice day
<ion> Pre-dormancy nutrition protocols engaged.
<Keybuk> huh?
<ion> Startrekish for âate supperâ
<Keybuk> "hmm"
<Keybuk> http://www.todaysbigthing.com/2009/12/07
<ion> DJOâs Star Trek videos are awesome.
<sadmac2> ion: you're kind of a crazy person, and that's cool, I'm feeling it.
<ion> http://www.youtube.com/user/dayjoborchestra
<sadmac2> I thought someone just handed me a new high-severity issue 1/2 hour before I leave work.
<sadmac2> moment of rage
<ion> Work on it for Â½ hours and let someone else finish it. ;-)
<sadmac2> I actually do have one that needs to be handed to australia before I can finally stop working today
<Keybuk> hmm
<Keybuk> now I'm catching up on the Interwebs
<Keybuk> I do see the "OMG! MARK SHUTTLEWORTH IS LEAVING CANONICAL!" screaming
#upstart 2009-12-18
<MarcWeber> How to handle this automount case? If /auto is active and you stop autofs then autofs just prints "Can't shutdown, /auto still active"..
<MarcWeber> However when you release /auto (by cding away) it still doesn't stop. Either upstart should resend some signals or automount should recall that it should shutdown when /auto can be released..
<Keybuk> there probably is no event for a filesystem being in use or not
<MarcWeber> Keybuk: Maube automount should umount -l /auto and exit?
<MarcWeber> I don't know which party to patch.
<Keybuk> filesystems are hard
<Keybuk> they're pretty integral to the "upness" of a system
<Keybuk> bringing them up and tearing them down has proven quite the tough cookie
<MarcWeber> What is the default signal being send to the job to make it quit?
<Keybuk> TERM usually ;)
<MarcWeber> Maybe I should start this on stopping : "set -e; while :; do pkill -TERM automount; sleep 1; done
<Keybuk> or have automount "stop on starting OTHERJOB"
<MarcWeber> What is OTHERJOB?
<MarcWeber> When I say stop that job I want it to stop.
<Keybuk> what you were thinking of putting that code into
<Keybuk> ie.
<Keybuk> if you have
<MarcWeber> The problem is that automount get's the signal but ignores it.
<Keybuk> /etc/init/umount.conf
<Keybuk>   exec umount -a
<Keybuk> and you need automount stopped first
<Keybuk> then
<MarcWeber> The script keeps resending the TERM signal. Upstart sends it only once
<Keybuk> /etc/init/automount.conf
<Keybuk>   stop on starting umount
<Keybuk> sure
<Keybuk> Upstart sends it once
<Keybuk> waits for automount to get its act in gear
<Keybuk> if it doesn't follows up with SIGKILL
<MarcWeber> IF SIGKILL is sent /auto keeps mounted. I guess this is a autostart bug.
<MarcWeber> It should umount -l then..
<Keybuk> yes
<Keybuk> automount shouldn't ignore SIGTERM
<Keybuk> how do you tell automount to stop normally?
<MarcWeber> It doesn't. But it neither unmounts its filesystems.
<MarcWeber> You send TERM ?
<Keybuk> you said it ignored TERM :p
<MarcWeber> IT does if you cd into the /auto directory..
<MarcWeber> if you don't it will exit.
<Keybuk> how does it know?
<MarcWeber> Don't ask me. Probably it tries umount /auto and notices that that command fails
<Keybuk> oh
<Keybuk> right
<Keybuk> so don't do that then ;)
<MarcWeber> That's not an option.
<MarcWeber> I'm a human. I am allowed to make mistakes causing trouble..
<MarcWeber> :)
<Keybuk> usually you kill all processes before unmounting anyway
<Keybuk> ie. killall5 -TERM; killall5- KILL; umount -a
<MarcWeber> Keybuk: It's another issue: I'm using NixOS. It restarts the job whenever the configuration changes. So maybe I should write an exception for that job as well ..
<Keybuk> possibly
<MarcWeber> hehe. How do you run halt then?
<Keybuk> after the filesystems are unmounted
<Keybuk> (you remount root read/only rather than unmounting)
<MarcWeber> Then the command may be gone..
<Keybuk> halt is on the root
<MarcWeber> So you umount everything but root
<Keybuk> yes
<MarcWeber> How long will upstart wait until it sends SIGKILL (if there is no on stopping script running?)
<ion> keybuk: Gotta beam off some poop. Start running around. http://www.youtube.com/watch?v=l4HMCCspbUE
#upstart 2009-12-19
<penguin42> Hi, I can see a file in /etc/init.d/ssh but it doesn't get listed in initctl list - why?
<Younder> How does upstart deal with the syslogd? I just installed psad (apt-get) and want to make sure kern is set to the /var/lib/psad/psadfifo named pipe.
<JanC> Younder: if you are using Ubuntu 9.10 then have a look at the config files in /etc/init/
<Younder> yeah, psad is set up now (and reports back to DShield)
#upstart 2010-12-20
<dash9> Hi, I want to create an upstart job, which starts a daemon. The application can be run so that it stays in the foreground, or it can be run so it goes to the background. Which mode should I use? I would prefer the first, so I don't have to specify "expect fork". Any reason why the second is better? 
<dash9> Where can I find example upstart config files (by using a web browser)?
<ion> A daemon is typically ready at the point it daemonizes, but not yet at the point itâs executed. Daemonizing is one of the ways to tell Upstart âiâm startedâ. With the current release of Upstart, one needs to be very careful with the expect stanza to avoid confusing Upstart: the program must fork in precisely the expected way. For job definitions, look at /etc/init.
<dash9> http://upstart.ubuntu.com/faq.html#native-jobs-where points to https://code.launchpad.net/~keybuk/upstart/replacement-initscripts but this page does not exist, can someone fix the documentation?
#upstart 2010-12-21
<benc> I'm writing an upstart script for an erlang server
<benc> the erlang server has a script that can start/stop/ping it
<benc> how do I combine it with the upstart script?
<benc> when using "status myserver" I guess I'm asking upstart what it thinks but this functionality is already implemented in the server itself
<Keybuk> Upstart is designed with the idea that services don't just fall over by themselves and stay running
<Keybuk> so you should find that your "status" script is unnecessary
<Keybuk> gee, hang around for the answer, why don't you
<benc> what is the upstart version on ubuntu 10.10?
<Keybuk> benc: 0.6.7-1 currently
<benc> thanks
<Keybuk> benc: http://launchpad.net/ubuntu/+source/upstart is the place to check that kind of thing out
<benc> ok
<Keybuk> benc: before you vanished earlier, I was going to suggest the following
<Keybuk>   exec command-to-start-erlang-server
<Keybuk>   pre-stop exec command-to-stop-erlang-server
<Keybuk> that may or may not work for you
<Keybuk> if it doesn't, you may be able to do
<Keybuk>   pre-start command-to-start-erlang-server
<Keybuk>   post-stop command-to-stop-erlang-server
<Keybuk> (with no exec or script)
<Keybuk> err pre-start exec, post-stop exec
<Keybuk> but no exec/script on their own
<benc> your first suggestion seems right
<benc> what about status?
<benc> which is ping in my server script
<Keybuk> there isn't support for overriding that in 0.6
<Keybuk> because upstart assumes that if the pid is alive, then the service is running
<benc> and logs?
<benc> maybe if the pid is alive the erlang server is running. not sure
<Keybuk> there's a conversation on ubuntu-devel about extending the "service" command to run custom status scripts
<Keybuk> that might interest you
<benc> on ubuntu-devel in irc?
<JanC> the mailing list
<benc> thanks. searching
<pmatulis> is it possible to ensure a network-required upstart job (upon shutdown) will always have the network resources available?
<soren> What would be a common reason why "stop foo" would hang?
<JanC> upstart looking at the wrong PID ?
<soren> Possibly.
<soren> I guess this thing may not actually be daemonising properly.
<soren> Ah...
<soren> Right, of course.
 * soren plays around a bit
<soren> Oh, I see what's going on.
<soren> Darn it.
<soren> I need a "expect <forks three times>".
<JanC> soren: good luck with that ;)
<ion> You need Upstart 0.10 :-)
<SpamapS> soren: guessing you have a script + an oldschool daemon (forks twice) ?
#upstart 2010-12-22
<SpamapS> Hrm.. the runlevel man page says that the environment variable 'RUNLEVEL' will be set .. "during boot" .. but it seems that its not always set on every event.
<mbiebl> SpamapS: it is only set for sysv init scripts afaik
<mbiebl> or for jobs triggered on the runlevel event
<SpamapS> mbiebl: right, I suppose its a readily accessible global variable, so its not that important. ;)
<SpamapS> I do wonder if there's a way in pre-start to determine what event caused me to start. I need to only start on started portmap when runlevel != [016]
<JanC> I think it's set after telinit is run for the first time
<JanC> which happens in rc-sysinit
<SpamapS> so its probably set in the scripts..
<SpamapS> but not on the events
<SpamapS> /etc/init/tty1.conf:start on stopped rc RUNLEVEL=[2345]
<SpamapS> Hmm.. ok so if that works..
<SpamapS> maybe have to export RUNLEVEL
<SpamapS> so yeah, I'm confused. if I add 'export RUNLEVEL' to portmap.conf .. and set it explicitly in the pre-start, main script, or post-start .. its still not matching 'start on started portmap RUNLEVEL=x'
<SpamapS> even when I just do export FOO and use that.. no dice. I guess I'm not understanding how export works. :-/
<dewey_> could someone help me with an ruby + upstart problem
<dewey_> my exec doesn't work, the rb file it executes can't find a required file
<dewey_> I've changed the PATH with the current gems folder
<dewey_> guys I'm using start program = "su - user -c 'path'"
<dewey_> but I'm getting a Error: Could not execute su
<Keybuk> is su in your $PATH ?
<dewey_> changed it to /bin/su and now it's working
<Keybuk> interesting, have you set $PATH in your kernel command-line or job environment?
<Keybuk> or is there a different su earlier in your $PATH ?
<Keybuk> e.g. a /usr/local/su
<dewey_> Keybuk: I'm a newb, this is my PATH
<dewey_> .. /home/sysadmin/local/bin:/home/sysadmin/.rvm/gems/ruby-1.9.2-p0/bin:/home/sysadmin/.rvm/gems/ruby-1.9.2-p0@global/bin:/home/sysadmin/.rvm/rubies/ruby-1.9.2-p0/bin:/home/sysadmin/.rvm/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<dewey_> maybe it's because of RVM? I haven't changed anything but the settings for rvm in my .bashrc
<Keybuk> yeah, it's entirely possible you have an extra su in your path there then
<Keybuk> so just use exec /bin/su
<Keybuk> :p
<dewey_> ;p
<SpamapS> I heard a rumor that there is a mailing list at upstart.at .. but I couldn't find a link to it there.. help?
<Keybuk> http://upstart.at/mailman/listinfo/upstart-devel
<Keybuk> though I haven't really formally suggested anyone move off upstart-devel@lists.ubuntu.com yet
<Keybuk> trying to decide
<Keybuk> ww
#upstart 2010-12-24
<rgl> hi
<rgl> for some odd reason, service rsyslog status reports rsyslog start/running, process 24518  ... but service rsyslog stop stalls (but rsyslog is indeed stopped) ... known how to troubleshoot this?
<rgl> I'm using ubuntu 10.04
#upstart 2011-12-19
<stringoO> Hi, I've never written an upstart script before - I need to write a script to start an app every time the system boots. I'm on ubuntu 10.10
#upstart 2011-12-20
<joern> stringoO: basically take a look at /etc/init/*.conf and roughly follow the existing scripts
<joern> it really isn't that hard unless you get fancy
<joern> speaking of fancy: upstart seems to have the edge-triggered vs. level-triggered problem
<joern> with a script that has "start on (started foo and started bar)", the results are somewhat non-obvious and non-useful
<joern> for initial startup, everything works just fine
<joern> but if you stop foo, then start foo again, only one of the dependencies is met
<joern> the service will remain stopped, waiting for bar to be restarted
<joern> is there a good reason to be edge-triggered that i am missing - other than "noone sent a patch yet"?
<stringoO> joern: thanks so much for the help. I'm getting an error with my script - https://gist.github.com/73a0c15bb64028ca6906 - any ideas? 
<stringoO> it works fine when I run it as user stringo0
<stringoO> but if I do service murmur start I get this error:
<stringoO> start: Rejected send message, 1 matched rules; type="method_call", sender=":1.4"
<stringoO> the full thing is in the comments for the gist
<JanC> you can't start system init jobs as a normal user... (uid=1000)
#upstart 2011-12-21
<cptmorgan> im using rhel6 and trying to configure an individual tty... can someone help me out? 
<cptmorgan> all i want to do is add the options --noclear --long-hostname to tty1
<happynoff> Hi there. I'm using debian and I want to know if it is possible to switch to upstart on my system without breaking everything. thanks :)
<fennec> is there a way to get an upstart job to load environment variables from a file (in this case, /etc/environment)?
<fennec> suppose I should just run it as a script and source that file?
#upstart 2011-12-22
<TimTim> would someone good with upstart be so kind as to tell me why this upstart script doesn't work? loads redis but not node... here's a pastebin of 4 things i've tried: http://pastebin.com/N0rss4ky
#upstart 2012-12-17
<xnox> jodh: can you please make https://code.launchpad.net/~jamesodhunt/+recipe/upstart-daily-nonvirt recipe be owned by canonical-foundations such that more of us can re-trigger it. 
<xnox> And can you please re-trigger it? with latest stgraber's fix it should finally build & pass =)
<jodh> xnox: done
<xnox> jodh: \o/
<xnox> stgraber:  jodh: deja-dup "case" for user-on-boot https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/deja-dup/raring/view/head:/monitor/README
<toabctl> xnox, why don't you merge the libnih-gtk-doc stuff into lp:libnih ? 
<xnox> toabctl: because noone can merge into lp:libnih =) we are locked out of it.
<xnox> toabctl: I will fix it up & merge it into lp:~canonical-foundations/libnih/nih & into ubuntu package
<toabctl> xnox, because scott is still the maintainer?
<xnox> toabctl: yes.
<toabctl> xnox, ok
<toabctl> xnox, you wote a mail to scott already to fix the situation?
<xnox> toabctl: but lp:~canonical-foundations/libnih/nih is what /foundations/ are proposing to become lp:libnih.
<toabctl> so lp:libnih is obsolete?
<xnox> toabctl: yes, we did. The solution was to move the devel focus to a new branch which has /new/ stuff which is the libnih/nih branch.
<xnox> toabctl: so soon it will move.
<toabctl> ok. thanks for the info
<xnox> toabctl: in a way the scott's branch is obsolete, because it is missing at least 3-4 important fixes that are present in libnih/nih branch and lp:ubuntu/libnih.
<ajohnstone> I'm failing to understand why upstart doesn't seem work work correctly with the following... I never see 'echo "" >> /tmp/xxxxxxxx' write a file am I missing something..
<xnox> ajohnstone: can you paste a full job file?
<xnox> stgraber: jodh: here be dragons http://paste.ubuntu.com/1445637/
<jodh> xnox: shiny! :)
<stgraber> xnox: nice! I guess --session is a bit redundant though :)
<xnox> stgraber: /me can patch in "if (session || user_mode)" :P
<stgraber> yeah, that's probably the right thing to do for now, we certainly don't want --user to try to bind the system bus
<ajohnstone> xnox: Think I figured it out, "pre-start script" was not executing with "exec"
<xnox> stgraber: jodh: fill in upstart sprint summary for day 1 in http://pad.ubuntu.com/j5DPzIp5KP
<jodh> xnox: thanks - updated.
<wakko> hi
<wakko> when udevtrigger is done, is it normal to receive only *-*-changed events and no *-*-added events ?
<wakko> ok i got it
<wakko> it's not like the man says, at least with my version of udev, i need to "udevadm trigger --action=add" instead of "udevadm trigger"
<slangasek> xnox: so, has anyone talked to Scott since these merge proposals have been raised, to find out if he still considers himself upstream or wants to hand it over?
<slangasek> wakko: hmm, the manpage may leave it ambiguous, but the 'udevtrigger' job in Ubuntu also calls 'udevadm trigger --action=add'
<wakko> slangasek: my job was based on an old ubuntu
<slangasek> ok
<slangasek> I would certainly recommend starting from a recent ubuntu :)
<wakko> 10.04 fyi
<wakko> sure :)
<stgraber> slangasek: currently the idea is to do a full review of the changes we are carrying, land all of that in an alternative branch with proper tests, then ask Scott to either pull from that (if he wants to remain the upstream) or set this new branch as the upstream trunk (if he doesn't want to remain the upstream)
<slangasek> ok
<slangasek> stgraber: btw, lp:~stgraber/upstart/upstart-shell-paths - why would the same test yield a shell on the ppa builders, but not on the distro builders?
<slangasek> i.e., won't this cause a regression now on the distro builds, where we were *not* able to see this PWD=/ ?
<stgraber> slangasek: it's not a distro vs ppa, it's an archive vs daily kind of problem
<stgraber> slangasek: the daily packages are native packages, so when unpacked it creates a directory containing the full version string, including the ~
<stgraber> slangasek: and the presence of the ~ in the command, makes upstart call a shell
<slangasek> oh, haha
<slangasek> got it
<slangasek> well caught :)
<stgraber> yeah, took a bit to figure it out ;)
#upstart 2012-12-18
<afournier1> hi
<afournier1> i am trying to compile upstart 1.6.1 but configure fails on json : "Requested 'json >= 0.10' but version of json is 0.9" the problem is i cannot find json 0.10 on json-c website http://oss.metaparadigm.com/json-c/
<afournier1> what did i miss ?
<afournier1> it got tagged 0.10 on github and they did not release the tarball :/
<afournier1> (it's not a tag it's a branch)
<xnox> afournier1: use $ pull-lp-source json-c 
<xnox> afournier1: or you can download a tarball from http://archive.ubuntu.com/ubuntu/pool/main/j/json-c/
<afournier1>  the thing is that i am not on ubuntu
<xnox> http://archive.ubuntu.com/ubuntu/pool/main/j/json-c/json-c_0.10.orig.tar.gz
<afournier1> yes i found that one
<xnox> jodh: where is json-c upstream? ^^^^
<afournier1> i'll check the difference between http://oss.metaparadigm.com/json-c/json-c-0.9.tar.gz and http://archive.ubuntu.com/ubuntu/pool/main/j/json-c/json-c_0.10.orig.tar.gz but that's weird json-c maintener on ubuntu bump json-c version like this
<jodh> afournier1:  https://github.com/json-c/json-c/tags
<afournier1> ok
<afournier1> i did not see that one
<afournier1> thanks jodh
<jodh> afournier1: they've hidden it rather too well ;-)
<afournier1> 7 months ago... and still no tar.gz :/ weird
<jodh> afournier1: check their mailing list - I asked about it, but they apparently no longer provide releases in the old location.
<xnox> afournier1: well github offers to "download" tags/revisions/etc: https://github.com/json-c/json-c/archive/json-c-0.10-20120530.tar.gz
<xnox> is "auto-generated" tarball by github.
<afournier1> that's not openembedded-friendly :)
<xnox> afournier1: why not? =) it's a tarball & available over https.....
<afournier1> because of the timestamp
<afournier1> but it's ok no big deal
<afournier1> oops
<afournier1> and it unpacks as json-c-json-c-0.10-20120530 :)
 * xnox slowly backs away & hopes afournier1 will enjoy fiddling with it =)
<xnox> afournier1: json-c is needed for stateful re-exec.
<afournier1> you mean i should disable it ?
<xnox> potentially we can make it possible to disable, if you don't care about re-execing init... but currently it's a hard requirement.
<afournier1> it's ok json-c 0.10 compiled already
<afournier1> and it's a good feature btw
<felixge> stop on stopped server and stopped worker
<felixge> ^--- is this supposed to work in upstart?
<felixge> it seems like it doesn't work when my worker job is already stopped and I'm triggering stop on the server
<xnox> jodh: stgraber: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-upstart/5/ARCH=amd64,label=adt/artifact/results/log/*view*/
<afournier1> yay upstart is compiled
<afournier1> btw i add to do this to json-c http://pastebin.com/1EfrZGR0
<afournier1> i had*
<jodh> stgraber: sorry - can't hear you - mumble breaking up for me.
<xnox>   * debian/patches/missing-headers.patch: Install json_object_iterator.h
<xnox>     header, needed by json.h.
<xnox> afournier1: we do as well =)
<stgraber> jodh: line 8691 is where it's failling when running only test_handler
<afournier1> xnox: nice to hear :)
<afournier1> xnox: now upstart does not complain beacause i don't use an initramfs, that's great
<jodh> stgraber: thanks. now we play "hunt the temporary file" :-)
<jodh> http://paste.ubuntu.com/1447297/
<xnox> jodh:  /j #ubuntu-quality just in case ;-)
<xnox> poked them there now, but no response yet.
<xnox> jodh: i got pm from jibel, he will get me access to a VM later today.
 * xnox already has vpn to the machines.
<felixge> I have 2 jobs that should be stopped after a third job is stopped. Is that doable with upstart?
<felixge> sry, phrased this wrong
<felixge> I have 2 jobs, and I want a 3rd job to stop after the 2 jobs have stopped
<felixge> ^-- this
<felixge> for my 3rd job I'm trying: stop on stopped job1 and stopped job2
<felixge> but this causes stop job1 to hang
<felixge> (when job2 is already stopped)
<xnox> felixge: is that what you really want? don't you want pre-stop script in job3  to execute stop job1; stop job2.
<xnox> meh, gone?
<xnox> jodh: is there a way to trace throught TEST_ALLOC_FAIL such that it would tell me which memory allocation it failed & I didn't handle right =)
<abassett> hey im on ubuntu 12.04. I put a script in /etc/init, but upstart isn't recongnizing it
<xnox> abassett: did you run a check on it? http://upstart.ubuntu.com/cookbook/#initctl-check-config
<abassett> yea i had two problems: syntax error and i was linking to it while i worked on it
<abassett> thanks
<jodh> xnox: no, since the other TEST_* macros aren't aware they're being called from within such a block. You'll have to add in code to print _test_alloc_count, _test_alloc_call, and test_alloc_failed.
<xnox> jodh: thanks.
<xnox> jodh: your code review "uncovered" just a couple problems ;-)
<jodh> xnox: better now than later ;)
<felixge> another attempt: When I have a condition like this: stop on stopped jobA and stopped jobB . Will this only be satisifed if upstart sees both events? Or also if just 1 event fires and the second condition already happens to be true?
<xnox> felixge: http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions
<felixge> can I met emit a "stopping" event?
<felixge> initctl emit stopping someJob ?
<felixge> or is the syntax: initctl emit stopping JOB=someJob ?
<xnox> felixge: http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions
<xnox> felixge: it's best for you to have a pre-stop and stop on either job stopping and check if the other one is stopping or is stopped.
<xnox> felixge: another way to do this is by blocking other jobs from doing stuff, see blocking in the cookbook.
<felixge> xnox: thx
<felixge> I think I finally figured it out
<xnox> good.
<xnox> =)
<felixge> I have a few jobs like this: stop on stopped server and stopped worker
<felixge> and now for both the server and the worker I have a pre-stop check that emits the other "stopped" event if needed
<felixge> pre-stop exec status worker | grep -q "stop/waiting" && initctl emit --no-wait stopped JOB=worker || true
<felixge> seems to work
<xnox> =)))))
<xnox> looks good.
<felixge> well, it's been quite the ride :)
<felixge> including a brief journey through the upstart source : )
<felixge> but that link you send me would have saved me a lot of time
<felixge> I read through the upstart cookbook
<felixge> and it's awesome how complete it is
<felixge> but this was hard to find
<felixge> :)
<felixge> just soo much to read
<felixge> :)
<jodh> xnox/stgraber: Feel free to add more: https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Default_System-Provided_Session_Init_Jobs
#upstart 2012-12-19
<xnox> jodh: stgraber: the test-static branch is a big hack =) #include "conf.c" in the test file ;-)
<stgraber> ;)
<jodh> xnox: very IOCCC... but I like it :)
<xnox> hardly http://www.ioccc.org/2012/blakely/blakely.c =)
<jodh> xnox: I was thinking of this: http://www.ioccc.org/1988/spinellis.c
<xnox> jodh: clearly that's everyone's favourite interpreter.
<jodh> xnox: ;)
<bizhanMona> HI I am using ubuntu 12.04, currently we are using a application logger based on log4j which is a rotating logger. This utility is a very older, I was wondering if there is a newer logger we can use? thx
<JanC> I'm not sure what that has to do with upstart?
<xnox> JanC: yeah, he got a reply in #ubuntu-desktop (which is also offtopic there.....)
#upstart 2012-12-20
<afournier> morning!
<afournier> is there a reason why upstart 1.6.1 installs upstart-socket-bridge.conf but does not install upstart-udev-bridge.conf
<afournier> btw upstart-udev-bridge is not compiled/installed either, could be a udev dependency problem ?
<afournier> that was it, too bad the configure is not more verbose when it cannot find udev
<errordeveloper> hi
<errordeveloper> hava used an infinite task as a place holder for a multi-instance service
<errordeveloper> have 4 conf files svc.conf, svc-instance.conf, svc-stop-task.conf and svc-start-task.conf
<errordeveloper> so start and stop tasks are doing a loop around starting and stoping service instance with PORT being the instance variable
<errordeveloper> all works good and I can `/sbin/stop svc` and `/sbin/start svc`, but `/sbin/restart svc` doesn't affect anything 
<errordeveloper> the stop and start task use `start on stopped svc` and `start on started svc` respectively
<errordeveloper> i'm happy to add svc-restart-task.conf, but don't know what to put in it ...
<xnox> errordeveloper: http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions ?
<errordeveloper> nevermind, I fixed it by using `start on {stopping,starting} svc` in the svc-{start,stop}-task.conf
<errordeveloper> so on restart of an infinite task you don't seem to get stopped->started, but you do get stopping->starting
<errordeveloper> :)
<vekexasia> hello all
<vekexasia> I'm trying to undestand why i can stop/start my instance
<vekexasia> but not restart
<vekexasia> someone that could help me '
<vekexasia> noone?
<xnox> vekexasia: did you read the cookbook about restart? can you please pastebin your job?
<vekexasia> i read it not much about restart section is "for me"
<vekexasia> http://paste.ubuntu.com/1452670/
<vekexasia> upstart start nodejs-instance FOLDERNAME="Example"
<vekexasia> triggers pre-start and post-start
<vekexasia> "stop" triggers pre-stop and post-stop
<vekexasia> "restart" triggers only pre-stop and does not stop the instance at all
<vekexasia> it's not a big deal i cannot restart my instances but i wanted to know if there's something i can do.
<vekexasia> any idea xnox ?
<vekexasia> ping xnox :)
<xnox> vekexasia: change log priority to debug, start/stop your instance and then restart & compare the events / transitions.
<xnox> http://upstart.ubuntu.com/cookbook/#change-the-log-priority
<vekexasia> ok
<xnox> vekexasia: i am not sure if post-stop is suppose to be run or not when doing "restart"
<vekexasia> xnox I thought that too. Problem is instance is not getting stopped :(
<vekexasia> sorry for the dumb question but /var/log/syslog is not reporting anything
<vekexasia> am I looking in the wrong place? 
<xnox> should be correct place.
<vekexasia> nothing is printed in there
<vekexasia> neither with initctl log-priority debug
<xnox> vekexasia: does restart work correctly without respawn?
<vekexasia> well should i get something with start/stop in the log ?
<vekexasia> cause even with start/stop i do not get anything
<xnox> have you check dmesg / daemon.log as well?
<vekexasia> nothing on dmesg
<vekexasia> daemon.log
<vekexasia> does not even exist
<vekexasia> and no,  it does not work even withouth respawn
<vekexasia> xnox ?
<vekexasia> still no luck
#upstart 2013-12-16
<X-warrior> I have this file http://pastebin.com/XvGs8NZp in one server it works, but in another it doesn't.  But if I execute the script part by hand... it works. Ideas on what could be the problem?
#upstart 2013-12-17
<munkeh> Am I allowed to ask about upstart v1.5 considering the topic is v1.11?
<munkeh> also: Hello
<xnox> just ask...
<xnox> support for any upstart is provided
<munkeh> How do you get a job to start when another job has been respawned?
<munkeh> I need to ensure that quagga is only running when unbound is running, and for unbound to respawn on crash.
<munkeh> Currently unbound respawns, but quagga does not start again once unbound has respawned.
<xnox> munkeh: what are the "stop on" conditions of "unbound"? 
<xnox> munkeh: i mean start/stop on conditions of quagga.
<munkeh> quagga.conf:  start on unbound started
<munkeh> quagga.conf:    stop on unbound stopping
<xnox> munkeh: right, i think that would be sufficient. can you try something quite weird:
<munkeh> yes.
<xnox> munkeh: wait those are wrong. "start on started unbound" and "stop on stopping unbound" is the right way around, no? (or was that the syntax in 1.5?)
<xnox> as in the event is "started" and "stopping" with qualifiers of job name "unbound"
<xnox> also you can try:
<xnox> start on started unbound
<xnox> stop on (starting unbound or stopping unbound)
<xnox> such that any running instances of quagga are stopped / killed upon a fresh launch of unbound.
<munkeh> hang on. I've just done a status quagga and it is still running. quagga is an abstact job to start ospfd. ospfd is stopped, but it's start on starting quagga
<munkeh> New meds on my part mean my mind is partially fried.
<munkeh> I'll get back to you/this channel once I have it all clear in my head. Thank you for responding. I apologise for being ill-defined.
<xnox> munkeh: =))) no worries. all is good. I hope you figure it all out.
#upstart 2013-12-18
<mpoole> hey.. i'm trying to use start on socket PROTO=inet PORT=9300
<mpoole> piping to a python script
<mpoole> for some reason... sometimes it works, sometimes it hangs there
<mpoole> any idea how i can debug this?
<mpoole> 12 seconds for a response from a simple write of "moo" to the socket
<mpoole> from the python script
<mpoole> I'm getting these in my upstart log:
<mpoole> raceback (most recent call last):
<mpoole>   File "/usr/bin/cluster_check.py", line 15, in <module>
<mpoole>     conn.send(reply.encode('UTF-8'))
<mpoole> socket.error: [Errno 104] Connection reset by peer
<mpoole> OK if I turn off load to it.. it runs every time in 90ms
<mpoole> so i guess this isn't made for load since sending traffic seems to kill it
<mpoole> https://gist.github.com/reedox/8029394
<mpoole> really wanted to use upstart instead of xinetd :/
#upstart 2013-12-19
<Ascendion> I'm trying to set up a bunch session jobs to run as a user on my system -- I've got the session-init-setup and session-init configs in place and the are working... its starting up all the jobs I have in ~/.config/upstart
<Ascendion> the problem the keep dying run that way (work fine when run from the command line) -- I added a console log directive -- where is it sticking the logs so I can see why the apps failed ??
<Ascendion> skip it -- found a glitch in my script that builds the job configs for all these processes
#upstart 2013-12-21
<[[thufir]]> upstart was recomended for me because I have a cron entry which spawns an infinite, well, many, processes.  I just want one or two minerd processes.  is upstart useful for that?  (the manual seems huge, I'm just doing something simple)
<[[thufir]]> I want to, if a job is not running, start it:  http://upstart.ubuntu.com/cookbook/#if-job-is-not-currently-running    where do I put this configuration file, though?  
#upstart 2013-12-22
<linux_dr> I'm having trouble with vagrant detecting something as ssh before openssh is responding properly... could upstart have something to do with this?
<linux_dr> can someone here point me to an easy way (maybe in the cookbook) to have OpenSSHd come up after everything else in the system is up and running?
<xnox> linux_dr: ssh start up in parallel with pretty much majority of everything (runlevel 2)
<xnox> linux_dr: and it's typically not the right solution.
<xnox> linux_dr: if you want to wait until an instance has reliably booted, look into cloud-init, which installs a few upstart jobs to coordinate an instance initialisation and gives reliable state information once everything is booted.
<xnox> linux_dr: the order in which jobs come up is never guaranteed, and shouldn't be relied upon.
#upstart 2014-12-15
<sexyboy> hey
<sexyboy> is there anything i should know about making an upstart job run during boot?
<sexyboy> because i've wrote a simple script that works when i invoke initctl manually but wont run during boot
#upstart 2014-12-17
<lkthomas> hey guys
<lkthomas> I want to let non-root user to execute start, stop, status on our in house program which is server-port_*
#upstart 2015-12-14
<baaba> hi, trying to set up notifications when a job is respawned by upstart but this is proving to be somewhat challenging
<baaba> in particular if i use a monitor job with "start on stopped" then i don't get successful respawns, and if i use "start on stopping" then i don't get $EXIT_STATUS or $EXIT_SIGNAL
<baaba> er sorry, meant to say "start on stopped RESULT=failed" for the first one
<baaba> although that doesn't seem to make a difference at any rate
<baaba> using upstart 1.12.1 (trusty)
#upstart 2016-12-22
<wdouglass> hi everyone! I'm trying to backport a service from systemd to upstart. It uses systemd's "WatchdogSec" variable, and sd_notify, for reliability. does upstart have a similar feature? Is there any way for upstart to watchdog my services?
<wdouglass> thanks.
<AnrDaemon> wdouglass: No, upstart only monitor services presence, AFAIK.
<wdouglass> ok thank you
#upstart 2017-12-21
<kaylindris> hey all... if i have in foo.conf, "start on starting bar"  does that mean that it's guaranteed that the pre-start section of foo will _complete_ before bar starts at all?
<JanC> kaylindris: http://upstart.ubuntu.com/cookbook/#job-lifecycle
<kaylindris> JanC: thank you!
#upstart 2018-12-19
<acidfu> moo
