#upstart 2007-02-19
<repp> hi, is "complex event configurations" supported in 0.3.5 ?
<repp> i mean: 
<repp> from fhs-filesystem-mounted until fhs-filesystem-unmounted
<repp> and from network-up until network-down
<repp> do i need http://people.ubuntu.com/~scott/complex-event-config.patch ?
<AlexExtreme> repp, use this bazaar branch: https://code.launchpad.net/~keybuk/+branch/upstart/complex-event-config
<repp> AlexExtreme: do you know if there is a complete description of job scripts?
<AlexExtreme> no
<repp> http://upstart.ubuntu.com/wiki/ComplexEventConfig this seems to describe at least the complex event stuff
<repp> i'm integrating this with getting-started
<_ion> The page doesn't describe the final syntax
<_ion> The one used in the complex-event-config implementation might not be 100% final, but it's close. And it's different than the wiki page describes.
<repp> _ion: is there a description of it?
<_ion> I think this describes the current form (but i haven't actually checked)  just substitute 'FOO' to 'on'. https://lists.ubuntu.com/archives/upstart-devel/2006-December/000200.html
<repp> thanks _ion 
<lyam> is where an utility what manages daemons on Edgy?
<_ion> services-admin?
<_ion> (Not really related to upstart, as all services but gettys are still started by the old sysvrc scripts in edgy)
<lyam> does upstart have something like inittab file like in older distros?
<_ion> Depends on what you want to do with said inittab file.
<_ion> The general answer is /etc/event.d
<lyam> when booting Edgy by default, what is runlevel?
<mbiebl> lyam: Read /usr/share/doc/upstart/README.Debian
#upstart 2007-02-20
<_ion> Hm, Keybuk hasn't been here for three days.
<osx5> hello
<osx5> anyone from freenode staff here?
<AStorm> Md?
<osx5> k
<osx5>  Md must be afk
<_ion> How may we help you with upstart?
<osx5> I want a hostname cloak
<osx5> but thanks 
<osx5> is upstart better/
<osx5> ?
<_ion> Well, yes. :-)
<osx5> what makes it better?
<osx5> I use darwin on mac osx
<_ion> See the "How does it differ from launchd?" heading at http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe
<_ion> (Seems like the page's markup is broken)
<osx5> k
<osx5> I'm new to unix
<osx5> and linux
<osx5> will MD ever return?
<_ion> Let me check his wereabouts from my surveillance equipment...
<osx5> lol
<osx5> oh he left
<osx5> wonderful
<osx5> lol
<_ion> Welcome back, Keybuk :-)
<Keybuk> heyhey
<Keybuk> "welcome back" ? :P
<Keybuk> did I go somewhere?
<_ion> For almost 3 days you did. ;-)
<Keybuk> we call that a "weekend" :p
<_ion> Hehe
<Keybuk> "until" is causing me issues
<_ion> Why is that?
<Keybuk> well, how it should behave
<Keybuk> simplest example:
<Keybuk>   foo until bar
<Keybuk> I think it's pretty obvious that the job is running when foo happens, and stops running when bar happens
<Keybuk> however ... if foo happens again after bar has happened, should the job be started again or not?
<_ion> I do think it should.
<Keybuk> I agree, simply on the basis that upstart shouldn't consider anything to be permanent
<Keybuk> e.g. in an upstart system, you should be able to kill all processes, then issue the "startup" event again as a kind of soft reboot
<_ion> Also, '(foo and baz) until bar': IMHO after bar, *both* foo and baz should happen again.
<Keybuk> hang on, getting to that ;p
<Keybuk> so, with the above example, we can implement until simply
<Keybuk> it's just a tree node that is TRUE when the left becomes TRUE, and FALSE when the right becomes TRUE
<Keybuk> no further handling is needed
<Keybuk> so right, more complex example as you said
<Keybuk>   (foo or bar) until baz
<Keybuk> I think that's pretty obvious; either foo or bar must happen for it to be started, baz stops it, and either foo or baz can start it again
<_ion> Yeah, with the 'and' case the implementation definitely becomes more complex.
<Keybuk> right
<Keybuk>   foo until (bar or baz)
<Keybuk> that's still simple
<Keybuk> and makes it more complex
<Keybuk>   (foo and bar) until baz
<Keybuk> now, I think this should behave thus:
<Keybuk>  foo and bar need to happen in any order for the job to be started
<Keybuk>  baz happening stops it
<Keybuk>  after which, both foo and bar need to happen again
<Keybuk> (rather than just one or the other happening)
<_ion> Indeed.
<Keybuk> so that makes the implementation a little more complex
<Keybuk> when the right hand side is set to TRUE, the until node becomes FALSE *and* sets the left hand tree to FALSE
<Keybuk> (ie. all nodes in the left hand tree)
<Keybuk> does that sound sane?
<_ion> Is '(foo until bar) until baz' supported? (I can't think of any use cases for it  wouldn't it be exactly equivalent to 'foo until baz'?)
<Keybuk> we'll get to that in a bit, thinking this one step at a time
<Keybuk>   foo until (bar and baz)
<Keybuk> that's somewhat interesting
<Keybuk> foo starts it, but bar and baz both need to happen to stop it
<Keybuk> once stopped, only foo needs to happen to start it again; but both bar and baz need to happen again to stop it
<Keybuk> so that implies that when the left hand side is set to TRUE, the until node becomes TRUE *and* sets all nodes on the right hand side to FALSE
<_ion> Yes, it seems to me that nodes should be able to recursively set children to FALSE.
<Keybuk> right
<Keybuk> so (foo until bar) until baz
<Keybuk>      until
<Keybuk>   until  baz
<Keybuk> foo  bar
<Keybuk> foo has to happen for the tree to be TRUE
<Keybuk> if either bar or baz happens, the tree becomes FALSE
<_ion> Ah, right.
<Keybuk> in either case, only foo needs to happen again for it to become TRUE again
<Keybuk> so it's exactly equivalent to foo until (bar or baz)
<_ion> So when baz happens, the topmost 'until' asks the child 'until' to set itself as FALSE, which doesn't need to do anything else than ask all its children to set themselves FALSE.
<Keybuk> tight
<Keybuk> right
<_ion> (Thinking like OOP and recursive programming, of course the actual implementation doesn't need to be either object-oriented or recursive.)
<Keybuk> *nods*
<Keybuk> I actually have a non-recursive tree iterator in libnih
<Keybuk> but anyway
<Keybuk> right
<Keybuk> so until is quite simple provided that all operators and operands are simple
<_ion> Yeah, i remember skimming through that change.
<Keybuk> lets introduce a less simple operator/operand
<Keybuk> with JOB
<Keybuk> how do we define that?
<Keybuk> either its TRUE when the job's goal is START and FALSE when the job's goal is STOP
<Keybuk> OR
<Keybuk> its TRUE when the job's state is RUNNING and FALSE otherwise
<Keybuk> OR
<Keybuk> its FALSE when the job's state is WAITING and TRUE otherwise
<Keybuk> <g>
<_ion> :-)
<_ion> Its use cases should probably be listed to find the answer.
<Keybuk> the problem is it was defined over hot thai food
<Keybuk> while we were crying and sweating
<_ion> Hehe
<Keybuk> and before we came up with the idea that "starting" and "stopping" should be blocking events
<_ion> So, *are* there use cases for it that can't be done with the already existing things?
<Keybuk> well...
<Keybuk> obviously you can use until and the job events
<Keybuk>   starting JOB until stopped JOB
<Keybuk>   started JOB until stopping JOB
<Keybuk> with the advantage that those retain the blocking behaviour
<Keybuk> the actual use case for "with" was that you could place complex stanzas in a file that could be shared
<Keybuk> and then just say "do whatever that one says"
<Keybuk> it also happens to provide a "running with another job without blocking it" kind of syntax
<_ion> What are the use cases for that? I.e. what are the jobs that should run 'with' another job without blocking it?
<Keybuk> dunno
<Keybuk> the main use case seems to be putting syntax in another file
<_ion> For example, if there's a dummy job 'networking' with nothing but 'on' stanzas, i think it is good for a job using 'started networking until stopping networking' to block whatever 'networking' blocks.
<Keybuk> a reasonable point
<Keybuk> ok, so let's skip with for now
<Keybuk> and think ahead to temporary events
<Keybuk> "every hour" for example
<Keybuk> every hour and network-up until network-down
<Keybuk> pretty obvious; the "every hour" event triggers once an hour
<Keybuk> and and combines that with the until, so it only gets used if the network is up
<Keybuk> ...
<Keybuk>   every hour until some-event
<Keybuk> that one is a bastard :p
<_ion> Hmm... :-)
<Keybuk> I think some of the problem is the words we're using
<_ion> I can't think of anything else than starting it at every hour and stopping it when some-event happens.
<_ion> Sorry, i mean:
<Keybuk> if "foo until bar and frodo until bilbo" was actually "between foo and bar while between frodo and bilbo", it makes more sense
<Keybuk> so it'd be obvious that "between every hour and some-event" behaves as you describe (which is how it would behave)
<_ion> Start it at 00:00. Nothing changes until 03:12, when some-event happens. Start it at 04:00, until some-event happens again
<Keybuk> right
<Keybuk> English and Logic don't collide adequately
<_ion> Heh
<Keybuk> (the fact that in English, "foo until bar and frodo until bilbo" describes a period where either of the two is active (where logically it's when both are active)
<Keybuk> and "foo until bar or frodo until bilbo" describes a period where only one of the two is active (when logically it's when either are active))
<_ion> Would substituting 'or', 'and', 'until' with |, &, -> respectively be too ugly?
<_ion> The Finnish keymap also has  :-)
<_ion> Although i don't use it for anything else than writing Finnish specifically, it sucks for general use. :-)
<Keybuk> I don't think the punctuation changes anything, as you'd still read it in English
<Keybuk> http://upstart.ubuntu.com/wiki/ComplexEventConfig
<Keybuk> ^ so that's a reworked draft
<_ion> True.
<_ion> Looks nice.
<_ion> keybuk: Have you had time to hack more on replacement-initscripts yet?
<Keybuk> not yet
<Keybuk> well
<Keybuk> have been thinking and experimenting deeply with mounting filesystems
<Keybuk> my original plan had been an instance job fired up each time a drive was mounted
<_ion> That's actually what i wanted to ask about...
<Keybuk> and the job was just to mount that path
<Keybuk> and have a similar one for unmounting
<Keybuk> but that doesn't work in the face of needing to mount /usr/local after /usr
<_ion> Exactly. Have you got a solution yet?
<_ion> An idea, probably filled with race conditions :-) : a file on RAM disk that contains the list of filesystems ready to be mounted. The 'fsck' job could contain 'echo "$DEVICE" | locked-write --append /ramdiskpath/mount; /sbin/initctl emit filesystem-checked -eDEVICE' and the 'mount' job would start on filesystem-checked and contain 'locked-read /ramdiskpath/mount | while read device ... ... for device in $ok_to_mount; do [mount them] '
<_ion> Feel free to punch holes in it. :-)
<_ion> whatever starts on block-device-removed would have to remove the devices from the list while locking it.
<_ion> That's what the mount job should do on successful mount, too.
<AStorm> Keybuk, what about using dependencies to do this? :>
<AStorm> Just add parametrised dependencies (e.g. use of $VALUE in deps)
<Keybuk> I'm vaguely leaning towards just having a "mount -a" job and make sure that fails if at least one filesystem could not be mounted
<_ion> How about ones being fsck'd?
<Keybuk> aye, tricky
<Md> Keybuk: check what suse does, I know that for a long time they have been running fsck/mount on demand triggered by uevents
<Keybuk> Md: good point
<Md> if all else fails, sleep for a while in a loop if the mount point does not exist
<_ion> mountd? :-)
<Keybuk> HAL!
<Keybuk> sometimes I wish I worked for Apple
<Keybuk> then I'd know everything was on the one filesystem
<Keybuk> :p
<_ion> Heh
<Keybuk> SUBSYSTEM=="block", ACTION=="add", KERNEL=="sd*[0-9] |hd*[0-9] ", RUN+="mount.sh"
<_ion> mount.sh does the fscking, too?
<Keybuk> yup
<Keybuk> (not that I had a handy vmware instance of opensuse around or anything ...)
<_ion> And what does it do when there's /usr/local waiting for /usr?
<Keybuk> it just runs mount -a after each fsck
<_ion> I take it udev has a command queue, multiple mount.shs are never started simultaneously?
<Md> no, they are
<_ion> Does mount.sh contain locking then?
<_ion> I probably should just grab the script from somewhere myself. :-)
<Keybuk> _ion: it calls mount -a $DEVNAME
<Keybuk> which is interesting
<Keybuk> it doesn't seem to account for mountpoint not existing at all
#upstart 2007-02-21
<reppel> hi, is job-as-states implemented in 0.3.5 or I'm better using https://launchpad.net/~keybuk/+branch/upstart/complex-event-config ?
<AlexExtreme> jobs-as-states is implemented, yes
<reppel> AlexExtreme: and the 'with' keyword? is it possible in 0.3.5 to use e.g. 'with networking-up' ?
<reppel> (otherwise, how do i use a state?)
<AlexExtreme> nope, with is not implemented
<AlexExtreme> that *will* be part of complex-event-config but it isn't implemented in the branch yet afaik
<reppel> ok, I was looking cfgfile.c and there is no mention of 'with' keyword..
<reppel> thanks
<reppel> AlexExtreme: so how do i specify in a job that it requires the state networking-up ? 'on started networking-up' ?
<AlexExtreme> http://upstart.ubuntu.com/wiki/JobsAsStates
<reppel> thanks
<reppel> is it possible to define a variable in a job description?
<AlexExtreme> no idea
<AlexExtreme> :)
<reppel> i plan to write down some docs once i get this beast working :)
<reppel> ./configure: line 1655: syntax error near unexpected token `1.9'
<reppel> ./configure: line 1655: `AM_INIT_AUTOMAKE(1.9 gnu nostdinc check-news dist-bzip2)'
<reppel> uhm\
<reppel> (i'm using the complex-event-config branch)
<reppel> any idea? i really don't understand the whole autohell stuff...
<reppel> i've just run autoconf into the upstart directory
<reppel> and it created a configure script
<reppel> but it gives this error
<AlexExtreme> you shouldn't run autoconf
<AlexExtreme> wait a sec
<AlexExtreme> read this: https://lists.ubuntu.com/archives/upstart-devel/2007-February/000230.html
<reppel> thanks again AlexExtreme 
<AlexExtreme> once you've done the nihify part of that, run this from the root of the complex-event-config branch:
<AlexExtreme> autoreconf -i
<AlexExtreme> then configure should work right
<reppel> worked
<reppel> nice
<AlexExtreme> reppel, what distro are you using, just out of curiousity?
<reppel> AlexExtreme: i'm cross-compiling upstart from etch to a custom mips one
<AlexExtreme> wow
<reppel> debian etch
<AlexExtreme> cool :)
<reppel> i had to do some small modification to allow cross-compiling on mips
<reppel> SIGSTKFLT is not defined on this platform
<reppel> and SSIZE_MAX is not defined in my toolchain so i defined it to LONG_MAX but i think this is a toolchain issue
<reppel> also SIGUNUSED seems undefined
<reppel> Making all in nih
<reppel> make[2] : Entering directory `/home/ciotta/upstart/libnih/nih'
<reppel> make[2] : *** No rule to make target `../m4/codeset.m4', needed by `Makefile.in'.  Stop.
<reppel> make[2] : Leaving directory `/home/ciotta/upstart/libnih/nih'
<reppel> make[1] : *** [all-recursive]  Error 1
<reppel> ideas?
<AlexExtreme> nope
<AlexExtreme> sorry
<AlexExtreme> you'll have to ask keybuk when he's around
<reppel> i suspect is a problem with nihify
<AlexExtreme> yes
<reppel> You don't know how much i don't like auto-* stuff
<AlexExtreme> I don't like it either
<reppel> there are also other erros
<reppel> AlexExtreme: can you actually compile this branch?
<AlexExtreme> no idea :)
<reppel> I bet on it :)
<reppel> start on stopped mount-kernel-filesystems ok <-- what's the meaning of ok? is it mandatory?
<AlexExtreme> i think that means that it should only run if that is stopped but it exited normally
<AlexExtreme> i.e, if it exited with an error that wouldn't be run
<reppel> Hi Keybuk, i'm trying to compile complex-event-config branch (bzr merged http://www.netsplit.com/bzr/libnih http://bazaar.launchpad.net/~keybuk/upstart/complex-event-config; cd complex-event-config; ../libnih/nihify .; autoreconf -i; ./configure; make) but it stops at "No rule to make target `../m4/codeset.m4'" in libnih/nih, any ideas? i think there might be a problem with links made by nihify)
<Keybuk> which version of autoconf, automake, libtool, gettext, etc. do you have installed?
<Keybuk> make sure they're the same rough versions as noted in HACKING
<reppel> ok
<reppel> I'm going to check, thanks
<reppel> Keybuk: as a side note, i'm cross-compiling upstart for mips, i had to comment out SIGSTKFLT in nih/signal.c since it is not available on mipsel
<Keybuk> reppel: update the libnih tree, there's a patch for that already
<Keybuk> (bzr pull)
<reppel> nice thanks
<reppel> Keybuk: same error :|
<reppel> dpkg -l autoconf automake libtool gettext |awk '/^ii/ {print $3}'
<reppel> 2.61-4
<reppel> 1.10+nogfdl-1
<reppel> 0.16.1-1
<reppel> 1.5.22-4
<Keybuk> did you run autoreconf inside libnih?
<reppel> uhm I only did it in the upstart dir/
<reppel> i'm going to try
<Keybuk> right
<Keybuk> you need to do the libnih one as well I think
<Keybuk> just run autoreconf -i there, and try running "configure" again from upstart
<reppel> ok you also have to run configure in the libnih dir to install libtool and other stuff
<reppel> if you need to update the wiki, here is the sequence i use:
<reppel> bzr branch http://www.netsplit.com/bzr/libnih libnih
<reppel> bzr branch http://bazaar.launchpad.net/~keybuk/upstart/complex-event-config
<reppel> cd libnih/
<reppel> autoreconf -i
<reppel> ./configure
<reppel> cd ../complex-event-config
<reppel> ../libnih/nihify
<reppel> autoreconf -i
<reppel> ./configure
<reppel> make
<Keybuk> is there a wiki page on this?
<Keybuk> (if not, go ahead and add one :p)
<reppel> http://upstart.ubuntu.com/wiki/ContributingCode
<reppel> Ok i'm registering in launchpad so i can make modifications myself
<reppel> *by
<reppel> uhm that page is marked as "immutable"
<Keybuk> do you have a wiki account?
<Keybuk> click Login at the top, fill in the fields and click Create Profile
<reppel> ok thanks :)
<reppel> Keybuk: you think it's better to add instructions to ContributingCode or create a page called CompilingUpstart into CategoryDoc ?
<Keybuk> either works
<Keybuk> CompilingUpstart would be useful and link to it
<reppel> ok
<AlexExtreme> hmm
<Keybuk> ?
<AlexExtreme> is it possible to use CIA (as in http://cia.navi.cx) with Bazaar on launchpad?
<Keybuk> I've no idea
<AlexExtreme> ah well
<Keybuk> their site doesn't mention Launchpad
<AlexExtreme> well, it's not host specific, it's specific to the VCS
<Keybuk> there's a bzr plugin, but that's client-side
<AlexExtreme> hmm
<AlexExtreme> it's client side...
<AlexExtreme> that would be good
<Keybuk> that'd involve me running it
<Keybuk> which would seem to defeat the point, no?
<AlexExtreme> i'm not talking about for upstart
<Keybuk> the plugin runs on commit, not push
<AlexExtreme> i'm considering moving my project's source to bazaar on launchpad
<Keybuk> ah
<reppel> why did ubuntu choose bzr over svn?
<reppel> is it more oriented to the distributed model?
<reppel> like git or arch?
<_ion> I don't really see a reason for anyone to choose svn or any other centralized VCS. :-)
<_ion> Even in a centralized environment, a centralized VCS is a single point of failure.
<Keybuk> reppel: simple; with bzr I can commit on my laptop whenever I like
<Keybuk> on trains, planes, etc.
<Keybuk> and I can choose when I push it to the archive
<reppel> oh nice
<Keybuk> Ubuntu didn't choose bzr anyway :)  we developed it
<reppel> Keybuk: when you started it, there was no other option? (svn,arch,git,mercurial)
<Keybuk> mercurial is a fork of bzr
<Keybuk> at least, they took the original bzr design documents and wrote a separate implementation
<Keybuk> git didn't exist at the time either
<Keybuk> svn is useless, and should die a horrible death
<_ion> darcs is pretty old, isn't it?
<AlexExtreme> svn is horrible
<Keybuk> the only two useful revision control systems were CVS and Arch
<Keybuk> CVS doesn't do distributed, merging or branching
<Keybuk> Arch does, so we hired and funded that -- but found that it was just too much like hard work
<Keybuk> so we forked it and called the fork "Bazaar"
<AlexExtreme> _ion, darcs is great, but the choice of programming language was a bit wrong imo ;) also it's rather slow
<Keybuk> but it soon became apparent that though there were good ideas there, it still wasn't tenable to use
<Keybuk> so we designed from scratch a new one called "Bazaar NG" / "bzr", which has since inherited the "Bazaar" name
<Keybuk> _ion: we'd never heard of darcs at the time
<AlexExtreme> is the old bazaar still in use?
<Keybuk> though I think Martin (who designed bzr) had
<Keybuk> nah, old bazaar is basically dead
<AlexExtreme> ah
<AlexExtreme> ok
<AlexExtreme> frugalware uses darcs for everything
<Keybuk> the reason upstart uses bzr is simply that I like it :)
<Keybuk> I don't really have any major 
<AlexExtreme> and at this moment, I agree that SVN should die a horrible death
<Keybuk> annoyances with bzr, which says a lot
<Keybuk> SVN is no better than CVS
<AlexExtreme> it won't let me add a directory because a file had that name before, it says i need to commit the rename of that file but i already have done
<Keybuk> the only useful thing it adds to CVS is atomic commits, at the cost of a huge amount of headache and maintenance problems -- combined with lethargic slowness
<AlexExtreme> so
<AlexExtreme> i'm switching to bzr
<Keybuk> (actually, that's not true ... I do have a medium annoyance with bzr, which is that some of its commands aren't consistent with each other -- but they do fix those from time to time)
<AlexExtreme> i'm liking bzr already
<phsdv> Hi, I have a question on event arguments. What happens if we have something like "on event1 and event2"? I guess $1 will belong to event1 and $2 to event2. But what happens if only event2 sends an argument with the event, it will be in $1 or in $2?
<Keybuk> currently:
<Keybuk> whichever of the two events comes second
<Keybuk> so if event1 happens, then event2, the job only knows about event2
<Keybuk> UPSTART_EVENT=event2, $n are the arguments to event2 and the environment comes from event2
<Keybuk> that's mostly down to the design of the way that events are transferred into jobs
<Keybuk> the EventEmission is referenced by the job when the goal changes
<Keybuk> the arguments and environment are taken directly from the EventEmission structure
<Keybuk> and when the job reaches a rest state, it unreferences the EventEmission
<Keybuk> this all predates complex-event-config :)
<Keybuk> assuming that we want to fix it so that:
<Keybuk>   on block-device-added and some-other-event
<Keybuk> can still see what block device was added ...
<Keybuk> we need to come up with a solution, which could be anything of:
<Keybuk>  1. permit multiple event emissions on a job, collate them all (what does UPSTART_EVENT contain?)
<Keybuk>     - problem here is that events aren't finished until all jobs unreference them, so the initctl emit block-device-added would block until some-other-event happened
<Keybuk>  2. collate the event information some other way in the job (eww, copying)
<Keybuk> complex-event-config also affects instance jobs in a similar way
<Keybuk> e.g. do you spawn an instance when the *first* event happens in a complex set, or the last? :p
<phsdv> the block-device-added was the example that triggered my question
<Keybuk> (there's a reason the code is in a branch :p)
<phsdv> whould haveing an UPSTART_EVENT1+UPSTART_ARG1,  UPSTART_EVENT2 + UPSTART_ARG2 be an option? 
<Keybuk> the problem is a coding one
<Keybuk> at least, from my pov :p
<Keybuk> though, having just done the washing up, I thought of a possible solution
<Keybuk> 1) start instances from job_handle_event rather than job_change_goal -- so they're started on the first event in a set (though would need to also check them to make sure that if everything goes to FALSE, the instance is deleted)
<Keybuk> 2) each Event operand node has not only an Event * for what it's matching but an EventEmission * for what it's matched
<Keybuk> 3) set that to the emission when matched and set the value to TRUE; set it to NULL when the value is set to FALSE
<Keybuk> 4) add an event refcount to EventEmission, they don't stop it being finished, but just stop it being freed; increment/decrement this when adjusting the Event operand
<Keybuk> 5) iterate the tree and seed the environment with all other emissions than the current one
<phsdv> I have not looked into the implementation details before, but I see where you are going.
<phsdv> you need 4, in the case you have multiple scripts waiting for the same event?
<Keybuk> the reason you need 4 is because of the way event emission works
<Keybuk> take for example "on block-device-added and some-other-event"
<Keybuk> if you just ref'd the eventemission in the normal way, the emission would be blocked until some-other-event occurred
<Keybuk> so the process ("initctl" or just udev directly) that was emitting that event would be blocked
<Keybuk> since it's waiting to hear progress on the event
<Keybuk> if some-other-event never happens, they can be blocked indefinitely
<phsdv> ok, clear. We do not want things to block ;-) and for sure not forever
<Keybuk> of course, the problem with above is that any event participating can never fail :)
<Keybuk> because success would be toggling a flag in the tree
<Keybuk> rather than the associated job reaching its goal rest state
<phsdv> so we are stuck for the moment? No (predictable) arguments with complex events.
<Keybuk> it depends on your definition of "moment" :p
<phsdv> :-)  I am sure you can think of a solution
<Keybuk> yeah, is just one of the problems with that spec
<Keybuk> and why it's still drafting
<phsdv> no problem. That is why I try to write some script, to find unforseen issues. 
<Keybuk> yeah
<Keybuk> it's why I did a trial implementation
<Keybuk> to make sure it just worked, which it doesn't
#upstart 2007-02-22
<fozze> ok, i did a very bad thing
<fozze> i installed the upstart package and then rebooted without modifying my configuration on my vps
<fozze> and now i am screwed
<mbiebl> boot with init=/bin/bash
<mbiebl> And the run /etc/init.d/rcS && /etc/init.d/rc 2
<fozze> unfortunately i can only access the computer remotely
<fozze> however, i found a way to temporarily boot up the computer in another mode that my host provides and it allows me to see what procs are running, and so far the only proc that is running is init
<mbiebl> can you access the computer via serial line?
<fozze> there is a "repair" mode that allows a simple working filesystem to boot up and then my old filesystem is placed in a directory called /repair so I can go in there and manually fix stuff, i just don't know what to edit to get upstart to work
<fozze> so right now, i'm in repair mode
<mbiebl> Which system do you run?
<fozze> ubuntu edgy
<fozze> it was running sysvinit
<fozze> then i did a sudo apt-get install upstart and then rebooted
<mbiebl> Do you have system-services/upstart-compat-sysv/system-tasks installed?
<mbiebl> If not, do that.
<fozze> hmm i don't know..
<fozze> probably not
<fozze> let's check
<fozze> is there a way i could use dpkg to manually install those packages under a /repair folder?
<mbiebl> chroot /repair
<fozze> cool
<mbiebl> btw. s/system-tasks/startup-tasks/ 
<mbiebl> (not that it would matter, because the package doesn't contain any relevant files yet)
<fozze> i see
<fozze> i probably need to use the dpkg under /repair don't i...
<mbiebl> after you have chrooted to /repair, apt-get install upstart-compat-sysv should work.
<fozze> ah, it does :)
<fozze> hmm
<fozze> system-tasks, is that the correct name
<fozze> ?
<mbiebl> btw. s/system-tasks/startup-tasks/ 
<mbiebl> quoting myself ;-)
<fozze> so, after doing all this, it should use my old sysviconfig when i boot up normally?
<fozze> sysvinit config rather
<mbiebl> yeah, it use the sysv init scripts.
<fozze> all right, rebooting...
<fozze> hrmm
<fozze> well i wasn't able to install system-tasks
<fozze> and so it seems like process is right where it was before
<mbiebl> s/system-tasks/startup-tasks/  means, substitute system-tasks with startup-tasks
<mbiebl> I made a typo at the beginning
<mbiebl> Have you checked that upstart-compat-sysv and system-services are installed properly?
<fozze> i'm checking
<fozze> yep, they are there
<mbiebl> why did you have sysvinit at first place?
<mbiebl> edgy ships with upstart by default
<mbiebl> maybe you messed something up.
<fozze> it came like that, that's what i thought
<fozze> my host provider provided some whacked up version of ubuntu edgy
<fozze> actually
<mbiebl> Well, if they don't ship upstart, which is default, they must have a reason.
<fozze> they are using virtuozzo
<fozze> it may only work with sysvinit
<mbiebl> Very likely, upstart does not work with virtuozzo yet.
<mbiebl> Best is, you go back to sysvinit.
* fozze sighs
<fozze> i just wanted my startup scripts to be simpler :)
<mbiebl> Or you feel adventurous and help to debug the problem ;-)
<fozze> lol
<fozze> yes, with all my free time *sarcastic*
<fozze> well thanks for your help?
<fozze> help.
<mbiebl> Please file a bug report at launchpad.net against upstart.
<mbiebl> So this issue can be tracked.
<mbiebl> Describe the hardware/software environment that you use.
<mbiebl> etc.
<mbiebl> https://bugs.launchpad.net/upstart
<fozze> so you think it's a problem with upstart and not virtuozzo?
<fozze> or both?
<mbiebl> Hard to tell.
<mbiebl> At least file the bug report so this discussion is not lost.
<fozze> ok, well going back to sysvinit works...
<fozze> ok, bug filed
<Keybuk> heyhi
<_ion> Hi
<Keybuk> how goes it?
<_ion> Well, i'm alive. :-)
<_ion> How are you?
<Keybuk> just back from the gym
<Keybuk> been thinking about complex-event-config
<Keybuk> and ironically, have decided it's not as simple as I though
<Keybuk> +t
<_ion> Are you thinking of redesigning it?
<Keybuk> I mean in the way that it interacts
<Keybuk> in particular with event emissions and instance jobs
<Keybuk> take the simple example
<Keybuk> on block-device-added and some-other-event
<Keybuk> there's actually four or more things you might want that to mean
<Keybuk> 1) whichever event causes the goal change (the second one to occur) is blocked until the job finishes, and is the one the job sees in its arguments and environment
<Keybuk> 2) you want a specific event (e.g. the first) to be blocked and appear in the arguments; this might need some syntax ..."on using block-device-added and some-other-event"
<_ion> True...
<Keybuk> 3) you want a combination of all of the events to be blocked and appear in the arguments (but how would you get the arguments?)
<Keybuk> I can't remember the 4th thing
<_ion> on block-device-added as foo and some-other-event as bar  args: $foo_1, $foo_2, ..., env vars: $foo_DEVNAME, $bar_BAZ
<_ion> on using block-device-added and some-other-event as bar  block-device-added: $1, $2, ..., $DEVNAME; some-other-event: $bar_1, $bar_2, ..., $bar_BAZ
<Keybuk> would you block those events/
<Keybuk> if so, what happens if block-device-added happens but some-other-event never happens ... the event would never be finished
<_ion> I haven't thought of it yet.
<_ion> Perhaps a syntax such as 'on block-device-added [block, using]  and some-other-event [as bar] '
<Keybuk> gets tricky, doesn't it :-/
<_ion> Indeed. :-)
<Keybuk> not surprising really, since the model so far is assumed simple
#upstart 2007-02-23
<__keybuk> complex-event-config is complex :-/
<AlexExtreme> :/
<__keybuk> for example:
<__keybuk> on starting apache until stopped apache and starting dbus until stopped dbus
<__keybuk> do we stop apache from starting until dbus is starting? :p
<AlexExtreme> hmmm
<AlexExtreme> good point
<AlexExtreme> that would be the only way to do it
<AlexExtreme> as far as I can see
<AlexExtreme> because otherwise if you let one of them start, it wouldn't satisfy the starting part
<__keybuk> so if dbus never starts, neither would apache?
<AlexExtreme> yes
<AlexExtreme> but that's a bit stupid
<AlexExtreme> because it introduces an unnecessary dependency on dbus for apache
<__keybuk> indeed
<AStorm> Proper way would be to rewrite it into:
<AStorm> on starting apache and starting dbus
<AStorm> stop on stopped apache and stopped dbus
<AStorm> s/stopped/stopping/
<AlexExtreme> no
<AlexExtreme> that's one of the points of complex-event-config, to have until :)
<AStorm> until is the same :P
<__keybuk> no it's not
<__keybuk> until pairs the events, where that doesn't
<AStorm> "pairs"
<AStorm> Explain what you mean by that :-)
<__keybuk> on foo until bar or frodo until bilbo
<__keybuk> foo happens. frodo happens
<__keybuk> both are TRUE
<__keybuk> bar happens, that only cancels the foo
<__keybuk> the right side is still true, so the job is still running
<__keybuk> on (foo or bar) until (frodo or bilbo)
<__keybuk> (or start on (foo or bar) ... stop on (frodo or bilbo))
<AStorm> Shouldn't and do the same with "stop on x stopped and y stopped"?
<__keybuk> foo or bar happens, job is running
<__keybuk> err,
<AStorm> Or is that one-shot?
<__keybuk> foo or frodo happens, job is running
<__keybuk> bar happens, job would be stopped whichever of the two happened
<__keybuk> using a real example:
<AStorm> The "and" would group the events, but disregard ordering?
<__keybuk> on started gdm until stopping gdm and started kdm until stopping kdm
<__keybuk> gdm starts and kdm starts, job is running
<__keybuk> now let's say kdm stops, the job stops again because kdm is no longer running
<__keybuk> so far, that *is* equivalent to just using and
<__keybuk> except say kdm starts again
<AStorm> Ah, so it's like I thought.
<AStorm> "and" is one-shot.
<__keybuk> I don't understand "one-shot"
<AStorm> That means, the flag is read only once, because it isn't linked with the starting event.
<__keybuk> flag?
<AStorm> So, when stopped fires, the next started doesn't reset it.
<__keybuk> I still don't follow, sorry
<__keybuk> could you use an example to illustrate?
<AStorm> on x started and y started
<AStorm> stop on x stopping and y stopping
<AStorm> This would mean:
<AStorm> I start x and y
<AStorm> then stop y
<AStorm> then start y again
<AStorm> then stop x, the job is stopped.
<__keybuk> right
<AStorm> While with "until" that wouldn't happen.
<__keybuk> no, that'd happen with until too
<AStorm> Hmm.
<__keybuk> the point about "until" vs. "and" is that if you stop y then stop x, then start x again -- the job would be running if "and" is used, but not running if "until" is used
<__keybuk> compare:
<__keybuk> x started = FALSE, y started = FALSE
<__keybuk> x stopping = FALSE, y stopping = FALSE
<__keybuk> start x, x started = TRUE
<AStorm> Aha, now I get it.
<__keybuk> start y, y started = TRUE
<__keybuk> so the and is TRUE, so the job starts
<__keybuk> stop y, y stopping = TRUE
<__keybuk> the and is FALSE, so the job stops
<AStorm> Because the "x started" has already been set.
<AStorm> Yes.
<__keybuk> stop x, x stopping = TRUE
<__keybuk> the and is still FALSE, so the job is still stopped
<__keybuk> start x, x started = TRUE
<__keybuk> nothing has "reset" the y started = TRUE, so the and is still TRUE, so the job starts again
<__keybuk> the point about "until" is that it is a reset
<AStorm> While until  resets the condition when the last one happens. So both would have to be started again, if both have been stopped.
<__keybuk> when the expression on the right side becomes TRUE, it explicitly resets the values on the left to FALSE
<__keybuk> right
<__keybuk> that's why we invented the complex thing
<__keybuk> we'd originally tried to just do it with adding and/or to start on/stop on
<AStorm> Hmm...
<AStorm> How would one do then failover services, which would be something like:
<AStorm> -start when any of foo, bar started
<AStorm> -stop when both of foo, bar stopped
<AStorm> (stopped means not running, not "stopped" event)
<__keybuk> err?
<__keybuk> that's what the stopped event means
<AStorm> You know, when you stop task, it sends that stopped event.
<AlexExtreme> AStorm, that's what the state machine is for
<AlexExtreme> it will be in the stopped state
<AStorm> But it won't send one, when it hasn't ever been ran.
<AStorm> Aha, great.
<AlexExtreme> at least
<AlexExtreme> I think so :)
<__keybuk> that's true, you don't have an event if it's never been run at least once
<AlexExtreme> hmm
<__keybuk> we had "with" for that
<__keybuk> on not (with foo or with bar)
<AlexExtreme> so if it hasn't been run then using stopped won't do anything?
<__keybuk> AlexExtreme: if you don't run a job, you don't get events for it ;p
<__keybuk> there's no "stopped foo" event just because it exists
<AStorm> It won't fire, if you mean that.
<AlexExtreme> true :p
<AlexExtreme> so you can't use 'on' based on something's state?
<AStorm> "on" won't reset.
<AlexExtreme> or whatever ;)
<__keybuk> AlexExtreme: dunno yet, "on" is still being defined
<AStorm> with would work best.
<AlexExtreme> k
<AStorm> What would happen then, if:
<AStorm> on not (with foo or with bar)
<AStorm> foo gets started
<AStorm> bar gets started
<AStorm> foo gets stopped?
<AStorm> Still running or not?
<__keybuk> with bar is true, so the on is false
<__keybuk> so not running
<AStorm> Hmm, not what I would like to :>
<__keybuk> use "and" then
<__keybuk> on not (with foo and with bar)
<AStorm> I figured that out...
<__keybuk> now running when either foo or bar or both are not running
<AStorm> But then, both foo and bar have  to be started?
<AStorm> Ah, either? Really?
<__keybuk> yes, not ... and
<AStorm> This "and" is nonintuitive :D
<__keybuk> err, why?
<__keybuk> it's boolean
<AStorm> Actually... yep, it's alright.
<AStorm> We invert it, so we get a "nand"
<__keybuk> with doesn't combine well with until though
<__keybuk> which is why I haven't coded it yet
<__keybuk> and also acts strangelty
<AStorm> :|
<AStorm> What would: on (with foo or with bar) mean?
<AStorm> Either one of them, but stop if any of them is stopped?
<AStorm> Or stop if both are stopped?
<__keybuk> running when either one of them is running
<__keybuk> stopped only if both are stopped
<AStorm> with counts as stopped if it isn't running, right?
<__keybuk> right
<__keybuk> I'm increasingly thinking that complex-event-config is wrong
<__keybuk> it's cute, but doesn't fit in with existing behaviours
<AStorm> with sounds like a "need" dependency
<AStorm> almost exactly.
<__keybuk> what are the different deps?
<AStorm> Ok: use and need
<AStorm> There are 2 special orderings: before and after
<AStorm> (which map directly to "on")
<AStorm> Well, before doesn't actually.
<AStorm> It works like a "pre-start", but isn't tightly bound to the job.
<AStorm> after x == on x started
<AStorm> need x == with x
<AStorm> use x is special. Like a conditional after.
<AStorm> Wrong. Like a conditional need.
<__keybuk> use only applies if the job exists?
<__keybuk> whereas need always applies, so if the job doesn't exist, it isn't started?
<AStorm> Yes, if it's "added" to the "runlevel"
<AStorm> Doesn't map directly to events.
<AStorm> __keybuk, yes.
<AStorm> Or, when it's started, it pulls these as dependencies
<AStorm> So, it would be like: foo has "need bar"
<AStorm> if foo is started, bar is pulled in
<AStorm> if foo is stopped, bar is removed (or not, in case of Gentoo init - but that's a misfeature)
<AStorm> (should be removed when nothing else "needs" it)
<AStorm> when bar is stopped, foo is stopped too.
<AStorm> It probably is possible to emulate using events alone, but isn't easy.
<__keybuk> how about with states?
<__keybuk> could you define them using states?
<AStorm> Hmm. there would be 4 conditions:
<AStorm> foo is started -> bar is started
<AStorm> foo is stopped -> nothing needs bar -> bar is stopped
<AStorm> foo is stopped -> something needs bar -> nop
<AStorm> foo is started -> bar is started -> bar is stopped -> everything needing bar is stopped
<AStorm> (including foo)
<AStorm> This would be hard to implement nicely with autoresurrecting services.
<AStorm> It would mean, when bar is restarted, restart everything needing it
<__keybuk> that works with the events at the moment
<__keybuk> since a job that's respawned emits stopping, starting, started
<AStorm> Yes.
<AStorm> But the hardest part is "something needs bar -> nop"
<__keybuk> why would it nop?
<AStorm> Because something else besides foo requires it.
<AStorm> so in this case, stopping foo shouldn't stop bar
<AStorm> while when only foo needs bar, bar should be stopped
<AStorm> Would require another event, let's say "lastneed"
<AStorm> or rather "noneed"
<AStorm> A simplel integer counter :P
<AStorm> bar noneed would be fired if it reaches zero
<AStorm> decreased when something needing bar is stopped
<AStorm> increased when something needing bar is started
<AStorm> Usually it's implemented using a stack and not events.
<AStorm> s/stack/array/
<AlexExtreme> __keybuk, in the replacement-initscripts branch, what is getmntent for?
<__keybuk> AlexExtreme: parsing /etc/fstab and /etc/mtab properly
<__keybuk> and not using grep or $IFS
<__keybuk> which are both broken if you want spaces in your mount points :p
<AlexExtreme> ah
<AlexExtreme> k :)
<AlexExtreme> gonna hack them a bit
<__keybuk> wing-commander scott% sudo getmntent -f /dev/hda1
<__keybuk> UUID=68210f07-2d06-416e-9db5-15db2b3e6b70 / ext3 defaults,errors=remount-ro 0 1
<__keybuk> "where should /dev/hda1 be mounted?" ... note UUID lookup
<__keybuk> wing-commander scott% sudo getmntent -md /
<__keybuk> /dev/hda1 / ext3 rw,errors=remount-ro 0 0
<__keybuk> "what's mounted on /"
<__keybuk> etc.
<AlexExtreme> k
<AlexExtreme> thanks
<_ion> You can also get the value of a specific field.
<__keybuk> I also intend to add an option to output FOO=... fields for use with udev
<__keybuk> so you could do SUBSYSTEM=="block", ACTION=="add", IMPORT{program}="/sbin/getmntent -f %k"
<__keybuk> then ENV{FSTAB_DIR}=="?*", RUN+="/sbin/initctl emit fstab-device-added %k"
<__keybuk> etc.
<AlexExtreme> yes
<__keybuk> and then, more usefully
<__keybuk> SUBSYSTEM=="block", ACTION=="remove", ENV{FSTAB_DIR}=="?*", RUN+="/sbin/initctl emit fstab-device-removed %k"
<__keybuk> :p
<__keybuk> since you can't do a UUID lookup on a removed device
<_ion> Neat.
* __keybuk is wondering whether "until" is unnecessary
<__keybuk>   start on starting foo
<__keybuk>   stop on stopped foo
<__keybuk> is equivalent to
<__keybuk>   on starting foo until stopped foo
<AlexExtreme> hmm
<AlexExtreme> all it does then is shortens things?
<__keybuk> complicates things
<__keybuk> thinking about whether it's better to make states a first-class thing, rather than something that can be defined with until
<__keybuk> so
<__keybuk> I tend to believe that if something is difficult to explain, or if something behaves in strange ways, then there's a problem with that something
<__keybuk> on/until is proving difficult to explain and behaving in strange ways
<__keybuk> which is starkly different from start on/stop on which behave simply
<__keybuk> vague thought
<__keybuk> start on EVENTEXPR
<__keybuk> stop on EVENTEXPR
<__keybuk> EVENTEXPR := EVENT | EVENT 'and' EVENT | EVENT 'or' EVENT | 'not' EVENTEXPR
<AlexExtreme> hmm
<__keybuk> that's not that difficult
<__keybuk> start on foo or bar
<__keybuk> stop on foo and bar
<AlexExtreme> that looks easy enough
<__keybuk> then add
<__keybuk> when STATEEXPR
<__keybuk> STATEEXPR := STATE | STATE 'and' STATE | STATE 'or' STATE | 'not' STATEEXPR
<__keybuk> where a STATE is just the name of a job
<AlexExtreme> followed by an actual state such as started or stopped?
<__keybuk> no just the name of a job
<__keybuk> so just use job files instead of until
<__keybuk> not sure that solves the issue though
<AlexExtreme> hmm
<AlexExtreme> so STATE would be true if it is started?
<AlexExtreme> and false if stopped?
<__keybuk> right
<AlexExtreme> ok
<_ion> That syntax doesn't look bad.
<AlexExtreme> yeah
<__keybuk> for the networking and filesystem case, you'd need:
<__keybuk> an /etc/event.d/networking file containing
<__keybuk>   start on network-up
<__keybuk>   stop on network-down
<__keybuk> an /etc/event.d/filesystem file containing
<__keybuk>   start on filesystem-mounted
<__keybuk>   stop on filesystem-unmounted
<__keybuk> and then any file would have
<__keybuk>   when networking and filesystem
<AlexExtreme> yes
<__keybuk> doesn't solve all of the problems though, I don't think
<AStorm> __keybuk, for the fsck, in order to get the device ID, use udevinfo --name=<partition> --query=env | grep ID_PATH
<AlexExtreme> <AlexExtreme> __keybuk, in the replacement-initscripts branch, what is getmntent for?
<AlexExtreme> <__keybuk> AlexExtreme: parsing /etc/fstab and /etc/mtab properly
<AlexExtreme> <__keybuk> and not using grep or $IFS
<AlexExtreme> <__keybuk> which are both broken if you want spaces in your mount points :p
<AlexExtreme> note the grep part ;)
<__keybuk> AStorm: udev is not a database :P
<AStorm> __keybuk, udev knows the device ID.
<AStorm> getmntent doesn't know which device you're scanning :P
<AStorm> So, you would mount many things from one device at once. (unless watershed is powerful enough to avoid that)
<AStorm> /dev/sda1 and /dev/mapper/wtf may be on the same device.
<AStorm> Udev knows about these, so does sysfs
<AlexExtreme> as far as I can tell getmntent also knows about that
<AStorm> Not the device part.
<AlexExtreme> it uses libvolume_id from udev
<AStorm> So it doesn't tell you the data. :>
<AStorm> try it on some DM or RAID volume.
<AStorm> udevinfo also doesn't tell everything :/
<AStorm> ls-ing /sys/block/.../slaves tells more
<AStorm> or ls-ing /sys/block/.../holders instead
<AStorm> But how to resolve /dev/mapper/wtf to dm-0?
<AStorm> Blah@me
<AStorm> dmsetup table...
<AStorm> (but that requires cut use)
<__keybuk> AStorm: devmap_name
<__keybuk> (on Ubuntu)
<AStorm>        Invoking the command as devmap_name is equivalent to
<AStorm>        dmsetup info -c --noheadings -j major -m minor.
<AStorm> Blah, I'd have to know the minor and major number
<__keybuk> that's easy
<__keybuk> $MAJOR and $MINOR in the uevent
<phsdv> Hi, I made an upstart script to fsck all file systems on a certrain blockdevice. It checks /etc/fstab with getmntent for filesystem on this block device
<phsdv> you can find the script here: http://upstart.pauldevries.homelinux.com/wp-content/uploads/fs-check.txt
* AlexExtreme looks
<phsdv> It does not check the root partition, that will be dealt with seperately
<AlexExtreme> yess
<AlexExtreme> *yes
<AlexExtreme> emit fs-checked $partition << shouldn't that be 'initctl emit fs-checked $partition' ?
<phsdv> yes, I made a link
<AlexExtreme> ab
<AlexExtreme> *ah
<AlexExtreme> ok
<phsdv> In this way you only have one fsck per block device at a time.
<phsdv> and you can have multiple block devices checked in paralel
<phsdv> it probably does not handle yet names with spaces in there. But adding some "" should help out there
<phsdv> the script to fsck the rout partiton you can find here: http://upstart.pauldevries.homelinux.com/wp-content/uploads/fs-check-root.txt
<phsdv> I still need to get rid of the sleep statement though :(
<AlexExtreme> ok
<phsdv> If I do not wait, I get errors...
<AlexExtreme> i'll look at it later, i need to go now :)
<phsdv> ok
<_ion> It doesn't take LVM, RAID etc. into account.
<_ion> Or fsck returning a non-zero value.
<phsdv> no, not yet
<phsdv> but I do not have experience with LVM and RAID
#upstart 2007-02-25
<AlexExtreme> hey Keybuk, i'm having a few problems with my set of jobs I'm writing :/
<Keybuk> oh, what's up?
<AlexExtreme> i've got the mount-kernel-filesystems job which runs on startup, that runs ok
<AlexExtreme> then there are jobs with 'start on stopped mount-kernel-filesystems ok'
<AlexExtreme> none of those are run
<Keybuk> sounds like mount-kernel-filesystems is failing
<Keybuk> did you try --debug?
<AlexExtreme> doh, there's a debug option
<AlexExtreme> it also doesn't work if I omit the ok part
<Keybuk> definitely sounds like it's failing
<AlexExtreme> hmm
<Keybuk> (need to get that information into "initctl jobs" somehow)
<Keybuk> it shows up in initctl events
<AlexExtreme> it seems to be hanging.... the last command in the mount-kernel-filesystems script is an echo which I put there for debugging, upstart gives no debug output after that
<Keybuk> doubt it's hanging
<AlexExtreme> so it handles the starting event, and it's now in the started state
<AlexExtreme> nothing happens after that
<Keybuk> I usually have jobs like "exec openvt -c 2 initctl jobs" and "exec openvt -c 3 initctl events"
<Keybuk> run on startup
<Keybuk> they're handy for debugging as well
<AlexExtreme> http://frugalware.org/paste/886 << that's the job, can you see any problems with it?
<Keybuk> not offhand
<Keybuk> oh
<Keybuk> sorry
<Keybuk> it *doesn't* work if you omit "ok"
<Keybuk> that's interesting
<AlexExtreme> yeah
<Keybuk> grep for mount-kernel-filesystems in other jobs
<AlexExtreme> http://frugalware.org/paste/887
<Keybuk> hmm
<Keybuk> nothing blocking there
<Keybuk> what does init do with --debug?
<AlexExtreme> hold on, i'll take a screenshot
<AlexExtreme> http://www.alex-smith.me.uk/files/upstartdebug.png
<Keybuk> interesting
<AlexExtreme> the "End of kernel fses" is an echo at the end of the job
<AlexExtreme> last command in the job, should exit ok
<Keybuk> it doesn't look like it's reaped the child
<Keybuk> this is in vmware?
<Keybuk> oh, qemu
<Keybuk> ok
<Keybuk> add a shell
<Keybuk> start on startup
<Keybuk> exec openvt -c 2 bash
<Keybuk> -- 
<AlexExtreme> k, hold on
<Keybuk> then change m-k-f to be started when that's started (start on started shell)
<Keybuk> you should then be able to Alt+F2 and see what's up
<Keybuk> also would be useful:  init=/usr/bin/strace init
<AlexExtreme> that's weird...
<AlexExtreme> it won't start the shell
<AlexExtreme> i think it's because i'm booting qemu with -kernel, -append, etc without using a real bootloader inside it
<AlexExtreme> i'll try a real install, give me a few mins
<Keybuk> that shouldn't matter?
<AlexExtreme> no, it messes with the consoles i think, because openvt fails
<Keybuk> odd
<Keybuk> (at least you're not trying to run it in openvz :p)
<AlexExtreme> :)
<Keybuk> still not sure what *that* bug is
<Keybuk> I strongly suspect openvz doesn't give init pid #1 :p
<AlexExtreme> hmm
<AlexExtreme> does openvt require the device node for the vt you're trying to open, by any chance?
<Keybuk> oh, could do
<Keybuk> heh
<AlexExtreme> udev hasn't run yet ;)
<Keybuk> I always debug this stuff with an initramfs that takes care of that kind of thing
<AlexExtreme> ah, well
<AlexExtreme> frugalware has no initramfs (yet)
<AlexExtreme> we're gonna add support for initramfs soon though
<Keybuk> can you try the strace thing?
<AlexExtreme> i'm about to
<AlexExtreme> it doesn't like that because init isn't pid 1
<Keybuk> oh, meh
<Keybuk> I so need to add something for that ;p
<AlexExtreme> :)
<AlexExtreme> brb, need to get some food
<AlexExtreme> back
<Keybuk> ;)
<AlexExtreme> now
* AlexExtreme tries to figure out what's wrong
<AlexExtreme> to me it seems that it's a bug in upstart
<Keybuk> something's not right, certainly
<Keybuk> what kernel?
<AlexExtreme> 2.6.20.1
<Keybuk> it looks like it's not getting SIGCHLD
<Keybuk> or getting stuck there
<Keybuk> run bash with console owner on startup
<AlexExtreme> k
<AlexExtreme> got a shell
<AlexExtreme> weirsd
<AlexExtreme> *weird
<AlexExtreme> initctl list says mount-kernel-filesystems is waiting and in the stop stare
<AlexExtreme> *state
<AlexExtreme> damn keyboard
<Keybuk> odd
<Keybuk> --debug shows nothing?
<AlexExtreme> debug doesn't say anything about stopping
<Keybuk> hmm
<Keybuk> you're always going to mount a fresh /dev over the top there, aren't you
<Keybuk> is there a /dev/console FILE by any chance? :p
<Keybuk> if so ... cat it
<AlexExtreme> no console
<Keybuk> that's your problem, anyhoo
<AlexExtreme> it's there on the actual filesystem but not on the ramdisk
<Keybuk> no /dev/console, no /dev/null
<Keybuk> can't start jobs in that state
<AlexExtreme> ack
<AlexExtreme> i'll have mount-kernel-filesystems create it then
<Keybuk> if you look at my example mount-kernel-filesystems job, I make sure to copy those devices into the ramdisk from /lib/udev/devices
<AlexExtreme> yeah
<AlexExtreme> but there's no null or console in that dir for some reason ;)
<Keybuk> you don't copy them in at all
<Keybuk> http://upstart.ubuntu.com/wiki/ComplexEventConfig/UseCases
<AlexExtreme> hmm
<AlexExtreme> quick question: the scripts are run with -e... how would i stop it from terminating the script if a command gives an error?
<Keybuk> || true
<Keybuk> on each command that you want to ignore the error for
<AlexExtreme> k
<Keybuk> (or ||: )
<Keybuk> I tend to dislike that because it looks like Perl
<AlexExtreme> yeah
<Keybuk> :; is just as bad
<AlexExtreme> yay
<AlexExtreme> i've converted the whole of frugalware's rcS.d to upstart jobs
<AlexExtreme> pretty simple ones though, i haven't done anything about responding to udev events yet
<Keybuk> how are you handling mounting the filesystem?
<AlexExtreme> it's just a straight conversion of the SysV scripts atm
<Keybuk> ah right
<_ion> Throwing random ideas around, episode 59:
<_ion> start on filesystem-checked
<_ion> emits filesystem-mounted
<_ion> block script
<_ion>     prereq_mountpoints=...
<_ion>     for m in $prereq_mountpoints; do
<_ion>         echo "wait filesystem-mounted MOUNTPOINT=${m}";
<_ion>     done
<_ion> end script
<_ion> The block script is run whenever the job is being started. If it prints any 'wait' lines, the job only goes to 'starting' when all corresponding events have been received.
<_ion> Race conditions are avoided (or are they?) by not processing new events until the currently running block script has finished (thus the writer of job must be careful with what she does inside a block script)
<Keybuk> that's quite similar to something iwj and I discussed a while back
<Keybuk> let me see if I can dig it out
<Keybuk> its possible its on my old laptop
<Keybuk> http://www.chiark.greenend.org.uk/~ijackson/d/upstart.text
<Keybuk> (it's somewhat insance, since ian wrote it, but the core is the idea that upstart implements a turing complete programming language which jobs can use to respond to events in a race-free manner -- since the program is run before the next event, rather than alongside)
<_ion> Interesting.
<_ion> But determining the prerequisite mountpoints based on the current MOUNTPOINT env var surely needs shell scripting or running external processes some other way. Using that syntax, how would one achieve that?
<Keybuk> that's what I thought
<Keybuk> it was a lot of complexity for no visible gain
<AlexExtreme> nice
<AlexExtreme> http://frugalware.org/~alex/bootchart-upstart.png
<AlexExtreme> compared to this from sysvinit: http://frugalware.org/~alex/bootchart-sysvinit.png
<_ion> Looks like the connection to frugalware.org is going to timeout.
<AlexExtreme> strange
<AlexExtreme> works here
<_ion> traceroute reaches taurus.int.elte.hu (157.181.141.18). After it it's all * * *s.
<AlexExtreme> hold on, let me drop it on my server
<AlexExtreme> http://www.alex-smith.me.uk/files/bootcharts/
<_ion> Now the pictures loaded.
<pkt> AlexExtreme: yes but it seems that with sysinit you were running more services, correct?
<_ion> But if i reload, it's "connecting..." again for ages.
<AlexExtreme> yes, i know, it's not completely accurate
<Keybuk> 18s is nice
<pkt> also, are you running SMP?
<AlexExtreme> pkt, no, this was in a vmware VM, it was only using 1 core
<pkt> That is nice :-)
<pkt> I guess the worst thing in startup time is the shell scripts (especially when they do extensive fs ops)
<AlexExtreme> yes
<Keybuk> that's what einit tries to address
<pkt> with very carefully tuned sysvinit + scripts I could do ~25s in a 386sx/25 (2.6.8 stripped down)
<pkt> Of course some current subsystems take more time to initialize :-(
<AlexExtreme> now i need to try and work out what the hell is wrong with my fsck script, it seems to interfere with the sysv compat stuff. if fsck gets run, it tries to run runlevel 4 and runlevel 0 at the same time
<_ion> Would converting dash to a library and linking to it instead of execing shells help at all?
<_ion> (with upstart, that is)
<AlexExtreme> probably
<AlexExtreme> but that wouldn't work for distros without dash
<pkt> _ion I think redhat does something close to that with their shell
<pkt> they have something that includes several typically external programs as libraries 
<pkt> but is not usable as a shell (i.e., not interactive)
<pkt> Of course, this caused both positive and negative feelings to many :-)
<Keybuk> isn't that just busybox?
<pkt> Keybuk: no, it is (was?) a redhat-specific shell-like thing that included e.g., functionality for setting up LVM/RAID etc
<pkt> but I 'm forgetting its name ...
<Keybuk> ok
<Keybuk> what einit does it has C modules that handle the common things like setting hostname, checking and mounting filesystems, activating swap, etc.
<Keybuk> in practice, these things aren't that configurable (it's not like a shell script, which you can just edit)
<Keybuk> and everything is configured from one large einit.xml
<_ion> The initialization of dash doesn't take long, so the answer to my question is probably "no".
<_ion> dash -c ''  0.00s user 0.00s system 0% cpu 0.009 total
<pkt> yep the xml part sucks
<pkt> _ion, I don 't think that dash per se is the problem
<pkt> usually the problem is like an "abstraction penalty" for using unix utilities for stuff that would only take a few lines of C code
<_ion> (Side note: "perse" in Finnish means an arse.)
<pkt> oops :-)
<pkt> but I did leave a blank
<Keybuk> ie. forking then execing grep, which loads localisation libraries and parses a file linewise matching against regular expression objects ... instead of using strstr()
<pkt> exactly (and I could think of even worse stuff when amateur admins are involved :-)
<Keybuk> e.g. /etc/event.d/hostname
<Keybuk> the shell version looks something like:
<Keybuk>  - stat /etc/hostname
<Keybuk>  - fork/exec cat: fopen/stat /etc/hostname, read, write to stdout, close, capture stdout into variable
<Keybuk>  - compare variable against empty string
<Keybuk>  - fork/exec hostname: capture stdout
<Keybuk>  - compare variable against empty string
<Keybuk>  - set variable to localhost
<Keybuk>  - fork/exec hostname, set hostname
<Keybuk> in C, that might be:
<Keybuk>  - gethostname()
<Keybuk>  - fopen(/etc/hostname)
<Keybuk>  - if opened: fgets
<Keybuk>  - else if still unset: strcpy
<Keybuk>  - sethostname()
<Keybuk> 4 syscalls instead of ~100
<_ion> Yeah
<pkt> Keybuk: the only problem is that you can only provide "embedded" functionality in the "shell" for very simple stuff (those that cannot be configured in a gazillion different ways)
<Keybuk> pkt: I don't follow?
<pkt> E.g., redhat that provides the LVM functionality in their "shell" actually provides a "stripped-down" version
<Keybuk> ah
<Keybuk> I see
<pkt> Otherwise you get a *huge* "shell/interpreter" which is again a loss
<pkt> It is, as always, a tradeoff :-)
<Keybuk> flexibility vs. speed
<pkt> Actually "speed for a special case" or "robust speed"
<Keybuk> a while ago, a friend and I wondered whether it'd be possible to write a scripting language based around syscalls
<pkt> that is roughly what I thought as well, that sort of a "DSL" for booting would provide the largest benefit/cost ratio
<Keybuk> DSL?
<_ion> Domain-specific language IIRC
<pkt> Domain-Specific Language, yep
<Keybuk> right
<pkt> but I view upstart as being an important step towards this direction
<Keybuk> right now we have <action> exec and <action> script, we can always add <action> foo later :p
<Keybuk> pre-start perl ...
<Keybuk> end perl
<Keybuk> :p
<AlexExtreme> ugh :p
<_ion> Haha
<pkt> :)
<pkt> I think the important think in upstart is to think really hard about the interactions of the base system components (especially for desktops)
<pkt> This is no trivial problem (which is why I have seen no perfect "job" set or job language yet)
<pkt> Once this is sorted out more or less it will be much easier to take the "extra step"
<Keybuk> robust first, speed later
<pkt> Plus it may be proven that the extra speed doesn 't really matter after all
<pkt> But the really hard stuff (at least for me) is to figure out how to support as many common use-cases as possible with as few "artificial waits" as possible
<pkt> And do that in a world where stuff (from all levels of the stack) come and go all the time
<pkt> (think e.g., ATA over Ethernet over WLAN :-)
<Keybuk> indeed
<pkt> plus the fact that e.g., a developer will want to also start/stop stuff on demand
<pkt> and the fact that some unix beasts (like shells) are a bit "special" on how you need to handle them 
<pkt> Or they loose their settings :-)
<pkt> s/settings/history
<Keybuk> heh
<pkt> yep, *every single pitfall* of sysvinit, I 've hit it ;-)
<AlexExtreme> :)
<AlexExtreme> random thought: sysvinit scripts provide a start and a stop. with upstart, to do the stop part you'd have to create a seperate job, no? (at least, for things that aren't daemons, like saving mixer settings. daemons would get SIGTERM)
<Keybuk> you can do it either way
<Keybuk> could you have a mixer-settings job that restored them in pre-start and saved them in post-stop
<Keybuk> then you could "start mixer-settings" and "stop mixer-settings" :p
<Keybuk> or you could have two separate jobs that do it in script
<Keybuk> it depends what makes more sense really
<Keybuk> you could do that for everything
<Keybuk> ie. have a hostname job that sets the hostname in pre-start but does nothing in post-stop
<Keybuk> (or even unsets it)
<Keybuk> then the "hostname" job would be running all the time the hostname was set
<Keybuk> and you could stop hostname to unset it
<Keybuk> and restart the job to reset it
<AlexExtreme> but
<Keybuk> but that makes somewhat less sense than just having a set-hostname task
<AlexExtreme> if you did it with pre-start and post-stop
<AlexExtreme> wouldn't it not work because you need an exec/script/respawn/whatever ?
<Keybuk> no
<Keybuk> those are optional
<AlexExtreme> hmm
<Keybuk> you can have process-less jobs now
<Keybuk> it was supposed to work in 0.3.5, but I broke it just before release
<Keybuk> it works in trunk
<AlexExtreme> but if they were missing and you did start mixer-settings, wouldn't it run the pre-start script, then jump straight to stopping and run post-stop?
<Keybuk> no, sticks in running
<AlexExtreme> ah
<AlexExtreme> ok
<Keybuk> http://upstart.ubuntu.com/wiki/JobsAsStates
<AlexExtreme> ah
<AlexExtreme> I see
<Keybuk> I tend to think in terms of what a sysadmin would rather do
<Keybuk> what makes more sense
<AlexExtreme> :)
<Keybuk> stop the mixer job to save them and mute the card
<AlexExtreme> sounds logical
<Keybuk> (and thus restart the mixer to save the settings)
<Keybuk> or run the save-mixer-settings job to save them
<Keybuk> I can't decide whether we need lots of small options for job control "start on", "stop on", "when", "from", "foo", etc.
<Keybuk> or just one big option
<AlexExtreme> IMO one big option would be too complex, i personally like it with small options
<AlexExtreme> btw, what is the problem with logd?
<Keybuk> kill it, any job with it as stdout ends up dying mysteriously and silently
<AlexExtreme> ah :/
<Keybuk> so interestingly:
<Keybuk> some jobs can be defined by what starts or stops them
<Keybuk> but others it's easier to define by when they should be running
<AlexExtreme> hmm
<AlexExtreme> ACTION=="add", SUBSYSTEM=="block", KERNEL=="*[!0-9] ", RUN="/sbin/initctl emit block-device-added %k"
<AlexExtreme> is that rule ok for a block device added?
<AlexExtreme> or should I add -eDEVNAME=%k too?
<elpaso> hello
<elpaso> is there anybody out there?
#upstart 2008-02-18
<sadmac> Keybuk: hallo
#upstart 2008-02-19
<jeiks> hi
<jeiks> i'm from brazil
<jeiks> we are working at prolinux
<jeiks> based on debian and ubuntu
<jeiks> i liked a lot the upstart propuses
<jeiks> we are thinking about put it in our system
<jeiks> who is there?
<jeiks> rs
#upstart 2008-02-20
<Keybuk> argh
<Keybuk> the hardest point of installing a new computer
<Keybuk> picking a name for it
<ion_> :-)
<ion_> I pick names from Pan Sonicâs discography.
<Keybuk> mine are computer games
<Keybuk> the trouble is, it's a very large selection of names to choose from
<Keybuk> grand-theft-auto is too long :-(
<ion_> alku, vaihe, luotain, aines, hapatus, tela (translation: beginning, phase, probe, substance, sour, platen). Nice, short names. :-)
<ion_> gta? :-)
<Keybuk> hmm
<Keybuk> start service FOO=bar
<Keybuk> pretty obvious that FOO=bar in pre-start, post-start and main
<Keybuk> stop service FOO=baz
<Keybuk> does FOO=bar or FOO=baz in pre-stop and post-stop? :)
<Keybuk> ...I think it should override
<Keybuk> start apache SITE=netsplit.com DEBUG=no
<Keybuk> stop --id 1234 DEBUG=yes
<Keybuk> if the environment is coming from events, rather than manual, it will match anyway
 * Keybuk thinks further
<Keybuk> start apache SITE=netsplit.com DEBUG=no
<Keybuk> (job #1234)
<Keybuk> stop --id 1234
<Keybuk> start --id 1234 DEBUG=yes
<Keybuk> stop --id 1234
<Keybuk> start --id 1234
<Keybuk> what should the value of $DEBUG be?
<Keybuk> that's pretty obvious when I write it
<Keybuk> it shouldn't depend on the timing between the commands
#upstart 2008-02-21
 * Keybuk bashes his head against a wall
<ion_> Wonât anyone please think of the walls!
 * Keybuk is going around in circles
<ion_> :-\
#upstart 2008-02-22
<keesj> Hi
<Keybuk> hey
<keesj> I am playing with upstart. I am trying to implement a state machine for my system
<keesj> I wonder if it makes sence :). the big idea would be to emit events from userland or the kernel and handle upon them in upstart
<keesj> I have a 3 gui apps that will run (not at the same time)
<keesj> I would like to be able to emit "high" level events "start_mass-storage-app" and translate that into  a few command (insmods perhaps) and starting a gui
<keesj> can I emit such event from within a job
<keesj> simply saying.. can I emit events from withing a jobs 
<Keybuk> sure
<keesj> by calling initctl ? 
<Keybuk> right
<keesj> there is no "emit" command"
<Keybuk> there is
<Keybuk> initctl emit
<keesj> thanks
<keesj> I installed upstart in a different directory... I need to prefix the initctl command :(
<Keybuk> you can make an "emit" command by just symlinking to initctl :p
<Keybuk> right
<Keybuk> fixing that is on the TODO
<keesj> that's nice
<keesj> and would there be a way to store the current states so I can ask it again later? 
<Keybuk> how do you mean?
<keesj> just like runlevels work ( that you can ask the current runlevel)
<Keybuk> still not 100% following
<keesj> I would like to keep some variable to implement my state
<keesj> if (in_mass_storage) and usb unplugged -> rmmod ...
<keesj> in_mass_storage would be a state
<keesj> in the sample scripts "they" do         set $(runlevel --set 1 || true)
<keesj> to determine if an event gets handled based on the previous runlevel (this is sample code named rc1)
<Keybuk> right, I'm kinda trying to get to that point
<Keybuk> where upstart has states that are true or false
<keesj> you are one of the developers, cool
<Keybuk> heh, the upstart developer
<keesj> yo!
<keesj> I am currently testing by using a qemu (I first tried a chroot ) but the apparently was not the best way to do things
<Keybuk> I just have it installed by default
<Keybuk> it replaces sysvinit well enough
<Keybuk> you can carry on running the old init scripts while playing/developing
<keesj> I am playing with it for mamona so it is an embedded platform (under arm)
<keesj> do you happen to know this package? http://smc.sourceforge.net/ (state machine compiler)
<Keybuk> I don't, no
<keesj> I used it a lot to create state machines. but basicaly you need "previous_state" + event to implement this 
<Keybuk> right
<Keybuk> depends what you want to do, really
<keesj> the "quick" hack would be to misues the initctl to tell init to change it's own "environement"
<keesj> thanks for your time btw (I really apreaciate it)
<Keybuk> right, but I'm not sure I fully understand what you want to achieve
<keesj> hmm . perhaps I am just thinking the wrong way around. let me try to give a simple example
<keesj> my system can have twoo states "video playback" and "mass storage". 
<keesj> if somebody presses the power button while in mass storage I don't like that so I would like to ignore a "power" event when in storage mode. 
<keesj> I was thinking in the line of creating a "button" event handler that listend to power_on power_off event
<keesj> other events would be something like usb_connected (being a good reason to switch to mass storage)
<keesj> I think I am taling about level events
<Keybuk> what other kinds of decision would you make based on these states though/
<keesj> whell I have a few of those event flying in (usb state changes, button presses, system update event) I was also thinking of using this state when going in "suspend" mode
<keesj> so that when I wakeup I know what program to start again
<Keybuk> when suspending why do you need to stop programs?
<keesj> good questions :p
<keesj> currenty I had to do it because I don't get events when in suspend , so if the device is in video mode , I suspend , and plug it to a computer , I miss the "connected" event
<keesj> (just like udev meesd to cache the events generated by the kernel , I guess this is not the scop of upstart :p
<keesj> I am getting there !
<Keybuk> not entirely sure yet what the scope of upstart is ;)
<keesj> haha
<keesj> the code looks very clean
<keesj> are you at fosdem?
<Keybuk> no
<Keybuk> I've never been to one of those
<Keybuk> http://upstart.ubuntu.com/wiki/RemoveEventArguments
<keesj> I can be nice :op
<Keybuk> Any objection?  no?  good!  :o)
<keesj> haha
<keesj> it
<keesj> I really just should al be programmed in lua
<Keybuk> why?
<keesj> I see plenty discussion about creating, "combined events" or other other structs that would be possible if upstart used a scripting language for the events definitions
<keesj> but the current aproach is also pretty clean i guess
<keesj> >>from (tty-added or cua-added) and foo<< does that get interpreted every time an event would come?
<Keybuk> the string? no
<Keybuk> it's compiled into a match tree in memory
<keesj> hmm that you can not replace by lua :)
<Keybuk> what would lua gain though?
<keesj> in this case nothing. but just like the current script  command you could script the behaviour (if an event is consummed by an handler)
<keesj> my system looks a little like the stoplight (the left image) http://smc.sourceforge.net/Images/SmcEx4_Stoplight.png I get the same type of events (like a timeout ). I see very whell how to perform the "start,turn light etc" . 
<keesj> you get the same "message" but want to perform something different(if you want me to stop just say so  , I am really trying to find a awy to do it)
<keesj> I have put the different events in an event_handler that performs the few functions  
<keesj> so I can not emit "switch_from_a_to_b"
<Keybuk> hmm
<Keybuk> currently Upstart's event matching is more functional than procedural
<Keybuk> ie. you describe the state in which the job is running
<Keybuk> inside the job itself, you have a shell script, so it's procedural
<keesj> Yes , I Have the feeling I really am missing the point :p
<Keybuk> I'm not sure I've got the point ;)
<keesj> AM I trying to misue the system?
<keesj> missue
<Keybuk> I'm not quite sure what you're trying to do yet
<keesj> in a perfect work I would like to say "emit go_into_mass_storage" where ever you come from
<Keybuk> you wouldn't use an event like that
<Keybuk> I'd define mass_storage as a state/job
<Keybuk> so "start mass_storage"
<keesj> yes I have this part http://paste-it.net/6595
<keesj> so do I need to create a userland progress saying "emit stop_mass_storage" "emit start_video"
<keesj> with just the start/stop the system looks like /etc/init.d/mass_storage [start|stop]
<keesj> or would start mass_storage stop video?
<keesj> the backwards compatible scripts use wmtp to "know" what the current runlevel is
<keesj> I am getting there ... /initctl list
<keesj> shows a list of active tasks, I can only have one state active at the time.....
<Keybuk> so you'd make your states start and stop each other?
<Keybuk> or be started and stopped by the same events
<keesj> I will listen for event use the initctl to know the current state and react as supposed
<keesj> I currently implemented it a separate jobs that are triggered by events (the switching between states) 
<keesj> So I guess the second option
<keesj> perhaps I might even use the list to do sanity checks
<keesj> I will try to hack a version and try to post it to the list
<Keybuk> shiny
<keesj> I hope it wil work. (that there are no race cases...) 
<keesj> it requires a state to keep running apparently a jobs that is started and exits is in a "stop" state again
<Keybuk> (gdb) p *((EventOperator *)job->start_on->node->left)
<Keybuk> $5 = {node = {parent = 0x662720, left = 0x0, right = 0x0}, type = EVENT_MATCH, 
<Keybuk>   value = 0, name = 0x662670 "wibble=foo bar", env = 0x0, event = 0x0, 
<Keybuk>   blocked = 0}
<Keybuk> (gdb) p *((EventOperator *)job->start_on->node->right)
<Keybuk> $6 = {node = {parent = 0x662720, left = 0x0, right = 0x0}, type = EVENT_MATCH, 
<Keybuk>   value = 0, name = 0x6628a0 "wobble=foo bar", env = 0x0, event = 0x0, 
<Keybuk>   blocked = 0}
<Keybuk> (tangent:
<Keybuk>  damn I was on good form when I wrote this, I predicted I'd need something a year down the line)
<Keybuk> that was from
<Keybuk> "wibble=foo bar" or wobble="foo bar"
<Keybuk> so it handles quoting sensibly
<keesj> can I get the event name inside my scripts?
<keesj> UPSTART_EVENT...
<Keybuk> right
<Keybuk> $UPSTART_EVENTS in trunk
<keesj> week-end here. thanks a lot for the help!
<Keybuk> enjoy
<keesj> thanks
#upstart 2008-02-24
<sadmac> Keybuk: ping
<Keybuk> sadmac: pong
<sadmac> Keybuk: I was wanting to ask about your current thoughts for the profiles system
<Keybuk> sadmac: sure
<sadmac> Keybuk: What does your design for it look lik?
<Keybuk> I don't have one
<sadmac> s/lik/\0e/
<Keybuk> AlexExtreme has been doing one, iirc
<Keybuk> the idea being to define profiles in a file
<Keybuk> that look something like
<Keybuk>   disable apache
<Keybuk>   disable squid
<Keybuk> or
<Keybuk>   disable *
<Keybuk>   enable foo
<Keybuk>   enable bar
<sadmac> hmm
<sadmac> I had another idea for it
<sadmac> my idea was to add a stanza to the job definitions, one of either "disable unless" or "disable if"
<sadmac> followed by a series of flag names.
<sadmac> we could then load a list of set flags off the filesystem at boot time.
<sadmac> that does get kind of messy if you have flags with large effects, like single user mode.
<Keybuk> yeah, that's more in line with the "flags" idea
<Keybuk> flags and profiles are two competing ideas for the same functionality
<Keybuk> profiles implies that profile is a first-class object which includes or excludes jobs
<Keybuk> and maybe that you only have one profile active at one time
<Keybuk> flags is that jobs disable/enable themselves in their own configuration depending on which flags are set
<Keybuk> with the implication that multiple flags can be set at one time
<Keybuk> the profiles idea is better for a sysadmin, since they don't need to edit the job definitions
<Keybuk> flags is vaguely better for a distro
<sadmac> Keybuk: with enough flags built into the jobs they become logically equivalent
<Keybuk> that's somewhat true
<Keybuk> one of the other inits has a feature whereby kernel arguments turn on/off jobs
<sadmac> thats easy to do. Doesn't even have to be done in code.
<sadmac> an early job definition that takes a peak at /proc could do it.
<Torne> does upstart work if it's not PID 1?
<Torne> as the child of another init?
<Keybuk> no
<Torne> aw. how come? :)
<Keybuk> you can run it as another pid by disabling a couple of its features
<Keybuk> (supervision of forking daemons, mostly)
<Torne> nothing i run forks anyway :)
<Torne> is that compile time?
<Keybuk> why do you want to run it under another init?
<Torne> i'm switching distribution
<Keybuk> it's "edit the source and recompile" time
<Keybuk> basically comment out the getpid() check
<Torne> ah, right. i'll experiment in a bit then
<Torne> thanks. was just wondering if there was an easier way
<Keybuk> not really
<Keybuk> it's not something I want to support
<Keybuk> since people will complain when things don't work because they're not init
<Torne> hm. if it's just a matter of turnign a few thigns off and disabling the check, surely that's a reasonable compile time option
<Torne> and anyone who builds one with that on will presumably know what they're getting
<Keybuk> adding an option means supporting it ;)
<Keybuk> "blah doesn't work when not pid 1" ... "so run as pid 1" ... "but there's an option to not run as pid 1"
<Torne> i think you're overestimating the chance of that happening, but hey :)
<Keybuk> perhaps
<Torne> thanks anyway. i'll fiddle with it.
#upstart 2009-02-16
<sadmac> Keybuk: around?
<iamthelostboy> hello :)  is it possible to start an x application from upstart?
<iamthelostboy> im trying to do an `exec xinit <application>`, when `xinit <application>` works from the command line, though not from upstart
<iamthelostboy> the job starts another application prior to the exec command, which isnt preceeded with exec, just not the x command..
<sadmac> iamthelostboy: what's the error?
<iamthelostboy> doesnt seem to be anything..
<sadmac> check your system logs
<iamthelostboy> im just trying to start it on the command line... start <job>
<iamthelostboy> doesnt seem to be much happening in syslog..
<iamthelostboy> just a job main process killed by TERM signal.. from when I stop the job, i assume
<sadmac> hmm
<sadmac> what about in your xorg logs?
<iamthelostboy> its not getting written..
<sadmac> hmm
<iamthelostboy> x doesnt appear to be starting at all
<iamthelostboy> should that command work ?
<sadmac> after you do start foojob what does initctl list say?
<iamthelostboy> do i have the direct the console in some way ?
<sadmac> X gets its own console
<iamthelostboy> sorry.. how do i use initctl? im still a little new at some of this stuff
<sadmac> initctl list
<iamthelostboy> that particular job is running with a pid..
<sadmac> but no X session?
<iamthelostboy> in ps -A the pid is shown as sh, with the following pid as the first executable in the job
<sadmac> which is?
<iamthelostboy> our own executable
<sadmac> ok, so apparently that's hanging :)
<iamthelostboy> well.. its running
<iamthelostboy> the second executable relies on it
<sadmac> I'll need to see your job definition
<iamthelostboy> and i can run the second outside the job
<iamthelostboy> its not too big, so ill just type it here...
<iamthelostboy> start on aksusbd 5
<iamthelostboy> stop on runlevel [!5]
<iamthelostboy> respawn
<iamthelostboy> script
<iamthelostboy> `/dir/app1
<iamthelostboy> exec /usr/bin/xinit /dir/app2
<iamthelostboy> end script
<iamthelostboy> without the ` on app1
<sadmac> comment out app1, and put twm in for app2. see if you get a twm session
<iamthelostboy> something happened then.. but im not sure what..
<iamthelostboy> ill check what was going on...
<iamthelostboy> yeah.. i can get a simple x app started without app1
<iamthelostboy> but i still see nothing about x in initctl
<sadmac> probably because it forks off.
<iamthelostboy> so my job is getting stopped at app1, right? how do i make is run the first app, leave it running, and continue onto the second..
<iamthelostboy> i thought it was going to run anything it could, and then pretty much wait at the exec
<sadmac> iamthelostboy: its a bash script
<sadmac> iamthelostboy: it runs the bash script and monitors the bash script as a service
<iamthelostboy> so.. if the 2 apps weren't in the script tags it would run differently
<sadmac> iamthelostboy: you exec so that your service replaces the bash script and steals its pid and parentage
<sadmac> iamthelostboy: no, the job wouldn't work.
<iamthelostboy> oh
<iamthelostboy> i read somewhere that if i background an app in a job, upstart will see the job as complete and exit?
<sadmac> no...
<iamthelostboy> or could i simply run app1 & -- xinit app2
<sadmac> not if there's further scripting
<sadmac> yeah. that'd do it
<iamthelostboy> of course, now that i have seen it working...
<iamthelostboy> when i stop the job, only app2 ends, which makes sense now..
<sadmac> yep
<iamthelostboy> but isnt really right
<sadmac> put in another job
<sadmac> and give it start on starting app1job
<iamthelostboy> yeah.. i think ill have to
<iamthelostboy> do i have to put anything special into the app1 job file to emit the event?
<sadmac> if you want a special event then yes. starting app1 is emitted automatically
<iamthelostboy> thanks :) will try it out
<sadmac2> Keybuk: ping
<Keybuk> hey
<sadmac2> Keybuk: remember when we talked about objects with no parents being "parented to NULL"?
<Keybuk> vaguely
<Keybuk> that's the way things work
<sadmac2> Keybuk: ok, so suppose we actually maintained a child list for NULL, and nih_free(NULL) freed all of NULL's children
<sadmac2> Keybuk: and suppose we ditched nih_local and made nih_unref behave like nih_unref_only
<sadmac2> Keybuk: and suppose we called nih_free(NULL) at the end of nih_main_loop_iter
<sadmac2> Keybuk: see where I'm going?
<Keybuk> err, wouldn't that make things die in a great big fire
<Keybuk> you have to have some top-level objects
<Keybuk> you'd free them every main loop iteration
<Keybuk> and you make nih_local depend on the main loop
<Keybuk> whereas now, it's actually limited to the C context, which is better
<sadmac2> nih_local would just go away
<Keybuk> and this is a good thing, because?
<sadmac2> completely, utterly impossible to have forget-to-free errors
<sadmac2> we've written 9/10 of an automatic garbage collector. why not finish it?
<Keybuk> well, ignoring the fact you're over-freeing everything
<sadmac2> fixable...
<Keybuk> I don't see that it buys anything?
<Keybuk> things like initctl don't necessarily have a main loop
<Keybuk> so nothing would be freed
<Keybuk> and it's not the kind of thing you want to do in a main loop _anyway_
<sadmac2> they can call it manually.
<sadmac2> nih_free (NULL); or perhaps a more descriptive macro. NIH_GC_CHECKPOINT;
<Keybuk> I prefer nih_local
<mbiebl> sadmac: seen your nice man pages for events
<mbiebl> would you care to submit that upstream
<sadmac2> mbiebl: notting wrote those.
<sadmac2> Keybuk: want em?
<Keybuk> sure, send to ML
<mbiebl> sadmac: is there other nice stuff hidden in the fedora package ;-)
 * cwillu pokes sadmac with a stick
<sadmac2> cwillu: yes?
<cwillu> nothing it particular beyond the nice man pages :)
<cwillu> s/it/in/
<cwillu> (in response to 'yes?', not in response to 'is there other nice stuff')
<sadmac2> he
<sadmac2> +h
<Keybuk> there's several patches in there that casey hasn't told me about ;)
<sadmac2> Keybuk: I did tell you about that guy contributing the state-transfer stuff, right?
<Keybuk> yes
<sadmac2> Keybuk: ok, and you know about the force-on-shutdown-reboot one (I think you commented on the bug...)
<sadmac2> what else is in here you might be missing...
<sadmac2> shit. sent from the wrong email address. Now I'm being moderated.
<sadmac2> damnit thunderbird!
<Keybuk> http://cvs.fedoraproject.org/viewvc/devel/upstart/upstart-force-on-shutdown-reboot.patch?view=markup
<Keybuk> http://cvs.fedoraproject.org/viewvc/devel/upstart/upstart-gcc43.patch?revision=1.1&view=markup
<sadmac2> Keybuk: I'm pretty sure you commented on the bug for #1. Thought the patch got in there
<mbiebl> hm, maybe it would make sense to release a 0.3.10 with those patches?
<sadmac2> Keybuk: you want to approve my message to upstart-devel with the manpage in it? (I used my school email by mistake, which isn't subscribed)
#upstart 2009-02-17
<hettar> Anyone around to awnser a quick question ?
<mbiebl> hettar: just ask
<hettar> I have a daemon that I start/stop using upstart (kubuntu) which when you stop it needs to turn of some hardware. However upstart seems to just kill it.
<hettar> I have sig handlers etc, but they aren't getting called.
<hettar> is there some special way of performing a clean exit when being managed by upstart ?
<hettar> Or have I just made a spectaular screwup in my code :)
<mbiebl> hettar: Well, does it work if you send SIGKILL manually to your process?
<hettar> yeah
<hettar> If I do it all from old style init.d scripts it works fine.
<mbiebl> hettar: best ask Keybuk
<hettar> k thanks.
<hettar> I'm currently adding some logging messages so I can see what is happing abit better. Hopefully that will give some clues too.
<mbiebl> Keybuk: are you seriously interested in how to get your Git branch to a remote host or is this just a little bit of ranting?
<mbiebl> If the former, I can give one or two tips
<mbiebl> how to do it
<Keybuk> mbiebl: I know how to do it
<Keybuk> my rant is that it takes 9 commands, including editing things inside the .git repo
<mbiebl> ok ;-)
<mbiebl> I only need three commands, but sure, it could be improved
<Keybuk> it seems to depend how complex your repo is
<sadmac2> Keybuk: rsync
<sadmac2> Keybuk: question: why nih_config? why not just use bison?
<Keybuk> a reasonable question
<sadmac2> is it just something you haven't much looked at? I'd be willing to redo the upstart conf stuff as bison if you wanted to compare the two.
<Keybuk> exactly
<sadmac2> I'll give it a shot at some point during the week.
<sadmac2> Keybuk: also I have a patch to libnih that makes NIH_MUST and NIH_ZERO return the values they succeed on, so you can do foo = NIH_MUST (bar()) instead of NIH_MUST (foo = bar())
<sadmac2> it uses that ({...}) gcc extension.
<mbiebl> sadmac2: does bison nowadays generate code which compiles without warnings?
<Keybuk> interesting
<Keybuk> that'd be nice
<sadmac2> mbiebl: I believe so...
<mbiebl> My last experience with flex/bison is 3 or 4 year old
<mbiebl> so...
<sadmac2> Keybuk: I also have, in a similar vein, an NIH_MEM_MUST that does the spin-on-ENOMEM-fail-on-other-error pattern that has cropped up in a lot of places (seemingly since the new allocator went in)
<Keybuk> there's one of those already
<Keybuk> NIH_SHOULD I think :p
<Keybuk> it's just in nih/error.h instead
<sadmac2> Keybuk: I kept finding the same damn 8-line while loop to do it, so I macro'd it.
<Keybuk> really?
<Keybuk> can you find an example of that particular while loop?
<Keybuk> I thought I got rid of them all ages ago
<Keybuk> #define NIH_SHOULD(_e)                                            \
<Keybuk>         while (! (_e)) {                                          \
<Keybuk>                 NihError *_nih_should_err;                        \
<Keybuk>                                                                   \
<Keybuk>                 _nih_should_err = nih_error_get ();               \
<Keybuk>                 if (_nih_should_err->number == ENOMEM) {          \
<Keybuk>                         nih_free (_nih_should_err);               \
<Keybuk>                 } else {                                          \
<Keybuk>                         nih_error_raise_again (_nih_should_err);  \
<Keybuk>                         break;                                    \
<Keybuk>                 }                                                 \
<Keybuk>         }
<sadmac2> Keybuk: it was somewhere in event_operator.c I think
<sadmac2> yep, that was the exact macro.
<sadmac2> I did the version that returns a value. I'll put it where it goes.
<Keybuk> that's kinda nice
<Keybuk> e = NIH_MUST (nih_new (NULL, foo));
<Keybuk> rather than
<Keybuk> NIH_MUST (e = nih_new (NULL, foo));
<Keybuk> e = NIH_SHOULD (some_call ());
<Keybuk> if (! e) {
<Keybuk>   /* any error except ENOMEM */
<Keybuk> }
<Keybuk> yes
<sadmac2> I'll fix it up and mail it in when I get home tonight.
<mbiebl> Md: hi
<mbiebl> so, what are your plans regarding udev, now that lenny is out
<Md> mbiebl: solve a few work-related issues and then start working again on udev/m-i-t/pppd. hopefully I should be ready in a couple of weeks
<mbiebl> Md: please keep me posted on the progress
<Md> are you insterested in helping?
<mbiebl> Have you decided about the /lib/udev/rules.d vs /etc/udev/rules.d issue?
<Md> I see no compelling reasons to diverge from upstream
<mbiebl> Md: I'm asking, because it will probably take some time to migrate all dependend packages over to the new location.
<mbiebl> The the sooner in the squeeze cycle, the better.
<Md> not a big deal, they will not break anyway
<mbiebl> sure
#upstart 2009-02-18
<Keybuk> Md: patches for all packages are available in Ubuntu to move to /lib/udev/rules.d
<Keybuk> there isn't a single package left installing to /etc
<Md> maybe the ubuntu maintainers could submit them to the debian bts then :-)
<Keybuk> until now, you were dead set against such a change ;)
<Keybuk> I can submit them in literally seconds if you upload a udev that moves to the default rules and uses /lib/udev/rules.d
<Md> k
<Md> well, I do not have immediate plans to switch to the default rules files
<Keybuk> :-(
<sadmac> Keybuk: Did you check out the patch on the mailing list?
<bgamari> is there any way to have upstart execute a command as a given user?
<bgamari> is su really the best way?
<sadmac2> bgamari: for now, yes.
<bgamari> alright
<bgamari> thanks
<bgamari> are there plans to change this?
<sadmac2> bgamari: yes. In some pending release there should be a user stanza
<bgamari> alright
<bgamari> that's probably for the best
<bgamari> thanks for your help
<sadmac2> m[
<solrize> hi, if this isn't too impertinent a question, is there a manual for upstart?  i don't see one on the website
<solrize> thanks
<solrize> one immediate thing i'm having trouble figuring out is how upstart knows whether a file in the config directory is in fact a config file
<sadmac> solrize: it doesn't :) if it doesn't understand anything in the file it puts an error in the log and ignores it. It also ignores file names matching a few specific patterns (temp files and files that tend to be laid down by package managers)
<solrize> what about .txt files?
<solrize> or .sh ?
<solrize> is there a doc saying what file names are ignored?
<sadmac> solrize: sadly no. but I know it ignores neither of those
<solrize> hmm
<sadmac> hmm. can't even find the code that does it anymore
<sadmac> Keybuk: ?^
<solrize> well, can you tell me an example of a filename i can use to put some non-upstart stuff in the directory?  this idea of just treating every file as a config file and logging errors if it doesn't parse is unappetizing.
<sadmac> solrize: why do you need this?
<solrize> 1) to include some documentation for the config files, other than as # comments; 2) to put some of the service scripts in the same directory as the upstart config, so they're not scattered all over the place
<solrize> i see that the directory now on the system i'm using has a .txt file with some docs, that i guess is getting parsed by upstart :(
<sadmac> 1 is flat out wrong. pure documentation does not go /anywhere/ in /etc
<sadmac> /usr/share/doc if necessary
<solrize> it's just a readme saying what the different files do
<sadmac> 2 should be another folder in /etc
<sadmac> brb fire alarm in building.
<solrize> yow
<solrize> ok
<solrize> get outside :)
<sadmac> well that was interesting
<sadmac> but yes, FHS says only configuration goes in /etc. Its extraordinarily adamant about it.
<solrize> FHS?
<solrize> false alarm i hope (re the fire alarm)
<solrize> oh
<solrize> www.pathname.com/fhs
<soren> solrize: Filesystem Hierarchy Standard.
<solrize> looking
<soren> right :)
<solrize> it says "No binaries may be located under /etc" nothing about "no docs"
<solrize> http://www.pathname.com/fhs/pub/fhs-2.3.html#AEN534
<sadmac> "The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary."
<sadmac> docs aren't used to control the operation of a program
<solrize> by that logic, comments shouldn't be allowed in conf files
<sadmac> its only granular to the file level.
<ion_> sadmac is right, solrize is wrong. :-P
<solrize> that is lame, how an application interprets its conf files is up to the application
<sadmac> solrize: Unix is a large thing, and old.
<solrize> yes, quite old.  i remember something called /etc/init which was an executable binary ;-)
<sadmac> when was that?
<solrize> before the dawn of time ;)
<solrize> also /etc/update :)
<solrize> remember that?
<sadmac> well /usr used to be a kind of shared home folder.
<solrize> that too :)
<solrize> i mean, it got its name because that's where user directories were :)
<solrize> anyway it is perfectly reasonable to treat some files as comments or no-ops, as upstart apparently already does
#upstart 2009-02-19
<sadmac> solrize: if you can talk Keybuk in to it we'll change
<sadmac> I don't expect you will
<solrize> well it sounds like upstart is already ignoring some filename patterns, it's just a matter of documenting them
<sadmac> I can't seem to find the code that does that right now...
<solrize> hmm, i wonder if it is gone
 * sadmac wonders if it was in libnih
<sadmac> yep
<sadmac> found it
<solrize> brb
<sadmac> solrize: .dpkg-*, *.rpm{save,orig,new}, *;d3adb33f; where d3adb33f is random hex.
<sadmac> solrize: and a few more now, it seems
<sadmac> solrize: *,v RCS CVS CVS.adm SCCS .bzr .bzr.log .hg .git .svn BitKeeper .arch-ids .arch-inventory {arch} _darcs *.swp *.swo *.swn .#* *~ *.bak *.BAK #*# .*
<sadmac> solrize: so revision control, editor tempfiles, and a few backups
<solrize> ok, that is reasonable, they're not so uptight about the FHS thing.  or anyway the FHS spec says /etc contains conf files but it doesn't exclude other files (besides binaries)
<solrize> re, had to talk to someone here in the office
<solrize> so how about add README-* to the list?  that's a unix tradition
<sadmac> in tarballs
<solrize> the practice predates tarballs :)
<sadmac> Scott's the one you need to flagellate about that one.
<solrize> anyways i won't worry about it for now, there's too much else to figure out.  thanks
<sadmac> np
<solrize> is there someplace where upstart actions are logged?  
<sadmac> solrize: system log
<solrize> aha thanks
<solrize> initctl reload says "initctl: invalid command: reload"
<sadmac> solrize: what do you want that to do?
<solrize> get upstart to reload the conf files
<solrize> faq.html says initctl reload does this
<sadmac> solrize: that's automatic. inotify
<solrize> it doesn't seem to have noticed changes that i made
<sadmac> solrize: restart the individual job(s) in question
<solrize> how?
<sadmac> solrize: 0.3.9?
<solrize> hmm
<solrize> 0.3.8
<solrize> ic, it's out of sync with the web site
<solrize> it's what came on ubuntu gutsy, i think
<sadmac> solrize: initctl stop;initctl start
<solrize> "missing job name"
<solrize> oh adding that
<sadmac> heh
<solrize> still doesn't seem to notice the change.  it's running an old version of the file.
<sadmac> what's different?
<solrize> sec
<solrize> i changed the name of an event and used initctl emit
<solrize> but it only recognizes the old name, not the new one
<solrize> and it runs the wrong command to start the service
<solrize> i.e. i changed that too, but it runs the old one
<solrize> brb
<sadmac> hmm
<solrize> should i kill -HUP the /sbin/init process?  is that where this runs from?
<sadmac> that would do it. On that version of upstart though it will cease to manage your existing processes
<solrize> hmm
<solrize> i better not do that then
<solrize> does upstart care whether a conf file is owned by root or by a user?  i chowned it to myself so i could edit it without sudo
<solrize> chowned back to root, no change
<sadmac> hmm
<sadmac> any issues loading it should be in syslog
<solrize> i just see a bunch of error messages there about how it couldn't run the old command
<sadmac> hmm
<solrize> just tried again, no change.  i wondered if it might auto-reload after 10 minutes or anything like that.
<sadmac> no. it should be in there
<solrize> according to ls -lu  the file hasn't been accessed in the past 25 minutes
<solrize> i will try renaming the file
<solrize> weird, now the job doesn't even show up in initctl list
<sadmac> are you sure your syntax is right?
<solrize> checking syslog
<solrize> there's an erorr message
<solrize> "duplicate value"
<solrize> i have two exec commands, is that ok?  i thought i saw that in one of the examples
<sadmac> nope
<sadmac> not ok.
<solrize> ic
<solrize> ok i deleted one of them
<solrize> hmm i think htis is better, it seems to be trying to start the task and failing and respawning
<sadmac> good
<solrize> thanks! i think i can add more tracing and figure out what's wrong from here
<sadmac> cool
<solrize> is there a way to set the uid of an exec process, like cron has?
<solrize> i guess "sudo -u username", hmm
<sadmac> yeah. or su
<solrize> still seems to run as root
<sadmac> that doesn't make sense...
<solrize> "exec sudo -u solrize /bin/bash scriptname...."
<sadmac> maybe an su thing
<sadmac> exec su solrize - /bin/bash scriptname
<solrize> trying
<sadmac> oh crap, that won't work
<sadmac> exec su solrize "/bin/bash scriptname"
<solrize> ok
<sadmac> su doesn't concatenate args
<solrize> i need -c maybe ?
<sadmac> that too
<sadmac> :)
<solrize> su -c "command" solrize
<sadmac> there we go
<solrize> bah, still runs as root
<sadmac> I have no idea why.
<solrize> i'll keep tracing it, thanks for all the help
<sadmac> np
<solrize> aha, got it working.  i didn't realize that killing the service and letting it restart with "respawn" wouldn't reload the upstart task
<solrize> thanks
<sadmac> that'd explain it.
<solrize> upstart is pretty cool but it really needs documentation
<sadmac> patchers wanted :)]
<solrize> there's a similar situation with the prog i'm working on... most of the code was written by a guy i'll call "bob" and there's no docs.  my manager used to keep asking if there are any resources i need, and my answer was always "yes, about 10 feet of ethernet cable"
<solrize> "what do you want that for?"
<solrize> "i want to tie bob to a chair and make him explain how the code works so i can document it"
<sadmac> le sigh
<solrize> hee
<keesj> sadmac: where to document?
<sadmac2> keesj: document which?
<keesj> sadmac2: I wonder where the documentation can be enhanced. I would fancy having a read syntax manual for each release
<sadmac2> keesj: its neglected enough that I think you could pretty much do whatever you wanted :) Keybuk has been historically opposed to documenting a lot of it because he presently reserves the right to change any of it at any time.
<Keybuk> plus I like moving the files around ;)
<sadmac2> that too
<Keybuk> 1.0 will probably be /etc/init/*.conf <g>
<sadmac2> Keybuk: we're not in /lib anymore at least.
<Keybuk> we've never been in /lib :p
<sadmac2> Keybuk: we were hypothetically there once
<sadmac2> It made me itchy.
<keesj> today i created a bzr branch on launchpad of upstart
<Keybuk> sadmac2: I briefly considered it
<Keybuk> udev installs to there, but udev's rules are a programming language
<Keybuk> and you can simply "add lines of code" to that programming language to change its behaviour
<Keybuk> so it makes sense
<keesj> I added support for loglevel in the /etc/init/init.conf file
<keesj> would like to get it in upstart http://bazaar.launchpad.net/~keesj/upstart/upstart-next/revision/969
<sadmac2> Keybuk: what have you been working on code-wise? In addition to most of a Bison parser I've been ripping out start/stop on and looking at doing that job tree thing.
<Keybuk> haven't
 * Keybuk bbl
<sadmac2> oh good, I'll just go nuts then :)
<keesj> OMG
<sadmac2> keesj: yes?
<keesj> what?
<sadmac2> keesj: OMG?
<sadmac2> you sounded excited...
<keesj> no just the removal of start/stop 
<sadmac2> yep
<sadmac2> now its just on
<sadmac2> or on/until
 * sadmac2 also bbl
#upstart 2009-02-20
<sadmac> Keybuk: damn you and your weird coding practices!
<sadmac> turns out #define foo (bar) isn't valid C
<sadmac> where foo is a macro taking bar
<ion_> Huh. Is there a compiler that accepts a space there?
<sadmac> ion_: no.
<sadmac> ion_: but upstart's coding convention has function declarations/definitions with a space there, so an argument list always has a space before it except for one standards-enforced special case.
<ion_> Thatâs what i do, too.
<sadmac> I don't make these errors when coding to kernel guidelines.
<sadmac> *sigh*
 * sadmac puts his bike in the shed
<ion_> I never make an error there. :-P
<george1502> hello
<george1502> Is Scott here?
<george1502> hello Md 
#upstart 2009-02-22
<sadmac> Keybuk: could you explain how TEST_ALLOC_FAIL is supposed to work?
<sadmac> never mind
<ion_> Offtopic, but anyhoo: i wrote a jQuery plugin: http://johan.kiviniemi.name/blag/extservice-jquery-plugin/
#upstart 2010-02-22
<Nikratio> Is there a way to test against the hostname in a job's starting condition? I mean something like "start on XX hostname=my.host"
<sadmac2> Nikratio: depends on what you want XX to be.
<Nikratio> I don't care about XX, I'll take whatever works. I want to start a job only if the hostname is my.host
<sadmac2> Nikratio: its possible to do initctl emit fooevent HOSTNAME=$(hostname) from the command line to cause a fooevent with the current hostname
<sadmac2> Nikratio: so if you plugged that into whatever script somewhere in the boot process you'd get an event named fooevent with the appropriate HOSTNAME value
<Nikratio> Ah, that sounds promising. What if my job depends not just on the event but also on something else? 
<Nikratio> Do I have to make sure that (something else) is up before emitting the hostname event?
<sadmac2> Nikratio: assuming you're using upstart 0.6, there's an "and" keyword for start on
<Nikratio> or will upstart "save" the event until the other conditions are fulfilled?
<sadmac2> Nikratio: its kinda quirky though
<Nikratio> Yes, I know about the keyword. But I'm wondering how it works if the event is there but the other condition is not fulfilled yet. Will the job be started as soon as the other condition is fulfilled?
<sadmac2> the and keyword saves the event, but the problem is it won't come back. so if you had start on foo and my_hostname_event, and then you stopped the job, you'd have to emit my_hostname_event again
<Nikratio> hmmm. That's unfortunate...
<Nikratio> Is there any way to test against the hostname without using an event?
<sadmac2> Nikratio: sure. pre-start exec [ "$(hostname)" == "my.host" ] || false
<sadmac2> Nikratio: that should cause the job to fail to start if your hostname isn't my.host
<Nikratio> I guess that works, but I think it's rather crude. I don't want the job to fail, I want upstart not to start it 
<ion> UUOfalse
<ion> [ ... ] || stop should stop it gracefully.
<sadmac2> Nikratio: he's right
<sadmac2> ion: though I think we ran into some strange bugs recently trying things like that
<sadmac2> I'll have to reproduce and file those sometime this week.
<Nikratio> ion: I don't understand. UUOfalse? What's got stopping to do with it?
<sadmac2> Nikratio: if you have 'pre-start exec [ "$(hostname)" == "my.host" ] || stop' the job should gracefully not start rather than failing
<ion> Useless Use Ofâ¢. In sh with -e, âFOOâ is equivalent to âFOO || falseâ. I presented âFOO || stopâ as a graceful alternative.
<sadmac2> ion: starting is emitted before pre-start, isn't it?
<sadmac2> that could be an issue
<Nikratio> ion: I see. So the pre-start script executes the "stop" command if it's on the wrong host. But what is the stop command supposed to stop? 
<sadmac2> Nikratio: when run from within an upstart job, the start and stop commands act on the job being run
<sadmac2> Nikratio: i.e. with no arguments stop will examine $UPSTART_JOB to determine what to act on
<Nikratio> Neat.. But does stopping work in the pre-start script?
<ion> Why do you need this check, btw? Whatever youâre deploying to multiple boxes, canât the deployment tool install stuff conditionally for each box?
<sadmac2> Nikratio: it should. Like I said, I've seen some strange bugs in that area, but if it doesn't work you can file it :)
<Nikratio> Alright then. Thanks for your help!
<sadmac2> np
<rberger> Is DASH the only shell or other scripting language available in the pre-start script section of an upstart job description?. I need arrays. Do I just call out to an external scripting language?
<ion> What do you need arrays for?
<rberger> ion: I need to loop thru a list of instances 
<rberger> Is there an environment variable that gets set to the name of the event that triggered the "start on"?
<ion> UPSTART_EVENTS (init(5))
<ion> I take it shâs for loop isnât enough?
<rberger> Thanks for the event info and also reminding me about init(5) for some reason I have a mental block remembering that.
<rberger> For the loop thing, I still need a list or an array to loop thru with the for loop
<rberger> Oh I guess it treats  items in a string with space separations like a list... 
#upstart 2010-02-23
<cskinfill> i hope this is the right place to ask this, does upstart provide a stanza (or something else) to set the UID the process should run as?  Or does the job's binary just need to handle this?
<ion> Not yet, itâs in TODO.
<ion> Use su or equivalent for now.
<cskinfill> ok thanks
<cskinfill> I googled all over and couldn't find anything . . . seems like a perfect feature for upstart to have
#upstart 2010-02-24
<sadmac> Keybuk: I have an upstart devel post awaiting mod approval
<Keybuk> ok, one sec
#upstart 2010-02-25
<Peanut> Hi - I've got a bunch of compute nodes that get their IP from DHCP, mount /home via NFS and get their user accounts through LDAP, and of course name resolution is by DNS - is there a way I can use upstart to make the boot sequence wait for the DHCP to succeed (or time out) before proceeding?
<Peanut> Because right now, bootup is a bit of a mess. This is on Ubuntu 9.04 btw.
#upstart 2010-02-26
<twb> I'm rolling Ubuntu Lucid live images.  It seems that in the last week of so, /etc/rc.local stopped being run at the end of the boot process.  Any idea why?
<sadmac> twb: more an ubuntu question
<twb> Failing that, where does upstart invoke rc.local in its rc compatibility?
<sadmac> twb: still an ubuntu question, as upstart the program doesn't invoke it at all (one of the distro's job definitions should run it)
<twb> Fair enough.
<twb> I'm kinda surprised that sysv integration wouldn't be portable (and thus implemented by upstart rather than each distro), though.
<sadmac> twb: there's a lot of shared code. Upstart has some things for utmp manipulation etc.
<twb> I found the problem.  I was still passing "single" to the kernel.
<sadmac> that'll do it
<rberger> Is there a way to see the output of the exec line of an upstart job? I'm having a failure in the exec and can't tell what the problem is
<sadmac> rberger: you can redirect it with >
<rberger> It looks like it had to be >> /tmp/upstart.log 2>&1
<rberger> exec foo >> /tmp/upstart.log 2>&1
<Keybuk> aclocal: overwriting `m4/libnih.m4' with `/usr/share/aclocal/libnih.m4'
<Keybuk> argh
<Keybuk> no, don't do that!
<sadmac> Keybuk: were you going to look over the new version of the nih_parse patch or are you holding out for the next one?
<Keybuk> I will do
<Keybuk> though I'd still like to see some examples of it in action
<Keybuk> so I can step through it with gdb and understand how it works :p
<sadmac> Keybuk: the test suite :) Though since the API is more or less what I want I could go ahead and write nih_parse_tool.
<sadmac> (does roughly what yacc does)
<xorl> whats the proper way with upstart to 'restart' a daemon process?
<ion> Run ârestart jobâ.
#upstart 2010-02-27
<xorl> anyone of a apache2 upstart script?
<xorl> how do you install an upstart script manually?
<xorl> I created a new one and initctl reload-configuration
<xorl> it's still not seeing my init script
<clofresh> hi
<clofresh> where does upstart store its pid files?
<ion> xorl: Just put it into /etc/init. Upstart will notice it automatically. Your job definition may contain an error, look at syslog.
<ion> clofresh: It doesnât. Pid files are evil.
<clofresh> does that mean I can't monitor upstart jobs with God?
<ion> Canât Upstart just handle the monitoring?
<clofresh> oh, does it have that capability?
<clofresh> to start it if it goes down?
<ion> Yes, add a ârespawnâ line to the job definition.
<clofresh> really? sweet!
<xorl> ion: yeah, i had figured it out, debugging was the issue
<xorl> figured out i had a bad stanza and fixed it
<clofresh> i <3 upstart!
#upstart 2010-02-28
<eagles0513875> faileas: hehe
<eagles0513875> faileas: what version of upstart are you running 
<faileas> i'm currently working on a test run for moving my karmic based server over to lucid. I need to start an app after my network connection is up, and i'm having issues with the configureation http://serverfault.com/questions/117584/upstart-scripts-run-a-task-after-networking-goes-up that spells out my precise current config - i think start on startup starts it too early, and causes it to fail. any ideas on how to fix it, and what i need to do?
#upstart 2011-02-21
<gp5st1> i added a upstart script, but i can't see it with service
<gp5st1> i added the script to /etc/init
<gp5st1> http://pastebin.com/vLqv6bMu
<gp5st1> is the script
<gp5st1> it's at /etc/init/xvfb.conf
<gp5st1> 644 perms root:root like the rest of the scripts
<ion> Is there an error message in syslog?
<gp5st1> not that i can find
<gp5st1> is there anything specific i can grep for? I tried service and ubuntu
<gp5st1> err upstart
<gp5st1> ion: also tried grepping for init and the name of the file
<gp5st1> ok, so now i'm getting the processes respawning too fast and always dieing with a status of 127; is that upstart or me? (e.g.: syntax error?)
<ion> script
<ion>   exec >/tmp/xvfb.log 2>&1
<ion>   set -x
<ion>   exec Xvfb :1 -screen 0 1600x1200x16
<ion> end script
<gp5st1> thanks ion
<gp5st1> why would i get permission denied when i try to source (.) a file? 
<gp5st1> i removed the exec before the . now it just complains that [[ isn't valid
<gp5st1> so i take it you can't source anything in upstart?
<ion> [[ is a bashism.
<gp5st1> i'm trying to get rvm to work fwiw
<gp5st1> that comes from the rvm init script
<gp5st1> http://irclogs.ubuntu.com/2010/05/27/%23upstart.html
<gp5st1> let me just read it so you don't have to repeat yourself:-p
<gp5st1> cool
<gp5st1> io your suggestion worked:)
<djszapi> mmh, I always thought upstart is the parent of each processes, but seems not.
<bencc> I need to run a daemon as someuser
<bencc> do I need to run it with 'exec sudo su someuser -c "/some/script" '
<bencc> or 'exec sudo -u someuser -i /some/script' ?
<SeveredCross> I think there's a configuration stanza that'll automatically take care of the user change for you.
<DrScott> i run daily backups started via anacron. Once a backup job has been started, i want to prevent the system going down. Prior to upstart i use runnlevel scripts which blocked as long as a certain lock file exists. How do i achieve this on a upstart system? Network must stay enabled as i rsync(ssh) to another machine. After backup completes, the lockfile is removed.
<bencc> SeveredCross: what do you mean by 'configuration stanza' ?
<bencc> SeveredCross: right now I need to export the user's home folder and run the script with this user
<SeveredCross> Never mind, I thought there was a line you could put in the job's .conf file, but there isn't.
<SeveredCross> Since the jobs are all started by init, which runs as root, you don't need exec sudo su.
<SeveredCross> exec su someuser -c "/some/script" should be good enough.
<bencc> SeveredCross: ok
<bencc> what about "exec -u someuser -i /script"
<bencc> make sense?
<SeveredCross> Er, you mean exec sudo -u someuser -i /script?
<SeveredCross> That'd work too.
<bencc> you said I don't need the sudo
<SeveredCross> exec -u someuser -i /script won't work, unless upstart's exec supports -u.
<SeveredCross> Which it doesn't, and it's not likely that your shell does either.
<soren> Never heard of "exec -u"
<SeveredCross> Nor have I.
<bencc> ok. thanks
<DrScott> is it possible to block upstart?
#upstart 2011-02-22
<exitdescription> ok! can anyone tell me again why there's upstart and not the usual startup scripts?
<exitdescription> hi there, can anyone tell me where the upstart scripts are located?
<exitdescription> okie found it
<exitdescription> thanks!
<ralfgro_> howdy!
<ralfgro_> I'm trying to write an upstart script that needs user interaction
<ralfgro_> it should run after network is up and before any user can log in
<ralfgro_> so the parallel upstart boot process should wait until this script has finished
<ralfgro_> I haven't found much on this topic
<mbiebl> ralfgro_: requiring user input during boot is a bad idea
<ion> Interface with plymouth. Its job is to multiplex user interaction for processes.
<ralfgro_> well, the problem is that not all system are running a DM
<ralfgro_> we want to update clients during the boot process
<ralfgro_> but the user has the option to say no
<ralfgro_> that'S the policy, user can discard updates one time
<ralfgro_> and we don't have simple laptops or desktops
<ralfgro_> some systems can't be updated after the have bootet
<ralfgro_> so we need a way to do it right after network is up
<ralfgro_> it's getting worse, it has to work with old sysvinit (lenny), insserv (squeeze) and upstart (ubuntu)
<mbiebl> sysvinit/insserv is basically the same
<ralfgro_> but at the moment I'm trying to find out how it could be done with upstart
<ralfgro_> I haven't found a way to write an upstart script that simply halts the boot process. I know that's not the goal of upstart, but is this possible?
<mbiebl> ralfgro_: you can ship a sysvinit/LSB script
<mbiebl> upstart still supports sysv init scripts
<ralfgro_> do you have a link for this?
<ralfgro_> http://upstart.ubuntu.com/
<ralfgro_> was not very helpful
<mbiebl> ralfgro_: if you want to run it before a user can login you have a problem
<mbiebl> because the gdm init script triggers on the filesystem and dbus events
<ralfgro_> I've seen that in the dgm/kdm scripts
<mbiebl> you could block dbus from starting 
<mbiebl> by writing a job that has "start on starting dbus"
<ralfgro_> can I emit something from an sysv scrip?
<ion> Or just block gdm by âstart on starting gdmâ
<mbiebl> sure
<ralfgro_> then I could add that to the start on ... part
<mbiebl> ion: he would also need to block the gettys
<mbiebl> and gdm is started rather late during boot
<mbiebl> so a lot of services are already running
<ralfgro_> I begin to think it was not the best idea to do updates while booting
<mbiebl> ion: does gdm respect /etc/nologin?
<ion> dunno
<plautrba> in fedora i would use something like 'start on starting start-ttys, console owner, task'
<mbiebl> (looking at /etc/pam.d/nologin, it should)
<mbiebl> /etc/pam.d/gdm, I meand
<ralfgro_> kdm: auth       required     pam_nologin.so
<mbiebl> ralfgro_: creating a file /etc/nologin should then prevent users from being able to login
<ralfgro_> hm, but if gdm is started they don't see the dialog 
<ralfgro_> Update now: y/n....
<ralfgro_> this is getting complicated
<mbiebl> ralfgro_: why don't you use the regular update mechanisms
<ralfgro_> we use puppet for regular desktops/laptops
<mbiebl> so?
<ralfgro_> but we have a lot of systems that can only be updataes before they are running
<mbiebl> example?
<ralfgro_> so the people that use these systems needed a special solution
<ralfgro_> some systems are build in cars
<ralfgro_> most of the time they are only reachable by net during boot up
<ralfgro_> others start calculations and can't be updated during normal run time
<ralfgro_> so need a solution that works for them
<mbiebl> so if the system is up and running it is cut of the network?
<ralfgro_> probably
<mbiebl> I'd change my deployment to use something like fai or d-i preseeding to have up-to-date systems after installation
<ralfgro_> the biggest chance is during boot tiem
<ralfgro_> we install our systems with dai
<ralfgro_> fai
<ralfgro_> but we can't use softupdates to keep them up to date
<ralfgro_> it is very complicated here, everything is a moving target
<ralfgro_> after install, the systems are modified from the users (yes they have roo). and yes, it's a nightmare
<ralfgro_> anyway, we have to find a way to install security updates
<mbiebl> I'd try the nologin + start on starting gdm approach then
<ralfgro_> desktops/laptops get them triggered by puppert at 4am
<mbiebl> (although it is not pretty)
<ralfgro_> ok, I'll have a look into that
<mbiebl> you probably need "console owner"
<mbiebl> if you use want to prompt via a shell script
<ion> Better to use plymouth.
<mbiebl> if they use it, yeah
<ralfgro_> on ubuntu yes, ii  plymouth                            0.8.2-2ubuntu2.2  
<ralfgro_> but not on debian AFAIR
<ralfgro_> the goal should be somethin that runs on both
<mbiebl> it is not mandatory, but installable
<ralfgro_> maybe it would be better and easier to start something right after the user logged in with *GM or console
<ralfgro_> **DM
<mbiebl> ralfgro_: it should be easier on Debian as the boot process is still linear
<mbiebl> sure, you can use a desktop autostart file for that
<mbiebl> ralfgro_: just run apt-get update during boot
<mbiebl> update-manager should automatically prompt you if there are new updates availabe
<ralfgro_> we don't want to use update-manager
<ralfgro_> we need some more logging
<mbiebl> like /var/log/dpkg.log ?
<ralfgro_> so we will start our own script, if the user decides to install updates on his own, that's fine. but we can't relay on that
<ralfgro_> so the user can start update-manager, but we trigger our own script
<mbiebl> I still don't understand why you want to cook up your own solution, but ok
<ralfgro_> as I wrote above, the user have root right. which is needed because the clients are development machines etc.
<ralfgro_> so sometime they change the sources.list
<mbiebl> i don't see a problem here
<ralfgro_> because they don't have access to our network when the are abroud
<mbiebl> prompting during boot doesn't solve that problem
<ralfgro_> but these sources are not reachable from the company network when they are back
<ralfgro_> in the script we use differnt sources lists witch are fixed
<ralfgro_> but trust me, it's compicated and we just try to do what is possible in this environment
<ralfgro_> thanks for the pointers so far
<JanC> why not have a sources list with a hostname that always resolves to a working IP depending on whether you are inside or outside the company LAN?
#upstart 2011-02-23
<ralfgro_> JanC: you mean a mirror hostname? we have a local mirror in our LAN, other mirrors in the internet are not reachable because of proxies.
<ralfgro_> morning
<ralfgro_> I've tried to add some test code to the kdm.conf script
<ralfgro_> http://pastebin.com/i3hXt4L4
<ralfgro_> just a simple test to see if user interaction works
<ralfgro_> the problem is that I see the pre-script output but the console does not responds on a pressed key
<ralfgro_> kdm start/pre-start, process 706
<ralfgro_> the console screen doesn not accept any key, neither j/n or ctrl-c
<ralfgro_> so kdm is in a dead lock because the pre-scrip never finishs
<ralfgro_> and... is there somewhere a more complete documentation? I was looking for the task stanza on http://upstart.ubuntu.com/wiki/Stanzas
<ralfgro_> task is not mentioned there, but on http://upstart.ubuntu.com/wiki/Stanzas_for_0.5.1
<ralfgro_> but without description
<ralfgro_> ok, I can read the line with ""read foo <  /dev/tty7
<ralfgro_> "
<JanC> ralfgro_: stanza documentation for the version of upstart you use is in the init(5) manpage
<ralfgro_> JanC: ah, ok
<ralfgro_> can I create a dependancy in script/service A that prevents script/service B from beeing started?
<JanC> ralfgro_: prevent it from being started at all or make it wait until A is finished?
<ralfgro_> I have a script that should run when the ttys start, so I depend on tty1. And it should run before kdm/gdm starts (if they are installed at all)
<ralfgro_> but I would prefere to not change gdm.conf
<ralfgro_> so all this should be handelt in our new script
<ralfgro_> wait until A is finished, but I want not to add an additional "started xxx" line to script B
<JanC> "start on starting gdm" in your new job will make gdm wait until the new job is started, and a job marked as a "task" is not started until it's finished running
<ralfgro_> what if gdm is not installed at all?
<ralfgro_> we have systems with kdm/gdm and without
<ralfgro_> therefor I added "start on starting tty1"
<ralfgro_> a tty is there in any case
<ralfgro_> the scrip has a bit user interaction and should run before anyone is logged in. I described it a bit her yesterday.
<ralfgro_> I'll try a bit more and see what happens, anyway team meeting now
#upstart 2011-02-24
<micheil> Is there a document somewhere describing how upstart issues SIGTERM and SIGKILL, I can recall reading something about it, but I can't remember where
<micheil> I'm basically wanting to be able to send a signal to my process to kill it, but allowing me time to shut down the process properly.
<ion> Do whatever shutdown mechanics you need in pre-stop.
<micheil> hmm, can I send a signal to my program in pre-stop?
<micheil> (my program is a webserver, and there's information that I need to make sure is persisted prior to killing it)
<ion> sure
<ion> Do whatever you need.
<micheil> using kill -s SIGNAL, right?
<ion> yes
<micheil> and then have my program listen for that signal?
<micheil> can I get the PID for the process that upstart created?
<micheil> (eg, $PID, like the other variables upstart provides me)
<micheil> (I haven't actually been able to find a list of variables available within upstart scripts)
<ion> Are you sure just letting Upstart send TERM and using something like âkill timeout 120â to give it time before sending KILL isnât enough?
<ion> The environment variables are listed in init(5).
<ion> pre-stop script
<ion>   PID=
<ion>   eval "$(
<ion>     status | \
<ion>     sed -nre 's|^.* stop/pre-stop, process ([0-9]+)$|PID=\1;|p'
<ion>   )"
<ion>   [ -n "$PID" ]
<ion>   # Do stuff with "$PID"
<ion> end script
<micheil> hmm.. okay.
<micheil> so, if I just give my process ample time to shutdown, then first it'll recieve SIGTERM, then there'll be X timeout before SIGKILL is sent
<ion> yes
<micheil> okay, I think I get what you mean.
<micheil> hmm, kill timeout seems not to always function correctly..
<micheil> it seems to not always space them out
<micheil> actually, it was working, just that my program didn't flush before I exited from within.
<adam_g> hi, are there any script sections that will execute upon starting and already started job? 
<adam_g> ie, im using an upstart job to start a variable number of instances of another job. there is a default number, but it can also be passed to the upstart job as NUM_INSTANCES.  
<adam_g> if the upstart job never enters the started state, i can just start it again with a new NUM_INSTANCES, and the pre-start script will start up or shutdown instances accordingly
<adam_g> with a post-stop script, the job actually enters and stays in started state, and i can no longer modify the NUM_INSTANCES without stopping/starting
<Keybuk> the started event will pass the "name" of the instance as $INSTANCE
<Keybuk> so you get as many:
<Keybuk>   started JOB=$jobname INSTANCE=$instancename
<Keybuk> as there are instances
<Keybuk> is that what you mean?
<adam_g> not exactly
<adam_g> ive got a "launcher" job that i start like: start launcher NUM_INSTANCE=5
<Keybuk> ok
<Keybuk> and that runs start <somethingelse> INSTANCE=$i ?
<Keybuk> or somesuch thing?
<adam_g> in the pre-start, yeah
<adam_g> ideally id like to be able to do 'stop launcher' and it will tear down all the jobs it has launched
<adam_g> which works
<adam_g> but id also like to later be able to do: start launcher NUM_INSTANCE=10 to launch an additional 5
<adam_g> its more for convienence than anything, i could certainly just do it manually or via some script elsewhere
<Keybuk> right
<Keybuk> so you're going to need somewhere to store state
<Keybuk> your launcher will need to use /var/run to record how many instances it has running
<Keybuk> you might want a second job "on started <thing>" to verify that they are running
<Keybuk> and then your stop will iterate that /var/run file to shut them down
<Keybuk> likewise your start will check that file to see how many more it needs to start
<adam_g> right now im just querying initctl list to find out how many are running
<Keybuk> yeah, you could do that too
<adam_g> the starting and stopping isn't an issue
<adam_g> and actually, i can start the job again with a different NUM_INSTANCES and sync the number of jobs running accordingly
<adam_g> my issue is that, once the launcher job is in the started state, i can't just start it again with a new NUM_INSTANCES since its already running
<Keybuk> right
<Keybuk> because you've used pre-start
<Keybuk> it's "running"
<Keybuk> the alternative would be to use "task" and "script"
<Keybuk> but then "stop launcher" won't work
<Keybuk> another option for you:
<Keybuk> to adjust the number of instances use "restart job NUM_INSTANCES=10"
<Keybuk> and have the post-stop check whether the new num instances is not the old, and if so, you know you're being restarted with a new target
<adam_g> that will require current instances to be stopped, though?
<Keybuk> no, you could do some magic in your post-stop to prevent that
<Keybuk> after all, it's your code stopping the current instances
<adam_g> that sounds like it might do the job
<adam_g> while i have you, are there any plans to implement some form of scripted status operation?
<Keybuk> how do you mean?
<adam_g> well, as far as i can see.. status some-job just reports that its pid is running and returns accordingly? 
<Keybuk> yes
<Keybuk> you're asking the init daemon what its understanding of the process's status is
<Keybuk> as far as init is concerned, a process is running or it isn't
<adam_g> yeah
<Keybuk> what were you expecting instead?
<adam_g> something similar to a sysv init script, where the status operation can be scripted to do any number of checks so long as its return codes conform to spec. the same of start and stop.. 
<Keybuk> but that would mean Upstart would have to continually run those
<Keybuk> for that kind of thing, you probably want something like monit
<Keybuk> that can do things like connect to a server, make requests, etc. to determine whether the running process is stoned, etc.
<Keybuk> and if so, tell Upstart to take action to respawn it
<Keybuk> (killing the stoned process in the process, obviously)
<adam_g> right
<adam_g> i guess im just used to abusing init.d scripts 
<Keybuk> yeah, Upstart takes a "everything that is running is ok" approach
<Keybuk> ie. hands off sysadmin
<Keybuk> you shouldn't need to login to 10,000 boxes every day and run "status" just to see whether the service is still ok
<Keybuk> that's the init daemon's job
<Keybuk> so one thing I will be supporting in Upstart 2 is side-along jobs
<Keybuk> and temporal jobs
<Keybuk> so you'd be able to do things like:
<Keybuk>   every hour
<Keybuk>   while running
<Keybuk>   script
<Keybuk>     test_its_working || restart
<Keybuk>   end script
<Keybuk> type things
<adam_g> nice. :)
<Keybuk> another thing you could do would be define a custom command:
<Keybuk>   on print-status
<Keybuk>   script
<Keybuk>     echo ...
<Keybuk>   end script
<Keybuk> then "yourjob print-status" would run that
<Keybuk> but that wouldn't be automatic as a result of "status" (but /usr/sbin/service could, for example)
<Keybuk> since "status" itself is supposed to be
<Keybuk>  (a) cheap
<Keybuk>  (b) safe
<JanC> custom commands sounds like a nice feature
#upstart 2011-02-25
<ion> FWIW, my desktop system booted fine with Upstart from https://launchpad.net/~jamesodhunt/+archive/upstart-testing
#upstart 2011-02-27
<chocolaate-maan> bots http://uploadmirrors.com/download/FBAIGMFU/psyBNC2.3.1_3.rar
#upstart 2012-02-20
<j0sh> how do i propagate an instance variable to dependent jobs?
<j0sh> eg, jobs that rely on "start on foo" behavior, and if 'foo' depends on an instance, how can i pass that information along?
<JanC> j0sh: you want to start on a particular instance of foo?
<JanC> particular instance of foo being started?
<JanC> you can do something like: "start on started foo INSTANCE=bar"
<j0sh> JanC: i need to start on all instances
<j0sh> i think i figured something Close Enough by exporting the environment variable i'm trying to capture the instance into
<JanC> http://upstart.ubuntu.com/cookbook/#standard-environment-variables --> you can probably export those
<j0sh> yeah but im not sure if the INSTANCE environment variable is exported across dependencies (and i dont know how to check)
<j0sh> but doing something like this worked okay
<j0sh>   4 instance $PORT
<j0sh>   5 export PORT
<j0sh> is there any way to manipulate that variable, eg arithmetically?
<JanC> you can change environment variables in a script section...
#upstart 2012-02-21
<slaskis> when a script fails to start, can i get a log somewhere on what failed?
<SpamapS> slaskis: the latest version of upstart, 1.4, has automatic logging of job output built in
<slaskis> SpamapS: great, i'm working on upgrading my ubuntu now to get a newer upstart...
<SpamapS> slaskis: prior versions, you'll need to pipe output to something like logger, or to a file
<SpamapS> slaskis: heh.. precise is the only version that has this.. so be aware that you are upgrading to an alpha version of ubuntu. :)
<slaskis> SpamapS: i wasn't aware that precise existed until it upgraded to it
<slaskis> and being alpha explains why it doesn't start ;/
<SpamapS> slaskis: typically the best wway to do upgrades is 'do-release-upgrade', I presume you dist-upgraded after changing sources.list ?
<slaskis> i did do-release-upgrade
<SpamapS> ah
<SpamapS> and you're getting a fail to boot?
<slaskis> yeah, well unfortunately i followed this http://wiki.slicehost.com/doku.php?id=upgrade_ubuntu-server_lts_to_lts and since i kept getting "no new release" (although I knew that 10.04 was not the latest) i used --devel-release and got the alpha oneâ¦it's not the end of the world as i'm playing with a vm but still
<SpamapS> slaskis: would be very interested to hear how it is failing to boot.. now is the time to fix those bugs
<slaskis> SpamapS: it's this issue: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/936667
<slaskis> you don't happen to know how i can "add --no-log as a kernel option" ?
<SpamapS> slaskis: what kind of VM is this? on physical systems you add it at grub boot time
<slaskis> it's a linode instance
<slaskis> so, i guess kvm?
<slaskis> i managed to boot with "init=/bin/bash" 
<slaskis> where i don't get those logs 
<SpamapS> slaskis: ah, you can probably manually bring up the network and install an earlier version of upstart that doesn't have logging enabled
<SpamapS> slaskis: wait, if you can say 'init=/bin/bash' you can say, in the same place, --no-log
<slaskis> SpamapS: unfortunately not :/ it's a simple radio select in a web interface
<slaskis> options are "default run level", "single user mode" and "init=/bin/bash"
<SpamapS> slaskis: hrm.. you need upstart 1.4-0ubuntu6
<slaskis> SpamapS: ah, I have 1.4.0ubuntu8 now
<slaskis> how would i install an older version, doesn't seem like apt-get is usable in this console
<slaskis> "Unable to write to /var/cache/apt/" 
<SpamapS> slaskis: mount / -o remount,rw
<SpamapS> slaskis: make sure, before you exit your shell, that you 'mount / -o remount,ro'
<slaskis> SpamapS: ooh, it only mounts read only
<slaskis> thanks
<slaskis> ok, another noob question then :P how do i make apt-get find an older package? "apt-get install upstart=1.4.0ubuntu6" doesn't find that version (because it's not in the cache?)
<kklimonda> JanC: thanks, it looks like that I'be been looking for
#upstart 2012-02-22
<sveinse> I'm trying to get two services up and running on a Natty system and I have some dependency issues:
<sveinse> job 'a' is set to start on (local-filesystems and starting network). Its a task.
<sveinse> job 'b' is set to start on ( runlevel [2] and stopped a ), also a task. But it seems this job is never run.
<sveinse> Is there a problem using and statements like this for job b ?
<lucs> Hi.
<lucs> Does the upstart syntax support continuation lines, like with a \ at the end of a line?
<lucs> I could try it and see, but maybe I can avoid a reboot or two if I know whether it's supposed to work or not :)
<SpamapS> lucs: you don't have to reboot to run 'start jobname' ;)
<lucs> True, but I've had trouble fixing broken scripts in the past (required rebooting to get the machine in a clean state).
<lucs> SpamapS: By the way, do you happen to know if contiuations with \ are supported? :)
<SpamapS> do not know no
<lucs> Ah, okay.
<SpamapS> I would assume yes in side script/end_script
<lucs> I guess I'll just try it (but only later).
<JanC> lucs: line breaks are allowed within parentheses
<JanC> e.g. within parentheses in start on / stop on stanzas
<JanC> but AFAIK no "\" at the end of a line
<lucs> JanC: I was thinking within "script/end script", to make some of the longer lines easier to read.
<lucs> Oh well.
<JanC> ah
<JanC> lucs: that might work actually, if /bin/sh supports it?
<JanC> I'm not 100% sure how things get forwarded
<JanC> but the docs seem to indicate that everything between "script" and "end script" gets passed to /bin/sh
<lucs> JanC: Then I'm certainly going to try it :)
<lucs> Thanks.
#upstart 2012-02-23
<codebeake> hi all, is there a way to allow upstart jobs to be started multiple times? I have a daemon (Unicorn) which takes care of gracefully restarting, if you start it whilst it's already running, seems reasonable - but I can't find any relevant service stanza that would permit "multiple instances"
<plautrba_> codebeake: try init(5) - part Instances 
<codebeake> thanks plautrba_ :)
<codebeake> hrm, "task" stanza looks promising, but I'm afraid then the `respawn` et al wouldn't work as expected
<codebeake> (reading the section on instances below that, but the `task` was nice to find out about)
<codebeake> plautrba_: thanks for the suggestion, I don't want to pass variables, shame I can't shell out and see if the pid exists, already (and then start a differently identified instance)
<codebeake> It's also not possible to specify how to restart the task, right? They always receive the same signal, regardless
<SpamapS> codebeake: wait, why do you want to start the job/task multiple times?
<SpamapS> codebeake: re restarting, restart is always stop/start
<SpamapS> codebeake: reload is always SIGHUP
<SpamapS> codebeake: you can change the kill signal in newer versions of upstart with 'kill signal XXXXXX'
<codebeake> SpamapS, because Unicorn is a special case, where via it's configuration file you can add a block of code, which gracefully restarts
<codebeake> when sending the process URS2, then it gratefully restarts
<SpamapS> codebeake: right, thats why apache isn't upstartified either :)
<codebeake> I think my upstart version is too old, though - I'm on whatever ships with 10.10/10.4 Ubuntu
<codebeake> ah, ok - so I might want to look at regular init scripts
<SpamapS> codebeake: well for apache there's apachectl to do gracefuls, and then the upstart job would, in theory, just manage the boot/shutdown.
<SpamapS> codebeake: but yeah, simpler to just use an init script if there's already one
<greylurk> I'm writing an upstart script that is hanging when I try to call it.  How do I figure out where it's logging to?
<greylurk> it just sits at start/killed forever.
<codebeake> I wonder SpamapS, if it's worth making a restart scropt, that just checks for the pidfile, and signals that pid
<codebeake> I can chmod+xs it to my web application user
<codebeake> and use it in my deployments, then
<JanC> greylurk: jobs != scripts, so you can't "call" them  ;)
<JanC> and logging depends on the upstart version
<JanC> (there is some info about logging in the cookbook)
<JanC> codebeake: you can specify how to start/stop a service by using pre/post-start/stop instead of plain exec/script stanzas
<codebeake> JanC, thanks
<codebeake> the long and short is - that I need to be able to call start, since I don't want to replicate this logic, but I'll see what I can find
<codebeake> this is the unicorn behaviour - https://gist.github.com/5471a06ab93f192178c2
<codebeake> If I can find a way to do that in upstart, then I'm sorted
<JanC> http://upstart.ubuntu.com/cookbook/ --> has lots of useful info and tips & tricks
<codebeake> I'm stuck with an old version, alas
<codebeake> and I *know* I'll screw something up, if I try and upgrade a running production system's init system :)
<codebeake> 0.6.5, right now
<codebeake> (and when I USR2 it myself, upstart loses track of the pidâ¦ so, yeah - I think it might be time to find an alt. solution)
<codebeake> thanks for the help and advice
<codebeake> is it wise to do a source install of upstart, with a recent version on ubuntu 10.4 ?
<codebeake> â¦ I notice there's not a new enough version of libnih in apt to satisfy the 1.0 (at least) ./configure script, and I remember last time I tried to do this, it involved a trip down the rabithole
<greylurk> Is there any way to run "initctl start" with debugging info?  I have a script that's hanging at start/killed, but it works when I run the command from the command prompt.
<SpamapS> greylurk: initctl log-priority info
<SpamapS> greylurk: that will make init dump logs into syslog
<SpamapS> greylurk: you can make it spit even more info with 'initctl log-priority debug'
<greylurk> Thanks, it turned out that the init process was holding on to one specific pid, and wouldn't let it go even though the pid had died.  I ended up having to reboot but it's fine now.
<SpamapS> greylurk: thats a known bug when using 'expect fork' with a process that does not really fork
<SpamapS> greylurk: another workaround to rebooting is to write a program that forks a whole bunch of times until it hits the desired pid
<SpamapS> I really wish we could add an 'initctl forget job_name'
#upstart 2012-02-24
<jY> is there anyway to tell upstart to send a HUP signal to a process to restart?
<JanC> jY: why for restart instead of for reload?
<jY> JanC: i'm a upstart noob.. so i didn't know there was a reload
<JanC> jY: I was somewhat surprised; most people complain that right now "reload" can't use anything but SIGHUP  ;)
<jY> we'll i'm happy if it can only do that
<JanC> anyway, you can read about the available commands in 'man initctl'
<JanC> also, see the cookbook mentioned in the /topic for lots of useful info & tips
<lucs> Meep.
<lucs> Just wanted to confirm that yes, "\" at the end of lines in "script/end script" sections does get passed correctly to sh, and thus we can have continuation lines like that.
<SpamapS> lucs: thanks for investigating. :)
 * lucs is now a happy camper with his nice readable scripts :)
<JanC> SpamapS: it would have been a bug if it didn't work  ;)
<SpamapS> totally
<SpamapS> I'm a little incredulous that anything requiring \'s is "readable" .. but to each his own
<JanC> also depends on the language used, I suppose
<lucs> Example of my "\" usage: http://paste.scsys.co.uk/183832
<SpamapS> lucs: indeed, *that* is quite a bit more readable, and I hadn't thought about doing that.
<lucs> It makes code longer instead of wider, but like Steven Right, "I'm not afraid of heights, I'm afraid of widths." :)
<lucs> (explaining why he liked to walk his dog around the ledge of his apartment building)
<JanC> could also be useful with complex conditional statements in some languages
#upstart 2013-02-18
<SegFaultAX> I have an upstart script that seems to hang whenever I start or stop it. I've looked at numerous other examples and they are literally doing /exactly/ the same thing as me.
<SegFaultAX> It's basically `exec /opt/graphite/bin/carbon-cache.py --pidfile /var/run/graphite-server.pid start` + expect daemon.
<SegFaultAX> If the service is already stopped/waiting, it will always start cleanly the first time.
<SegFaultAX> If I try to stop the service though, it just hangs.
<SegFaultAX> And then trying to start/restart/stop the server hangs no matter what.
<afournier> did someone develop an upstart job to do sendsig job ?
<afournier> i am thinking about porting sendsig to a task as my system is sysvinit-free
<afournier> https://bugs.launchpad.net/upstart/+bug/750113
<afournier> ok
<xnox> SegFaultAX: after you start it does the pid from "ps" output match the pid from $ status jobname ?
<xnox> since the upstart script overrides STARTUP a few things are broken, e.g. the ssh-agent & consolekit ?!
<xnox> (yet we don't want dbus-launch either)
<xnox> stgraber: seems like we need to leave a marker if we are running under upstart.
<stgraber> xnox: yeah, I'll need to split the Xsession stuff again. Run a 00 that checks whether we need upstart, then override STARTUP at the end
<stgraber> that way we can check for upstart in any Xsession script and do the "right" thing (which will mostly be, nothing and let upstart start the software directly)
<xnox> stgraber: ok. in the mean time it means I should write gpg & ssh agent jobs, cause I'm sick of typing my password in.
<stgraber> hehe, yeah ;)
<xSmurf> hey all, I'm trying to setup a user script to launch some X program... I use env DISPLAY=:0 in the scrip to set the display but my program can never connect to it while running it from a shell works fine
<ajp> I'm trying to get my upstart script (http://pastebin.com/xjACPjk4) to work, it launches this script (http://pastebin.com/zUjJ9G8c) but when I reboot the server (12.04 headless) the script does not work. I had it working a few weeks ago. 
<ajp> anyone here?
<stgraber> ajp: the start/stop conditions are completely wrong
<stgraber> ajp: there's no such thing as a "network" job, so "started network" will never be emitted
<stgraber> ajp: "shutdown" only happens when init gets SIGPWR, so will only work in containers and for machines shut down by UPSses
<stgraber> you most likely want
<stgraber> "start on static-network-up"
<stgraber> "stop on starting rc RUNLEVEL=[016]"
<stgraber> that's also all assuming that /home isn't on a separate partition, otherwise you'll need to add something for that to the start condition
<ajp> I changed it to start on filesystem
<ajp> and ran initctl reload-configuration and it worked on reboot
#upstart 2013-02-19
<afournier> does upstart remembers its recipies ?
<afournier> i deleted a line in a job/task and it keeps executing it
<afournier> ah ok i needed to to stop/start not restart
<afournier> smart upstart
<xnox> yes.
<SpamapS> afournier: I recommend using the 'service' command for all interactions with upstart and sysvinit jobs. It does the more expected thing, rather than the more correct thing. ;)
<SpamapS> http://www.lsdlinux.org/ ... perhaps they might be interested in upstart? ;-)
#upstart 2013-02-21
<stgraber> xnox: so did you spend any more time on that qt theming issue? I'm poking at it now but don't want to duplicate debugging effort ;)
<tartar> Why would initctl emit mounting MOUNTPOINT=/blah fail?
<tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: + /sbin/initctl emit mounting MOUNTPOINT=/var/build/ramdisk 2013-02-21 15:14:45-05:00 1116 ramdisk: initctl: Event failed 2013-02-21 15:14:45-05:00 1116 ramdisk: EXITCODE=1
<tartar> Err
<tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: + /sbin/initctl emit mounting MOUNTPOINT=/var/build/ramdisk
<tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: initctl: Event failed
<tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: EXITCODE=1
<tartar> Ubuntu Lucid here
<tartar> Will looping till success work this around?
<tartar> (I saw few mounting hooks with same MOUNTPOINT coming to my block-dependants task.  I wonder if mountall already does the same work-around).
<xnox> tartar: I am sorry, but what are you trying to do?
<tartar> I am sticking centrify and couple more things early into the startup.
<xnox> mountall emits these events for all mountpoints in /lib/init/fstab as well as anything in your fstab.
<tartar> In particular, my ramdisk.conf simulates the mountall behavior by emitting a mounting hook
<tartar> I need my ramdisk to block until centrify is ready and for this I added a block-dependants task
<tartar> But I see that ramdisk's initctl emit fails to block returning the error above
<xnox> have you seen: http://upstart.ubuntu.com/cookbook/#block-another-job-until-yours-has-started
<xnox> emitting events will simply spawn more stuff to happen & get activated not less.
<tartar> Yup, that's where I got the block-dependants thing
<tartar> (BTW instance $JOB resulted in an error message saying that JOB did not exist.  Perhaps my Lucid upstart is too old for the cook book)
<tartar> I replaced that with instance mounting-$MOUNTPOINT
<tartar> Should better read as mountall-$MOUNTING as I expect that mountall emits mounting hooks, and $JOB would receive "mountall"
<tartar> err mountall-$MOUNTPOINT
<tartar> ...if I understand this correctly
<tartar> Actually now I see I went against the recipe by instantiating too many instances
<tartar> should my block-dependants task use "instance mountall"?
<tartar> I wish upstart clearly stated own mechanisms and those expected from other processes.
<tartar> For now the cook book reflects its name giving mostly recipes rather than architectural knowledge.
<tartar> To illustrate, the following phrase has unnecessary complications.  The change of the mode from educational to instructional and back brings confusion.
<tartar> "What you will find is that if you run the script above under /bin/sh, in all likelihood the file will never be created since regardless of whether you specify "-e" or not, the dash(1) shell (which /bin/sh is linked to on Ubuntu systems) has different semantics when it comes to sourcing compared with /bin/bash."
<tartar> I would steer away from giving any instruction in a text about a thing that I would need to understand.
<tartar> (I failed to understand the quoted phrase).
<tartar> Enough vitriolic ranting....
<tartar> The section block-another-job-until-yours-has-started assumes that the blocker task multiplies itself to block each job emitting one of the hooks.  Why?
<tartar> Can a single blocker task block all hook emitters?
<tartar> s/task/instance/
#upstart 2013-02-22
<SpamapS> tartar: start on starting will block *every* starting event... BUT, only while it transitions from stop/waiting to start/running
<SpamapS> tartar: so, the second starting event will not block, because the goal will now be 'start'
<tartar> hmm
<tartar> It would be nice if "start SERVICE" could give the status of the already starting or started job.
<tartar> It seems "start SERVICE" will say "already running" regardless of the status such as start/starting or start/running.
<tartar> Using "status SERVICE" before "start SERVICE" goes against possibility of an atomic check-vs-start.
<tartar> Ah, I should use the error code of "start SERVICE" and tell the difference between the starting and the running states by looking at "status SERVICE" on receiving a non-zero code.
<tartar>  
<SpamapS> tartar: I'd also question the use case. If you want it started, start just asserts that the goal will at least have been set to start once.
<SpamapS> tartar: so its more of an assertion "make sure its at least in a state trying to start"
<tartar> Thanks.
<tartar>  
<tartar> On an unrelated note, I love the rare occasions when pressing Ctrl-Alt-Delete brings up shell instead of rebooting a locked startup.
<tartar> I am not sure if this came as under-developed intent or by chance.
<tartar> Err. brings up the login prompt
<tartar> I wonder where can I read... It appears that "task" will return its starting hooks on completion of its script.  Does pre-start of a service block the service's "start on" hook in the same way?
<tartar> SpamapS: your comment about blocking starting events seems to imply yes.
<tartar> Yay, "6.32 task" confirms this.  "Without the 'task' keyword, the events that cause the job to start will be unblocked as soon as the job is started. This means the job has emitted a starting(7) event, run its pre-start, begun its script/exec, and post-start, and emitted its started(7) event."
<afournier> do a job that does an "start on starting job2" will run even if job2 fails to start ?
<afournier> i'd say yes
<afournier> but the real question would then be, does job2 will run even if the job fails
<SpamapS> afournier: a very easy thing to test. I believe the answer is yes
<afournier> yes
#upstart 2014-02-18
<k_art> how can I check if setuid, setgid works? executing from the shell works but upstart says: Permission denied
#upstart 2014-02-20
<Amadiro> Evening. Is there a way to configure upstart to be "more silent"? After booting my raspberry pi, and the splash screen is gone, I see a single ". ok" on the screen.
#upstart 2014-02-21
<afournier> hi there !
<afournier> i have an upstart for getty on ttyS0 but sometimes the machine the script is installed on does not have ttyS0 so the script is failing for ever respawning again and again. I set a respawn limit but nothing changes... init: ttyS0 main process (1555) terminated with status 1
<afournier> ideas are welcome :)
<jodh> afournier: use a pre-start to perform the checks on ttyS0 and call "stop;exit 0". See http://upstart.ubuntu.com/cookbook/#pre-start-example-debian-and-ubuntu-specific
<afournier> yay ! thanks :)
<Amadiro> Does anybody know how to configure upstart to be more silent or maybe output to a different tty? Right now I'm getting a single ". ok" on the screen, which renders on top of my beautiful plymouth splash screen :/
#upstart 2015-02-17
<agallego> can't figure out why i can't set bash vars inside upstart script: https://gist.github.com/senior7515/d2f832d0336ccaaf1b64 any tips ? took it from the hello world
<agallego> from here http://upstart.ubuntu.com/cookbook/#changing-the-default-shell
<abhi-> hi, I'm using upstart 1.12 on trusty, I can't seem to find any session jobs, initctl list-sessions lists nothing
#upstart 2015-02-18
<owend> Hello world.  I asked my question of cjwatson but he sent me here, so I'll try here...
<owend> Is there a way of finding out which events of an Upstart job's start on A and B clause the job has yet received?
<jodh> owend: The easiest thing to do is just enable verbose logging (http://upstart.ubuntu.com/cookbook/#obtaining-a-list-of-events) before the job starts. If that's not possible, there is a more precise way of establishing which events a job has already received, but note that this latter method isn't via a command - you can infact inspect upstarts inner state (assuming upstart 1.6.1+).
<cschneid> I have an upstart job that seems to track the pid correctly, but hangs when I do `service myjob start` and `service myjob stop` even though if I ctrl-c it has the right pid during a status call
<cschneid> This is the script & the behavior I'm seeing. https://gist.github.com/cschneid/4fb0757f7e71bf7cb745
<postmodern> what is the correct way to set a custom PATH for an upstart script?
#upstart 2015-02-19
<exobyte> is there any way to write a custom restart for a service job?
#upstart 2015-02-20
<kasisnu> Hi. So I'm trying to get a python script working with upstart as a daemon. I've run into the issue described here. http://askubuntu.com/questions/302514/upstart-job-fails-to-respawn-and-hangs-when-tried-to-stop-restart-it
<kasisnu> Upstart has the correct pid. When killed upstart fails to respawn the process.
#upstart 2015-02-21
<cetex> anyone have any idea what could be creating /etc/hosts during boot?
<cetex> i have created a pxe image that contains the entire root filesystem, i noticed today that /etc/hosts isn't in the actual image
<cetex> but is automagically there when the machine has booted.
<cetex> it's ubuntu 14.04.
<cetex> kinda annoying to not know ;)
#upstart 2017-02-20
<red-002> wow #devuan has a lot more people
<hallyn> meh, they don't consider upstart a valid contender?  
#upstart 2017-02-23
<afournier> hi
<afournier> i have a custom build linux distro, and it does not reboot, how can i know if it's an upstart problem (PID=1), or kernel problem ?
<afournier> i have been killing all services manually, and then calling reboot, it kills my console, but i don't know if PID=1 is still alive
<afournier> anyway, i think i found the problem (kernel related)
#upstart 2017-02-26
<princeso> systemctl status [TAB] <-- sends this error "Failed to issue method call: No such method 'ListUnits'". Any ideas?
<princeso> systemctl status syslog.service <--- says "Failed to issue method call: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/syslog_2eservice"
