#upstart 2007-06-25
* Starting logfile irclogs/upstart.log
<Shred01> hello all
<Shred01> i'm wondering how i can simulate events to test an upstart script i am writing.
<shawarma> Shred01: initctl emit <event>
<shawarma> Shred01: The initctl(8) man page is probably your friend.
<JK44> hi, here is my question :
<JK44> in the FAQ, it is said "will upstart replace DBUs " (because of the respawn feature)
<Keybuk> right ... (though it's nothing to do with the respawn feature)
<JK44> the answer is, "no but your software could directly tell upstart to restart program if they directly notice
<Keybuk> not correct
<JK44> oh ?
<Keybuk> the question is simply about activation of services, not about respawning them
<JK44> yes but if dbus that a setrvice is dead it respawn it
<JK44> so if i set upstart to respawn, and i use dbus to tell upstart to respawn (with command line) will it respawn soft twice 
<JK44> well it is another dumb question, if i tell upstart to respawn an active  program it does not restart it
<JK44> so it should be ok
<Keybuk> err
<Keybuk> sorry
<Keybuk> I don't understand your questions
<Keybuk> dbus isn't a service manager, so it doesn't respawn services
<Keybuk> it has some code to attempt to activate services in the user's session, but doesn't particularly deal with respawning, etc.
<JK44> if Dbus receive a message for an inactive service, it launch the defined command line for this service
<JK44> we use this feature as service respawning
<JK44> well we dont detect crashes
<Keybuk> yes, it does that
<JK44> but, its some kind of crash reactivation when needed
<JK44> i would like to keep using this feature
<JK44> and also the uspart respawning
<Keybuk> whereas upstart's respawning is based on processes dying
<Keybuk> in the theoretical Upstart+Dbus world, the "defined command line" would be instead "defined upstart service"
<JK44> so the command line in Dbus could be a call to upstart
<Keybuk> and dbus would send upstart a message to start a particular service
<JK44> exact
<JK44> but isn't a risk to have double restarts if the process dying detection and the dbus command line are executed concurrently ?
<JK44> for exemple : upstart detect a crashh and lose cpu
<JK44> dbus send his message
<JK44> the message is received, the service is activate
<Keybuk> dbus would send messages that affect upstart's state machine only
<Keybuk> upstart is very resilient to this kind of thing
<JK44> ok, so its totaly safe, its a great thing
<JK44> thk very much
<shawarma> Does it make sense at all to use upstart to call a regular init script for starting an stopping stuff or is it really only geared towards actual process supervision?
<Keybuk> I don't think it makes sense
<Keybuk> what's your use cas?
<Keybuk> +e
<shawarma> I'm just packaging some new stuff, and was about to install the symlinks in rc?.d, and thought how upstart was supposed to take over the world in this case.
<shawarma> When we want to ditch sysvrc, we need to completely rework each and every init script, I suppose.
<Keybuk> right
<shawarma> I just hadn't really thought a lot about that.
<Keybuk> we need only do them one at a time though
<shawarma> Well.. Yes, if we start with the low or high numbers and work our way up or down. We can't just cherry pick them?
<Keybuk> cherry picking is fine
<shawarma> If something used to be S30foo and is dependent on bar (S20bar) and baz (S40baz) is dependent on foo, how would we do foo in isolation?
<Keybuk> you would have to do bottom-up for "dependencies", yes
<Keybuk> but we have very few of those in reality outside of initscripts
<shawarma> True.
<Keybuk> the baz bit doesn't matter, since the runlevel stuff would be run after any upstart stuff
<shawarma> Right. That's why I said we should work our way either up or down the list. Not from the middle and outwards :)
<Keybuk> first thing is to get filesystem mounting converted and bullet-proof
<Keybuk> then the miscellaneous over things to do with block devices, and setting up the machine (hostname, etc.)
<Keybuk> after that, networking
<Keybuk> and then services from the bottom up
<shawarma> Right. That should cover pretty much everything.
<shawarma> I have a hunch that it just sounds daunting, but when we actually start doing it, it's not that bad. Most init scripts are already split into a lets-prepare-everything bit and a actually-start-the-bugger bit (and possibly lets-clean-up-the-mess-after-this bit)
<Keybuk> yeah
<Keybuk> indeed
<Keybuk> AGA : Q)EGTT/QFAXX/IV/NBO/A/000/999/5227N00145W005
<Keybuk>       FROM 07/04/30 07:19 TO 07/08/30 23:59               C1947/07
<Keybuk>       E)LARGE NUMBERS OF PIGEONS CROSSING RWY 15/33 ESE TO WNW 
<Keybuk>         FM THR 15 TO TWY K, SFC TO 100FT AGL, SR-SS.
<Keybuk> ^ rofl
<Keybuk> (momentarily off topic)
<shawarma> *G*
<shawarma> EGTT is Heathrow?
<Keybuk> yes
<Keybuk> ish
<Keybuk> EGTT is the London FIR
<Keybuk> EGLL is Heathrow itself
<Keybuk> that's a NOTAM for EGBB (Birmingham International)
<Shred01> does upstart in feisty emit events for old-style initscripts?
<Shred01> i.e. can i write a bona-fide upstart script and have it wait for an old-style initscript to be done starting?
#upstart 2007-06-26
<mbiebl> Shred01: No, that won't work.
<Shred01> is there any reason not to emit events for those old initscripts?  to help interfacing newer ones with older ones?
<mbiebl> Do you know, how the current sysv compat layer works?
<mbiebl> upstart basically has two jobs: rcS and rc-default (which by default runs rc2).
<mbiebl> These two jobs simply run /etc/init.d/rcS and /etc/init.d/rc 2
<mbiebl> If you wanted feedback from the old sysv initscripts, you'd either have to modify /etc/init.d/rc or the initscripts directly.
<mbiebl> And place corresponding "initctl emit $foo" call in their.
<mbiebl> s/their/there/
<Shred01> mbiebl: exactly.  i'd of course opt for modifying /etc/init.d/rc.
<mbiebl> I guess, the reason why it's not done, is simply that it is not really needed.
<mbiebl> Do you have any good use cases?
<mbiebl> And modifying /etc/init.d/rc won't address the problem, that you can start/stop services via /etc/init.d/$foo.
<mbiebl> So you'd have to modify all initscripts and add "initctl emit $foo $changed_status" everywhere.
<mbiebl> A lot of work that would be not worth the effort imho.
<Shred01> mbiebl: that is true.  i guess i am just looking from the "orderly starting of services" POV.  the use case is mythtv's existing mythtv-backend initscript.  i want to write an upstart script for myth's frontend (which is not included in the frontend package as an upstart or initscript) but it really can't start until the backend has started.
<mbiebl> You would write an upstart job for the backend first.
<mbiebl> Replace the initscripts from the bottom up.
<Shred01> sure, but then i have a one-of that i need to remember to keep replacing every time i get a mythbackend update.
<Shred01> i'm just being impatient i guess and not seeing the point to writing an initscript for mythfrontend vs. writing an upstart script for it.
<mbiebl> You could write an upstart job which runs at "start on stopped rc2"
<mbiebl> This means, it is started after runlevel has been started completely, which means, the mythtv backend should be running.
<Shred01> ahhh.  after all of the initscripts are run.
<Shred01> right.
<mbiebl> correct.
<Shred01> is upstart-for-everything supposed to happen in gutsy or post-gutsy?
<mbiebl> Shred01: I guess that not all services will be converted for gutsy but only the main ones.
<Shred01> cool enough i guess
#upstart 2007-06-27
<jk44> hi, i have noticed a possible bug in upstart
<jk44> i wrote this job :
<jk44> console output
<jk44> pre-start script
<jk44> 	echo "**UPSTART : ************* launching RCS ********** "
<jk44> end script
<jk44> script
<jk44> 	echo "avant exec"
<jk44> 	exec /etc/init.d/rcS
<jk44> 	echo "apres exec"
<jk44> end script
<jk44> post-start script
<jk44> 	echo "will try to launch runlevel 3"
<jk44> 	echo "done rlv 3"
<jk44> 
<jk44> 	echo "gona launch rcS"	
<jk44> end script
<jk44> and post start is executed before exec script
<Keybuk> incorrect
<Keybuk> post start is executed alongside the exec script
<jk44> ok, it explain what i get
<Keybuk> which wins is dependant on such matters as your kernel, and possibly the one that outputs first is running second, and it's the console buffer that's fooling you
<Keybuk> post-start makes most sense when the process run by exec is not immediately redy
<Keybuk> you can use the post-start script to poll the daemon until it's accepting connections
<Keybuk> the job won't be marked running until the post-start script exits
<jk44> ok, thk very much
<jk44> another dub question :
<jk44> when a job fail starting, how can i recover, (as it has not failed)
<jk44> and start the other jobs ?
<jk44> is "started failed or started"
<jk44> the solution ?
<jk44> i am trying that, but quite unsuccessfully
<Keybuk> start on stopped JOB failed
<Keybuk> the stopped event for the job will include the argument "failed", and will include arguments and environment saying what failed, etc.
<Keybuk> http://upstart.ubuntu.com/wiki/JobFailedEvent
<Keybuk> ^ see that
<Keybuk> e.g.
<Keybuk> stopped apache failed
<Keybuk>   EXIT_SIGNAL=SIGSEGV
<jk44> ok, sorry for bothering with such uninterresting question ^^, i had not very well understood the doc (poor english :s)
<Keybuk> that's ok
<Keybuk> the docs aren't great yet
<AlexExtreme> hmm
<AlexExtreme> this is weird
<Keybuk> hmm?
<AlexExtreme> i've got some native jobs written for LFS
<AlexExtreme> (just playing around)
<AlexExtreme> it boots fine
<AlexExtreme> apart from somewhere a bash syntax error gets printed
<AlexExtreme> it says the syntax error is in /dev/fd/7 every time
<AlexExtreme> i can't figure out why
<Keybuk> heh
<Keybuk> /dev/fd/7 is the name of the shell script upstart executes if it's > 1024k or so
<AlexExtreme> strange
<Keybuk> why?
<AlexExtreme> i have no job even 2kb
<Keybuk> that's a little more unusual
<Keybuk> oh, sorry, 1024 bytes
<Keybuk> not K
<Keybuk> I always do that
<Keybuk> 1K
<AlexExtreme> ah
<AlexExtreme> that limits it to 2 jobs
<Keybuk> (the /dev/fd thing is because upstart makes a pipe on which it arranges the script to be executed; and that's the trick to passing it to sh as a file)
<AlexExtreme> k
<AlexExtreme> the weird thing though, is that i get no "job failed" message from upstart
<Keybuk> passing it on "standard input" would mean the script couldn't use exec < or things like that
<Keybuk> and passing it in the arguments could exceed available space
<AlexExtreme> ah, got it
<AlexExtreme> stupid type
<AlexExtreme> *typo
<Keybuk> dunno why it doesn't fail
<Keybuk> maybe you've got a set +e in there?  or an ||/&&, or it's part of an if, etc.
<AlexExtreme> yeah, it was part of a ||
<AlexExtreme> now *that's* what i call optimization
<AlexExtreme> http://www.alex-smith.me.uk/files/bootchart-ud.png
<AlexExtreme> :D
<ion_> :-)
<tale> AlexExtreme, I'm not an upstart expert, but that distro wouldn't do much, right?
<AlexExtreme> the boot sequence does actually run more stuff, just it seems that bootchart missed some stuff
<AlexExtreme> currently it boots to a text-based multiuser system with networking and ssh
<tale> ah
<tale> what are some of the fastest boot times you guys are getting with the latest development code?
<AlexExtreme> that is the fastest boot i have ever got with any init system
<tale> but, what about a normal ubuntu install?
<AlexExtreme> i haven't tried with ubuntu, since i don't use it ;)
<tale> what distro do you use?
<tale> I assumed ubuntu since most distros don't use upstart
<AlexExtreme> frugalware atm
#upstart 2007-06-28
<wasabi> woh here i am
<Nafallo> hi! what's the current way to start a job in event.d? I'm using Ubuntu Gutsy
<Nafallo> found it
<Keybuk> "start" :-)
#upstart 2007-06-29
<j85wilson> /lusers
<j85wilson> whoops
<j85wilson> question: can any user on the system emit an event?  That is, is the only way to emit events by initctl emit (accessible only to root)?
<j85wilson> Also, I have read that events can be emitted when eg a file changes.  How do I set this up?
<Keybuk> currently only root can emit events
<Keybuk> there are no file change events at this time, but it is planned
<j85wilson> kk
<j85wilson> is that planned to change
<j85wilson> ok
#upstart 2009-06-22
* Keybuk changed the topic of #upstart to: Upstart 0.5.3 "Britain's Flag Carrier" | Upstart 0.3.11 "For Friday, June 19th 2009, I'm Jon Masters" | http://upstart.ubuntu.com/
<rikard> What's the problem if you get the following message in Upstart 0.5.0: "Unable to set root directory: No such file or directory" ?
<rikard> someone that could get me some help?
<rikard> plz
<Keybuk> rikard: usually it means that whatever path you've given to the chroot stanza does not exist
<ion_> keybuk: Good progress with 0.10? :-)
#upstart 2009-06-23
<sadmac2> Keybuk_: what's supposed to be in 0.6?
<Keybuk_> 0.5.3, plus a few fixes to the util/ stuff, plus some migration tools Debian want
<sadmac2> Keybuk_: hmm. almost doesn't seem worth a minor bump
<sadmac2> Keybuk_: side note, I've done the style cleanup on the state transfer patch. It still needs test cases though.
<Keybuk_> it's more of a statement of intent
<Keybuk_> 0.5 was tagged as a development series, while 0.3 was stable
<Keybuk_> calling it 0.6 means it can be labelled stable
<sadmac2> woohoo!
<sadmac2> Keybuk_: are we still on target for a 1.0/0.10 at LPC?
<Keybuk_> sadmac2: yes
<sadmac2> cool
<sadmac2> notting: petr should probably be in here
<Keybuk_> petr?
<plautrba> Keybuk_: yes
<Keybuk_> ah hi :-)
<sadmac2> Keybuk_: since I'm not a dev engineer anymore, petr will be the RHEL 6 Upstart maintainer
<Keybuk_> it was more of a "who is Petr?" kind of question, but you pretty much answered that :-)
<Keybuk_> plautrba: pleased to meet you!
<plautrba> Keybuk_: hi, nice to meet to too 
<plautrba> *you
<Keybuk_> RHEL 6 and Fedora?
<plautrba> for now it's for rhel6 but i would like to involve in fedora too
<sadmac2> plautrba: where are you out of? I don't think we even met.
<Keybuk_> sadmac2: you'll be still doing the Fedora packages?
<Keybuk_> when is RHEL 6 scheduled for? what kind of timeframe?
<sadmac2> Keybuk_: yes
<notting> Keybuk_: *cough*
<Keybuk_> notting: you can't say? :p
<Keybuk_> or you have no idea?
<plautrba> sadmac2: i am from brno
<sadmac2> plautrba: ah. cool
<notting> Keybuk_: the former
<plautrba> sadmac2: i'm sure we haven't met yet
<Keybuk_> I'd strongly prefer you were able to run 0.6 in RHEL 6
<Keybuk_> since that'll be the stable version that Ubuntu and Debian will also be using
<sadmac2> notting: ^^yeah, we need to look into this
<Keybuk_> and the version I'm trying to bribe SuSE into using
<Keybuk_> (instead of using 0.3 or 0.5)
<notting> Keybuk_: unlikely as it stands now, given the format changes
<Keybuk_> notting: 0.6 is basically compatible
<Keybuk_> it's me declaring the 0.5 version "better" than the 0.3 version, and fixing up the last few bits that aren't the same
<sadmac2> Keybuk_: you say it'll be compatible with 0.10. Does that mean 0.10 is keeping start/stop on?
<notting> ? 0.5 wasn't compatible with 0.3.
<Keybuk_> notting: it's mostly compatible, a few bits that aren't will be fixed for 0.6
<Keybuk_> sadmac2: 0.10 will read the 0.6 jobs, and apply some logic to making them work
<Keybuk_> sadmac2: I may simply still support "stop on" to allow easier transition
<sadmac2> Keybuk_: how will it know which one is which? folders? new job_version stanza?
<Keybuk_> sadmac2: 0.10 jobs use "while/on", 0.6 jobs use "start on"
<sadmac2> Keybuk_: either can use exec foo with no other info in the file
<notting> Keybuk_: including file locations, or is that a lost cause?
<Keybuk_> sadmac2: and both will behave the same way in that case
<sadmac2> notting: shouldn't be hard to make it support the old location as well as the new
<sadmac2> Keybuk_: true.
 * sadmac2 goes to feed himself
<Keybuk_> notting: I'd like to get everyone on broadly the same page
<ion_> keybuk: Karmic will get 0.6 instead of 0.10?
<notting> Keybuk_: what's your schedule?
<Keybuk_> ion_: Karmic will get 0.6, 0.10 is due for plumbers so that's "too late" for Karmic
<Keybuk_> and will go into Karmic+1
<Keybuk_> Debian will have 0.6 in unstable when it's released
<Keybuk_> and will move to 0.10 in September for squeeze (the next release)
<ion_> Ok. Will Karmic get a startup based on 0.6 (if thatâs even possible) or still sysvrc?
<Keybuk_> notting: 0.6.0 this week, 0.10.0 for plumbers
<Keybuk_> ion_: yes, partly
<notting> Keybuk_: if we don't actually use it for anything native beyond rcS... what does 0.6 buy me? :)
<Keybuk_> notting: support
<Keybuk_> cf. your recent crasher bug with 0.3.x
<Keybuk_> which already didn't effect 0.5
<ion_> How are you planning to support 0.6 jobs in 0.10? How about /{etc,lib}/init/$formatversion/ and have separate parsers for both trees (and yet another separate piece of code to yield 0.10-compatible jobs based on the 0.6 parserâs result) in order to not contaminate the 0.10 code with 0.6 stuff? Too idealistic? :-)
<ion_> One could then easily rid the codebase of 0.6 stuff in n years when nobody uses 0.6 anymore.
<Keybuk_> separate parser code is probably the easiest way
<sadmac2> Keybuk_: if you still have a directory change in mind, it might actually simplify things. Folder x for 0.6 jobs, folder y for 0.10
<ion_> /lib/init/0.6/jobs, /lib/init/0.10/jobs, /lib/init/42.0/jobs, or call the 0.6 format â0â, the 0.10 format â1â and the 42.0 format â2â and use /lib/init/{0,1,2}/jobs
<sadmac2> ion_: I don't think we're doing them in /lib
<sadmac2> Keybuk_: why do you have better candy in the UK?!
 * sadmac2 eats an aero bar
<Keybuk_> a not unreasonable idea might be just to have 0.6 jobs in /etc/event.d <g>
<Keybuk_> err
<Keybuk_> yeah I do mean that
<Keybuk_> sadmac2: you're in the UK?
<Keybuk_> ion_: you appear to have misspelled /etc
<ion_> keybuk: I thought the distro-supplied jobs were supposed to go to /lib and the user jobs or overrides to /etc at some point.
<sadmac2> Keybuk_: no. Friend found them at an import store.
<sadmac2> Keybuk_: but I now have one more reason to come.
<Keybuk_> ion_: no
<sadmac2> ion_: it never felt right to me. If anything I'd say distro jobs would go in /share, if there were such a thing.
<Keybuk_> jobs go in /etc
<Keybuk_> they're configuration files
<ion_> Alright
<soren> ion_: Perhaps you're thinking of udev rules?
<ion_> No
<sadmac2> soren: no, there was discussion of upstart keeping its config in /lib (the reasoning being that job definitions are "like udev rules"), but it was canned
<soren> ion_, sadmac2: Oh, I see.
 * soren crawls back under his rock
#upstart 2009-06-24
<ion> My user config files are under version control, and i have some default config files in a separate branch. I made a script that automatically updates the default config branch with latest versions of the respective files. Now iâll just need to run dotconfig-update-usptream && git merge upstream, and if a default config has changed due to a software update, the VCS merges those changes to my personal settings. :-) ...
<ion> ... http://github.com/ion1/dotconfig/blob/master/.local/bin/dotconfig-update-upstream
#upstart 2009-06-25
<johnflux> Hey all
<johnflux> I come in here every few months to check on the status of upstart
<johnflux> Any news on being able to see what services are running as a normal user?
<johnflux> I maintain the kde 'task manager' thing
<johnflux> and interested in having it show the currently running services
<johnflux> there were plans for being able to query this information via dbus.  Is this still be considered?
<johnflux> Could policykit be used for this instead?
<johnflux> The webpage says:
<johnflux> Features...# Communication with the init daemon over D-Bus
<johnflux> although I can't see anything upstart-like with qdbus
<johnflux> but perhaps because ubuntu uses 0.3.9
<johnflux> a search for "dbus" on the wiki returns zero matches
<mbiebl> Keybuk: reading the backlog: what will be the location for upstart job files for 0.6?
<mbiebl> and will a *.conf suffix be mandatory
<Keybuk> haven't quite decided yet ;)
<Keybuk> 0.3 uses /etc/event.d/*
<Keybuk> 0.5 uses /etc/init/jobs.d/*
<Keybuk> 0.10 will use /etc/init/*.conf
<mbiebl> if we want to ship 0.6 in Debian/Ubuntu, I'm wondering if we should keep /etc/event.d for 0.6 or go to /etc/init/*.conf directly
<mbiebl> to not clutter our maintainer scripts unnecessarily
<mbiebl> Keybuk: been watching your presentation for fosdem
<Keybuk> right, it's an interesting decision
<Keybuk> if we go with /etc/event.d - it's a bit more compatible with 0.3 (assuming the jobs work unmodified)
<Keybuk> but that leaves the people using 0.5 out in the cold
<Keybuk> if we're not quite compatible with either, we may as well just go straight to /etc/init/*.conf and make sure 0.10 is backwards compatible
<mbiebl> and I'm not sure if I like the idea of having "while dbus and hal" in a job called foo, make those service be started automatically
<mbiebl> when I run "start foo"
<Keybuk> really, why not?  if you want foo running, you want it running ;)
<sadmac2> mbiebl: upstart doesn't have such an idea
<sadmac2> mbiebl: dbus and hal will start foo. starting foo without dbus and hal just bitches about not having dbus and hal
<Keybuk> sadmac2: not true, in 0.10 starting foo will start dbus and hal
<mbiebl> sadmac2: that's not how I understood the presentation
<sadmac2> Keybuk: that's not particularly event-driven...
<mbiebl> Keybuk: I'd say, if I run "start foo", upstart should simply ignore the "dependencies"
<Keybuk> sadmac2: nor is having a "start" command in the first place
<mbiebl> or at least provide a switch, which allows that
<sadmac2> Keybuk: true
<Keybuk> sadmac2: which is all we're talking about here; there's no facility for foo to be automatically started and cause dbus/hal to be started
<sadmac2> Keybuk: so if I have when file-exists /etc/foo.conf will doing start foo create foo.conf ? :P
<Keybuk> sadmac2: no, that will fail ;)
<Keybuk> mbiebl: you need to know which dbus and hal to be associated with
<Keybuk> mbiebl: since you need to resolve which instance of foo to start
<Keybuk> mbiebl: you can obviously create a new foo instance and start that - without its dependencies
<sadmac2> Keybuk: that won't always make sense. Starting metacity without its X dependency doesn't really make sense
<Keybuk> sadmac2: that's generally been my thought too
<sadmac2> Keybuk: we need to adjust that semantics draft I wrote to reflect that. Right now it doesn't allow an instance to exist without its dependencies.
<Keybuk> sadmac2: I've always envisioned that you can force creation of an instance without its dependencies
<Keybuk> and that in that situation, it's up to you to provide the necessary environment that would otherwise come from them
<Keybuk> obviously such an instance would never be automatically stopped
<mbiebl> Keybuk: I think we need the ability to start a job while ignoring it's dependencies
<sadmac2> Keybuk: its an ugly thing to do but it can be possible
<Keybuk> mbiebl: I don't think it should be the default behaviour though
<sadmac2> Keybuk: I've also wondered about having a softer mode of dependencies (not all services have to be restarted if they lose a dependency, so long as the dependency comes back in a reasonable time frame)
<mbiebl> I'll try to put my thoughts, why we need it into an email an send it to the debian initscripts list
<Keybuk> upstart-devel better surely?
<sadmac2> mbiebl: ^^what he said
<Keybuk> sadmac2: seems reasonable
<sadmac2> Keybuk: you want a fun challenge, figure out how to manage ypbind :)
<Keybuk> sadmac2: I don't know what that is
<mbiebl> Keybuk: the main reason, why I want this, is to make upstart-job work properly
<mbiebl> which will be Debian/Ubuntu specific
<sadmac2> Keybuk: NIS. Its abysmally built. Figuring out whether its actually running and doing what it should is a quantum uncertainty problem
<sadmac2> Keybuk: It'll start, say "ok" and then just be sitting there not responding to requests
<Keybuk> post-start exec sleep 10
<sadmac2> Keybuk: not for an interval
<sadmac2> Keybuk: permanently
<sadmac2> Keybuk: if it doesn't find a server or something it just idles
<sadmac2> Keybuk: and never recovers
<Keybuk> sounds like you need monit or something to test it
 * Keybuk wishes bzr had a "bundle working changes" command
<Keybuk> quest util% ./initctl start --no-wait slow-starter
<Keybuk> slow-starter start/pre-start, process 7425
<Keybuk> yay
<Keybuk> --no-wait works again
<Keybuk> interestingly, to get the goal, state and process list is three d-bus property requests
<Keybuk> which means things can change between them
<Keybuk> (implemented GetAll :p)
<ion> :-)
<wasabi> hi long time no seen
<ion> Howdy
#upstart 2009-06-26
<ion> http://github.com/ion1/vim-highlight Output syntax-highlighted HTML version of input using Vim
<ion> (There are syntax highlighters for a huge amount of formats in Vim)
<Keybuk> ion: we could do with one for Upstart jobs ;)
<johnflux> hello?
<johnflux> the channel is very quiet :-)
<johnflux> anyone around?
<Keybuk> hello!
<johnflux> :-)
<johnflux> Keybuk, just wondering if dbus support has been added yet
<Keybuk> yes, that was added in 0.5.0
<johnflux> the front webpage says it has, but there's no mention on the wiki on using it, and I can't find it running "qdbus --system"
<johnflux> ah
<Keybuk> many distributions still use 0.3.x though
<johnflux> yeah
<johnflux> that explains why I don't have it in ubuntu
<johnflux> so..  does this mean that as a normal user I can see what services are running?@
<Keybuk> correct
<Keybuk> though that is also true of 0.5
<johnflux> can I map it to a PID?
<Keybuk> which limits method calls to root only
<johnflux> even dbus calls are limited to root only?
<Keybuk> yes
<Keybuk> though it's possible that 0.6 may open up the "status information" calls
<johnflux> hmm - can I use policykit or something to get permissions to use it?
<johnflux> without having to prompt the user each time
<Keybuk> since they're done through the Properties interface now
<Keybuk> PK support is somewhere on the wishlist
<johnflux> I'm the maintainer of the 'task manager' thing in kde
<johnflux> so it shows the list of running processes
<johnflux> it would be nice to also show the list of running services
<johnflux> and to map between them
<johnflux> so that when you right click on the apache process, you could kill it properly, rather than sending a signal
<Keybuk> *nods*
<Keybuk> tell you what, after a few seconds thought, I'll definitely agree that the properties interface will be public
<Keybuk> plus the "Get" interfaces
<Keybuk> since most of that detail shows up with Introspection anyway ;)
 * johnflux nods
<Keybuk> the root-only methods will be
<johnflux> in particular I want to be able to get the pid
<johnflux> would that be possible?
<Keybuk>   com.ubuntu.Upstart.ReloadConfiguration
<Keybuk>   com.ubuntu.Upstart.EmitEvent
<Keybuk>   com.ubuntu.Upstart.Job.Start
<Keybuk>   com.ubuntu.Upstart.Job.Stop
<Keybuk>   com.ubuntu.Upstart.Job.Restart
<Keybuk>   com.ubuntu.Upstart.Instance.Start
<Keybuk>   com.ubuntu.Upstart.Instance.Stop
<Keybuk>   com.ubuntu.Upstart.Instance.Restart
<Keybuk>   org.freedesktop.DBus.Properties.Set
<Keybuk> and the public methods will be
<Keybuk>   com.ubuntu.Upstart.GetJobByName
<Keybuk>   com.ubuntu.Upstart.GetAllJobs
<Keybuk>   com.ubuntu.Upstart.Job.GetInstance
<Keybuk>   com.ubuntu.Upstart.Job.GetInstanceByName
<Keybuk>   com.ubuntu.Upstart.Job.GetAllInstances
<Keybuk>   org.freedesktop.DBus.Properties.Get
<Keybuk>   org.freedesktop.DBus.Properties.GetAll
<Keybuk>   org.freedesktop.DBus.Introspectable.Introspect
<johnflux> .GetInstanceByPid  ? :-) 
<Keybuk> does that sounds reasonable?
<johnflux> it does
<Keybuk> johnflux: believe it or not, there's no such lookup path in Upstart ;-)
<Keybuk> johnflux: though you're right - there should be - could you file a wishlist bug for that one
<johnflux> Keybuk, right, I was hinting at adding it :-)
<Keybuk> also can you file a wishlist bug for changing the D-Bus conf - pasting the above ;)
<johnflux> what's the url for this bug reporter?
<Keybuk> http://bugs.launchpad.net/upstart
<johnflux> Keybuk, would i want getJobByPid   or GetInstanceByPid  ?
<johnflux> instance?  both?
<johnflux> I don't get the difference between instance and job
<Keybuk> both technically
<Keybuk> arguably that should return Job, Instance and Process
<Keybuk> com.ubuntu.Upstart.LookupPid (Int32 pid) => (ObjectPath job, ObjectPath instance, String process)
<johnflux> Keybuk, that's a suggestion for a new call?
<johnflux> Keybuk, can a job/instance have an icon?
<johnflux> for prettiness
<Keybuk> icons are pretty much left to front-end implementation to decide for now ;)
<Keybuk> it wouldn't be much to add an icon stanza like description and author
<Keybuk> feel free to add a wishlist bug ;)
<Keybuk> johnflux: right, given com.ubuntu.Upstart.LookupPid (1234) you'd expect a reply like
<Keybuk>   ( "/com/ubuntu/Upstart/jobs/test", "/com/ubuntu/Upstart/jobs/test/_", "pre-start" )
<Keybuk> ie. it says that pid 1234 is the pre-start process of the default instance of the test job
<johnflux> https://bugs.launchpad.net/upstart/+bug/392500
<johnflux> I can't work out how to make it a wish
<johnflux> it didn't ask me
<Keybuk> I can do that
<johnflux> thanks
<johnflux> https://bugs.launchpad.net/upstart/+bug/392502
<johnflux> Keybuk, the other one
<johnflux> Keybuk, I'm looking forward to making kde integrate nicely with upstart
<johnflux> it could all come together in such a slick way
<johnflux> Keybuk, do you know the status of other major distributions and upstart? 
<johnflux> Keybuk, redhat, suse etc
<Keybuk> johnflux: feel free to add a wishlist for icon support as well
<Keybuk> Fedora are using Upstart 0.3.x currently
<Keybuk> I'm hoping they'll use 0.6.0 when it's released
<Keybuk> Ubuntu is using 0.3.x and will use 0.6.0 when it's released
<Keybuk> we had a productive discussion with Debian this week, and it's favourable for Debian to use 0.6.0 when it's released
<Keybuk> I understand that RedHat will ship Upstart with RHEL 6, but not sure which version
<Keybuk> a SuSE maintainer is pushing for adoption there
<Keybuk> the only trouble with doing unit tests is you end up spending a day catching up on testing every time you write new code :-/
<sadmac2> Keybuk: yeah.. its fun
<Keybuk> of course, that's better than spending a week hunting down bugs you introduced
<wasabi> Nothing to do with the conversation, but I find it interesting... sometimes unit tests aren't appropriate for just that reason.
<sadmac2> Keybuk: lazy programmers write fewer bugs, but the industrious ones have less trouble finding them. Its cruel really.
#upstart 2009-06-28
<A2C2A> is it possible to "interrupt" upstart's init sequence in such a way that you get to choose whether to start or skip starting each service? if you're familiar with Gentoo's init, what I'm after is what happens when you press i during init.
<ion> How would that be useful?
<A2C2A> for debugging 
<A2C2A> it has been invaluable for me while creating various gentoo-based mini-distros
<A2C2A> I guess that means this is not possible in upstart?
<JamesB192> A2C2A: and you can't sit baselayout atop upstart why? it's not a feature of sysvinit either.
<JamesB192> sysvinit is told basily to just call rc on runlevel changes, I had an upstart job that did the same thing until I switched my box back to sysv, and I don't remember what I did w/ the ebuild for upstart. 'man inittab' and 'nano /etc/inittab' are probably your friends. substitute the editor/pager? of your choice for nano.
<mbiebl> A2C2A: Keybuk expressed interest in such an "interactive" mode
<mbiebl> but upstart currently doesn't have support for that natively
#upstart 2010-06-28
<crankharder> why is this config starting multiple processes of god initially, and then within a few seconds it's down to two of them that won't go away: http://pastie.org/1021409
<crankharder> if I comment out the exec/respawn lines then god never gets started
<crankharder> all these commands are within a few seconds: http://pastie.org/1021413
<crankharder> for some reason it killed all but one this time
<ion> Hi Keybuk
<ion> Working hard on 0.10? :-)
<Keybuk> it consumes my every waking moment :p
<crankharder> anyone have any insight into this weirdness? https://answers.launchpad.net/upstart/+question/115996
<Keybuk> crankharder: I would guess that "god" forks multiple instances by itself
<Keybuk> or is a daemonising process (so upstart sees the daemonisation as it existing badly)
<crankharder> well, 1) i dont think god forks itself 2) it doesn't do it if I execute the command manually 3) respawn on it is broken, if I kill all the processes it doesn't restart
<crankharder> "do it" == start multiple processes
<crankharder> also, weirdness like this:
<crankharder> $ sudo stop god
<crankharder> stop: Unknown instance: 
<Keybuk> that to me really implies that god forks
<sadmac> Keybuk: well yeah. Jesus.
<crankharder> are there repercussions if I add expect fork and expect daemon and god doesn't actually fork/daemonize something?
<crankharder> ...well, it works as expected w/ those added
<mgoetze> Keybuk: is there any chance of an ubuntu developer working on randomly nonstarting services on 10.04? at work we are still installing 8.04 on customer systems due to this bug...
<Keybuk> you'd have to ask your support contact about that
<mgoetze> my employer is too cheap to pay canonical for support :)
<Keybuk> I don't know of any bugs affecting large numbers of users in 8.04
<Keybuk> so if you do have an issue, it is probably specific to your configuration
<mgoetze> the bug is in 10.04, LP#543506 and co.
<Keybuk> sorry I mean 10.04
<Keybuk> isn't that the bug where /dev/console isn't available?
<mgoetze> yes i think that's part of the problem
<Keybuk> (well, the node exists, but opening fails)
<Keybuk> right, the cause of that bug hasn't been found yet
<Keybuk> and reading through the comments, multiple ubuntu developers are participating in the triage process
<mgoetze> alright ... i don't really know which ones are ubuntu devs and which aren't of course :) well thanks for having a look
<mgoetze> maybe i'll see whether i can reproduce it with a different kernel
#upstart 2010-06-29
<pepsiman> My computer sometimes hangs during shutdown, looking at the mythtv-backend logs for when this happened this morning, it appears that mysqld was stopped before mythtv-backend - start of a very long log: http://mythtv.pastebin.com/hdUT4nmp .  Can the shutdown order be controlled with upstart?  How can I debug the shutdown process?
#upstart 2010-06-30
<twb> How can I trace upstart events during boot?
<twb> For some reason most of /var/lib is being deleted when I have my ramdisk mount a read-only NFS root filesystem and aufs-merge it with a tmpfs cow -- but if I first bind the cow so that it's also visible after the pivot_root, the problem goes away.  And I can't see anything in the ramdisk's code (casper) that looks culpable, so I'm trying to follow execution of <stuff> by init, which (this being Ubuntu 10.04) is upsta
<twb> rt.
<rapha> Hi all!
<rapha> after rm rf'ing my /etc and trying to fix everything again i almost got it, besides: http://pastie.org/1025284 - do you have any idea what i'm still missing?
<ion> The backups
<ion> and /etc/init/mysql.conf probably
#upstart 2010-07-02
<_vadim> Hi! I'm working on an automatic install system. I have VMs that automatically get installed from the network. Once the install is done, I need to run a script after the first reboot. It must run to completion before any logins are allowed or X is started. How do I do that?
<Stevee> hello, just a question is the upstart development process still continuing ? because the last version was released in april and the last patch for ubuntu at early may - almost 2 month ago...
<Md> Stevee: yes, it is
<Stevee> many thanks, it is - because there are any news or commits
<Stevee> it seams like the project is sleeping or dead
<Md> there are definitely plans, but new code tends to appear in bursts
<Stevee> nice to hear about that
<ion> AFAIU, Keybuk is working on 0.10 fulltime.
<Stevee> oh, on the next version - great
<Stevee> thanks man
#upstart 2010-07-04
<Kurogane> anyone know how i can enter in console mode when i'm booting?
#upstart 2011-06-27
<Marco> Hi
<Marco> if I'm writing an upstart script, will environment variables changes I make persist after the script runs?  
<JanC> Marco: does http://upstart.ubuntu.com/cookbook/#environment-variables answer your question?  (especially the part just before 7.2.1)
<Dirus> I'm trying to make a quick change to some upstart scripts, do I need to rerun some sort of preprocessor before the requires etc changes are recongonized?
<Dirus> *recognized
#upstart 2011-06-29
<bderrly> hey folks, i'm working on a config and seem to have hit a problem i can't fix
<bderrly> the service started fine and logged the pid, but failed not long after
<bderrly> upstart still thinks the process is blah even after multiple 'service blah stop' calls
<bderrly> and restart etc
<bderrly> how can i get upstart to "forget" what it thinks the pid is?
<bderrly> i just tried running start on it and hte status is "start/killed, process 9385"
<bderrly> the service start command never exited, i eventually sent it a sigint
<bderrly> if i run the exec line from the config directly on the console it runs fine and stays running
<AzzA> im not bery good with upstart, but i need to run a script as root
#upstart 2011-06-30
<guufy> hi
<guufy> i have one service that "start on started anotherone"
<guufy> and if i do initclt list, it says that my service is in stop/waiting, and anotherone is in start/post-start, (post-start) process 193
<guufy> does it mean that the post-start script hasn't returned yet?
#upstart 2011-07-01
<hetii> Hello :)
<hetii> Q: is it possible by upstart to display some message that will come from post-start script ?
#upstart 2012-06-25
<fAz4> i've placed my test.conf files in /etc/init/
<fAz4> and i have to call "start test" every time my server is up
<fAz4> is it anyway to make it auto ?
<lnykryn> fAz4: specify start on
<fAz4> lnykryn: it's "start on startup"
<fAz4> in my .conf file
<lnykryn> this should be enough
<fAz4> lnykryn: it's my script   http://paste.ubuntu.com/1058929/
<ion> on startup, / hasnât been mounted rw yet, the networking isnât up etc.
<ion> Ubuntu? Try start on runlevel [2345]
<fAz4> ion: yeah
<fAz4> ion: thanks dude
<fAz4> ion: that was the issue
<fAz4> should i say  "stop on runlevel [!2345]"
#upstart 2012-06-26
<upstart-event> Hello all, can anyone refer me to a document which describes keyboard events. For example, when I press CTRL+9 , i want to emit an event. How do I do that?
#upstart 2012-06-27
<xnox> http://paste.ubuntu.com/1062218/
<xnox> can we please make upstart through warnings if start-stop-daemon is used in the upstart job
<SpamapS> xnox: we recommend start-stop-daemon for switching users, so I don't think that would make much sense. ;)
<xnox> SpamapS: yeah, especially in the ubuntu package, in the archive!
<SpamapS> xnox: whats wrong with that job?
<xnox> SpamapS: nothing wrong, it's just not upstartish
<SpamapS> if you need to run pre-start's as root, you can't use setuid/setgid
<SpamapS> you have to have something to switch user ids
<SpamapS> I'm kind of surprised mongod doesn't have a --user argument tho
<xnox> ok
<SpamapS> xnox: http://upstart.ubuntu.com/cookbook/#changing-user
<wavded> does upstart make sure a process is terminated?  seems there are cases when it lingers around, wondering how to tune it
<annath> Hey all, I have a wierd issue with a small service I've written using python. I'm using upstart to run it as a service. When the script runs as an upstart service, any calls to time functions (localtime, strftime, etc) come back in GMT. This doesn't happen if I just run the script on its own. Is there any way to fix this? I can't find anything on google relating to upstart and time.
#upstart 2012-06-28
<stiang> How can I convince upstart that "no, there is no process 26428 anymore, please start solr even if you think it is still running"?
<pdtpatr1ck> Question - upstart returns 0 whether the app is running or stopped. I've read many bug reports and the back and forth, haven't seen any solution 
<SpamapS> pdtpatr1ck: upstart *prints* the actual status
<JanC> an option to return a status might be useful though
<JanC> e.g. in scripts
<SpamapS> JanC: I agree
<SpamapS> JanC: I believe there is also a feature request to have something like --oknodo for start/stop
<SpamapS> JanC: so that you can just say 'start --ok-no-do foo' and then it will just make sure foo is started, not that it changed from stop->start
<SpamapS> JanC: given that, status would become less relevant in scripting
<JanC> depends
<JanC> that isn't useful if you want to be sure it's not running  ;)
<JanC> or if you just want to do something different based on that status
<SpamapS> JanC: stop --oknodo is the same thing
<SpamapS> JanC: if its stopped, you return 0. If you move from start->stop, you return 0. You only return 1 if there's an error.
<SpamapS> JanC: for the other cases, parsing status is fine
<JanC> parsing is always prone to errors (unless the output is guaranteed never to change)
<JanC> and you do not always want to change the started/stopped status
<SpamapS> the output is guaranteed never to change
<SpamapS> goal/state is set in stone
<SpamapS> JanC: we agree, but there are two things.. goal and state.. and status's return code cannot possibly handle all of the combinations of those sanely.
<JanC> SpamapS: let's say I feel more comfortable with separate output for machines & humans...   ;)
<SpamapS> JanC: what would you have status do then? 0 only for start/running, 1 for all others?
<JanC> even if the output would be printed to stdout or stderr, or whatever mechanism is used, there should probably be a difference between output for humans and for computers
<JanC> and both should be optimized for their purpose
<SpamapS> JanC: $jobname[space]$goal/$state is pretty darn easy to parse for human and machine
<SpamapS> JanC: no probably, show me the money. I want to know how you envision it. :)
<JanC> that's already not going to work...
<JanC> e.g. "network-interface-security (network-manager) start/running"
<JanC> or "tty6 start/running, process 1811"
<JanC> (well, that's with list output, but you don't always know the exact thing to query without parsing that)
<JanC> and maybe not even by parsing that  ;)
<JanC> also, sometimes an PID is added, sometimes not
<JanC> and maybe in the future other things will be added
#upstart 2012-06-29
<SpamapS> JanC: if things are added that will be weighed heavily, but you still have not said how it should work, only how it shouldnt
#upstart 2012-07-01
<steffen_b> hi 
<steffen_b> i have a question about ubuntu's wait-for-state job 
<steffen_b> anyone ever used it ?
<steffen_b> its starting or stopping the job it is waiting for - thats , lets say unexpected
<wmp> hello, i have problem with upstart and shutdown my conteneir on vserver
<wmp> http://wklej.org/id/782802/ - this problem
#upstart 2013-06-24
<xnox> slangasek: one 2 one mapping between "lsb Provides: " stanza and upstart job name, or between initscript name and upstart job name, or both?
<xnox> e.g. I see Required-Start: mountall & Provides: mountall in the initscripts on debian....
<xnox> nevermind me, it uses file names to build up dependencies.
<slangasek> xnox: right - the provides are only used internally within insserv, but the generated dependencies are based on expanded real scripts
<xnox> slangasek: which is a shame =(
<slangasek> why?
<xnox> slangasek: there would be no need for /etc/init/mountall.sh.conf /etc/init/hostname.sh.conf in debian if purely "Provides" names would be looked up.
<xnox> and used.
<slangasek> xnox: yeah... except then there would be header parsing at boot time :)
<xnox> =)))))))) which is like really fast, right?! =)))))
#upstart 2013-06-25
<Md> I am trying to debug an ubuntu 10.04 system which hangs at boot. If look at what upstart is doing in a different console I see that it started a few processes but I am left with only plymouth running
<Md> what can I do to find out what's wrong?
<jodh> Md: take a look at http://upstart.ubuntu.com/cookbook/#debugging.
<jodh> Md: first, I'd try booting with --debug on the kernel command-line and capturing the log output to see if anything looks suspicious.
<jodh> Md: have you installed any new jobs recently or changed any default jobs maybe?
<Md> jodh: this is a customer server and I have no idea if and how they broke it
<Md> the problem does not appear to be a job hanging, unless it's plymouth itself
<Md> I already checked the log with --verbose
<jodh> Md: do you know if this server has ever booted successfully?
<Md> jodh: yes, it was working until it was rebooted (or crashed, who knows)
<Md> I can see that the only jobs started are plymouth, hwclock, ureadahead and hostname
<Md> the only possibly suspicious message is two "ignored event 40 (1) for process ..." messages
<Md> where the process is plymouth
<jodh> Md: this will list missing standard jobs: http://paste.ubuntu.com/5798845/
<jodh> Md: this will list modified jobs: http://paste.ubuntu.com/5798853/
<jodh> Md: look at the newest files in /etc/init/ and try to identify any new jobs which might be causing problems.
<whg> Is there any sort of "best practice" around managing Python processes inside a virtualenv?
<Md> there are no new files
<whg> Can I source scripts in shell script I'm running under upstart?
<Md> no missing files, no modified files
<jodh> whg: I suggest you read the Cookbook: http://upstart.ubuntu.com/cookbook/#sourcing-files
<whg> Dammit
<whg> I swear I searched the cookbook for that
<whg> Thanks for the link.
<jodh> whg: np.
<jodh> Md: any new jobs? If not, has /etc/fstab been modified? are all expected disks mounted?
<Md> no new jobs, only one disk
<jodh> Md: I think we'll need to see the output from --verbose/--debug then.
<Md> jodh: http://www.bofh.it/~md/u/
<jodh> Md: looks like mountall might be the problem. Look for any odd lines/options in /etc/fstab.
<Md> there is nothing unusual, the file is trivial
<Md> if I run "initctl start upstart" it mounts / rw
<Md> I mean "initctl start udev"
<jodh> Md: well, from the files you've provided, it doesn't appear that mountall gets as far as spawning.
<jodh> Md: mountall is supposed to do that
<Md> yes, so what should start mountall?
<Md> if I try to start it manually I get a "Job failed to start" error
<Md> got it
<Md> the problema was a syntax error in /etc/default/locale, which was over one year old
<Md> can you make sure that a || true is added to mountall in the next release? :-)
<JanC> Md: you mean when sourcing /etc/default/locale ?
<Md> JanC: yes
<Md> there are still some issues BTW, only some services have been started
<Md> I can start them manually, but I have no clue why upstart is not starting them
<JanC> considering that that file might get changed on many systems, and admins are humans, so make errors, maybe that wouldn't be a bad idea  :)
<Md> nevermind, this one looks like a fuckup by a coworker
<slangasek> Md: ah, that bug was just recently reported, https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1192514
<slangasek> wonder why everyone has invalid /etc/default/locale all of a sudden :P
<Md> there was no error message either at boot time or when starting mountall manuall BTW
<slangasek> yes; job output handling only became sensible much later (13.04, I think?)
<JanC> maybe upstart needs a library of functions that provides "best practice" methods for common tasks in upstart jobs...
<JanC> (that also means they can be fixed centrally if they aren't really best practice ;) )
<xnox> JanC: nah, ideally daemons/software is capable of running with just a single exec line.
<xnox> JanC: without need of any scripts at all.
<xnox> JanC: plus we have http://upstart.ubuntu.com/cookbook/ already.
<xnox> JanC: problem with "helper" libraries is that they quickly gain feature creep trying to accommodate every use case.
<JanC> xnox: ideally, all programs would be bugless  :p
<xnox> JanC: please no, otherwise I'd be out of work :P
<JanC> you can always write new bug-free software  :)
<JanC> and to avoid too much feature creep, you just need a good gatekeeper  ;)
#upstart 2013-06-26
<slangasek> jodh, xnox: hi, so I assume you've seen these build failures on trunk and that someone's working on sorting them out?
<xnox> slangasek: that one needs a fix in lp:ubuntu/upstart
<xnox> yeah, it was fixed for distcheck target, but not in the ubuntu-branch compile.
<slangasek> ok - so is that something we wait to fix until we're released and ready to upload to saucy?
<jodh> the test_libupstart failure looks like it's a no-dbus-in-chroot issue.
<xnox> slangasek: pushed a fix, and requested a new ppa build.
<slangasek> xnox: cool, thanks
<xnox> slangasek: well at the moment I think everything is ready for 1.9 upstream release, but then further work will be needed to merge up 1.9 into lp:ubuntu/upstart.
<slangasek> ack
<xnox> that later will also require additional patches from mdsleur
<jodh> xnox: your fix is for the abi-check right? we may as well resolve the dbus/chroot issue before putting a release out tomorrow I think.
<xnox> jodh: what's the issue around dbus/chroot?
<xnox> jodh: if something needs dbus, simply wrap the whole command/environment with "dbus-launch -- " and that's it.
<jodh> xnox: I thought we were all taking about: https://launchpadlibrarian.net/143474336/buildlog_ubuntu-raring-amd64.upstart_1.8%2Bdaily%2B1489%2B1444%2B201306261447~raring1_FAILEDTOBUILD.txt.gz but seemingly not :)
<jodh> xnox: no - that won't work as dbus isn't configured in the chroots.
<jodh> xnox: see in_chroot() and dbus_configured() in test_initctl.c.
<jodh> so, really, we need to fix test_libupstart() to handle being run from within a chroot. Technically, that test is flawed as it assumes it's already running on a system with upstart - it should really spawn its own instance.
<magmatt> I have /etc/init/aolserver.conf http://bpaste.net/show/fDLGOSF3dfG7X6RTyGkk/ but, because there's nothing running in the foreground, I can't stop/restart it.  What's a better approach to starting multiple services?
<jodh> magmatt: I think you should be looking at 'instance': http://upstart.ubuntu.com/cookbook/#instance
<jodh> magmatt: the examples in the cookbook are a little basic, but this example might be more useful...
<jodh> magmatt: worker.conf: http://paste.ubuntu.com/5802034/
<jodh> magmatt: workers.conf: http://paste.ubuntu.com/5802036/
<magmatt> okay, thank you jodh.  I'll have a go at that
<magmatt> jodh: if one of the stop worker commands fails (in workers.conf) will it not continue to the others?
<jodh> magmatt: if you want it to: change 'stop worker id=$inst' to 'stop worker id=$inst || :'.
<magmatt> jodh: how do I get `initctl status workers` to work? Here's what I'm seeing: http://paste.ubuntu.com/5802108/
<magmatt> would it be silly to do: script while true; do done; end script?
<magmatt> or maybe with a long sleep in there
<jodh> magmatt: maybe just do "initctl list|grep aol" :)
#upstart 2013-06-28
<jodh> /topic Upstart 1.9 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
<jodh>  
* jodh changed the topic of #upstart to: Upstart 1.9 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
<elmo> jodh: \o/
<elmo> jodh: could I safely run upstart 1.9 on raring if I backport it?
<xnox> elmo: wait for us to merge 1.9 into saucy & apply ubuntu-specific patches for apparmor, and then backport that package.
<elmo> xnox: ok
<xnox> elmo: well, i expect you will just be able to recompile for raring.
<erkules> ahoi short question. having in his old init script  an own option. Does upstart has any way to have own options? I was thinking about using emit, but that is too fuzzy.
<xnox> erkules: what do you want to achieve? and what do you want to do?
<xnox> erkules: all common tricks are described here: http://upstart.ubuntu.com/cookbook/#cookbook-and-best-practises
<erkules> xnox: hi, I was reading a blogpost. There they patched galera-init with a bootstrap option. So when you start the script with that option it creates a new GTID
<erkules> xnox: okidoki
<xnox> erkules: i'm still confused what your initial problem/question is. =)
<xnox> erkules: if you want to launch different instances of the same daemon you can be using instances
<erkules> hehe
<xnox> erkules: what is galera-init? what is GTID?
<erkules> ok GTID (global transaction id)
<erkules> it is a galera thing
<erkules> mysql-multi-master
<erkules> service mysql start -> starts the server with old GTID
<erkules> service mysql start --bootstrap forces the server to create a new GTID
<xnox> erkules: if a job is already running, upstart will not try starting it again. Thus you should stop; start.
<xnox> erkules: if you want to keep the "old one" running. and run a new one with a different GTID simultaniously. Look into passing variables to jobs and/or instances.
<xnox> erkules: it looks like above is an init.d script, are you converting it to a native upstart job?
<xnox> erkules: cause under upstart, you can continue using init.d scripts and above should just work as upstream uses it.
<erkules> xnox: I would like to implement the idea of extra options in my own upstart script
<xnox> erkules: they are not scripts, and are not executed.
<xnox> erkules: they are configuration files.
<xnox> erkules: you can pass environment variables to them.
<xnox> erkules: e.g. you can have $ start myjob BOOTSTRAP=true
<xnox> but not arbitrary arguments.
 * xnox slowly builds on disk.
<xnox> jodh: all 18 tests pass for me with saucy sbuild.
<xnox> jodh: please note that for me locally upstart testsuite fails if sbuild is using: overlayfs, tmpfs, eatmydata.
<erkules> xnox: thats cool
<erkules> xnox++
<xnox> jodh: thus to build upstart I always use sbuild with a configuration closer to the distro builders:
<xnox> jodh: so my /etc/schroot/chroot.d/sbuild-saucy-amd64 looks like this: http://paste.ubuntu.com/5808343/
<xnox> jodh: and I build upstart with sbuild -c saucy-plain-amd64 path-to.dsc
<slangasek> xnox: so I confirm your result that the branch builds fine in my sbuild environment; must be something specific to eatmydata or other optimization
#upstart 2013-06-30
<pfak> I'm looking for a way to append to a job instead of overriding a job, is this possible?
#upstart 2014-06-23
<wyattjoh> So Iâve determined that the error being printed now is â/proc/self/fd/9: 8: /proc/self/fd/9: setuid: not foundâ yet Iâm running 1.12.1 which should have this command no?
<wyattjoh> Any ideas?
#upstart 2014-06-24
<afournier> morning
<afournier> i am working with upstart 1.6.1 and packaging it with oe. I would like to play with the dbus interface but the com.ubuntu.Upstart.*.xml are not installed (in /usr/share/dbus-1/) is it possible to do so with the provided Makefile, or i have to install it manualy ?
<xnox> afournier: upstart is not dbus activatable service.
<afournier> i don't really get what you mean, but what i want to do it use dbus to start, stop and monitor daemons using the dbus interface
<afournier> http://upstart.ubuntu.com/wiki/DBusInterface
<xnox> afournier: USR1 signal is used by upstart to connect to system dbus.
<xnox> afournier: after that upstart is available on the system dbus.
<xnox> (and thus the dbus interface)
<afournier> i read about that some days ago, the thing is dbus needs a patch for this and i could not apply it
<afournier> but still i don't want to do things like "start on <dbus event>"
<afournier> i just want to talk to upstart thru its dbus interface
<afournier> and rpc com.ubuntu.Upstart0_6.GetAllJobs and EmitEvent and stuff like that
<xnox> afournier: (a) start system dbus (b) make post-start of dbus call "exec kill -USR1 1" (c) upstart will be available on the system bus (d) open e.g. d-feet and read the job statuses via dbus api
<xnox> afournier: initctl tool uses dbus API to upstart only, and can do so via system/session DBUS and private sockets.
<afournier> i think it's possible as netstat tells me there are two active dbus connections on @/com/ubuntu/upstart
<afournier> ok
<xnox> afournier: that's private socket, that uses the same dbus IPC, the socket is always available. If upstart is not on the system dbus, you need to send USR1 signal to upstart.
<afournier> ok
<afournier> then i need to patch dbus
<afournier> no ?
<xnox> afournier: no.
<xnox> afournier: why?!
<xnox> afournier: upstart connects to system dbus and publishes an object.... no more no less
<afournier> dbus only has "--systemd-activation"
<xnox> afournier: DBusInterface is not about dbus activation styles, above will give you dbus api to start/stop/restart upstart jobs.
<xnox> afournier: it will not give you ability to control dbus activated daemons through upstart's $ initctl stop, command for example.
<afournier> good, then my init/dbus.conf has "post-start exec kill -USR1 1"
<afournier> so let's go back to the first question :)
<xnox> that's all you need.
<afournier> upstart does not install it's dbus schemas by default, i don't want to use d-feet or something like this. I'd like to code my own client using dbusxx-xml2cpp and some c++
<afournier> i could make an upstart request to introspect the upstart dbus interface, but it's not fair for "offline" compilation
<afournier> s/upstart request/dbus call/
<afournier> do you get my point ? :p
<xnox> afournier: one is expected to copy the partial schema of the things you will use only into your source code. Use whichever code generator appropriate for your language.
<xnox> afournier: we do not indeed install developer headers at all, and well didn't in 1.6
<xnox> afournier: in recent upstart, we have libupstart which is compiled client side dbus library.
<xnox> afournier: look at the code of the upstart bridges.
<afournier> wouldn't be cleaner to introspect directly from system directories like /usr/share/dbus-1/.../com.ubuntu.Upstart.xml ?
<afournier> i mean generate code
<xnox> afournier: it's dbus client apis, you don't need them published.
<afournier> i must be completly wrong then as i am new to dbus, but i thought each installed program would publish it's schemas so you can generate your dbus bindings easily
<xnox> afournier: it looks like there is /usr/share/dbus-1/interfaces where things drop their interface files, we don't at the moment. I can add that for next release, but that will not change history.
<afournier> no it won't, it just makes things cleaner i think :)
<xnox> afournier: whilst it wasn't planned at the beginning upstart dbus has never changed, and is stable.
<afournier> so when you compile somethign against your distro, you know your dbus bindings are up to date
<afournier> i see
<xnox> afournier: if you complile complete bindings into your app / service you will get a lot of generated code into your app.
<afournier> that's true
<afournier> but upstart dbusinterface is well done and i think all methods could be usefull :)
<xnox> afournier: hence e.g. mountall has it's own private ./dbus/com.ubuntu.Upstart.xml with only 6 methods and 2 properties of the interface.
<afournier> interesting
<xnox> libupstart1.so.1.0.0 generated into C with nih-dbus-tool is 156k, which is a lot if you only need a couple methods.
<xnox> (dbus methods / properties)
<afournier> even so code generator could use filters based on methods names or something like this to filter out useless methods. this would avoid useless copy of dbus interfaces. I am no dbus programmer :) so i must be completly wrong.
<afournier> i just don't like copy paste
<afournier> :)
<afournier> but as you said no big deal
<afournier> by the way the upstart dbus interface is splitted in 3 files, so we can go under 156k if needed :)
<afournier> that a good trade-off
#upstart 2014-06-26
<dariocravero> hi all, I have an upstart script that needs some of the user's secondary groups being set and after a while without knowing what was going on I realised that setgid only sets one group for the user. I've found this SO post (http://superuser.com/a/225355/134737) that highlights a few alternatives to it, it's a bit old though, are those still relevant or is there any better way to go about it?
<dariocravero> should I use start-stop-daemon instead?
<dariocravero> do I still need to use setuid and/or setgid in that case?
<dariocravero> thanks :)
<Phlogistique> hi
<Phlogistique> I'm trying to run an upstart-based system (Ubuntu) under systemd-nspawn
<Phlogistique> Did anyone do that successfully?
<Phlogistique> http://sprunge.us/LTGD so far I get this in the console. does this "Handling starting/failed event" message mean that mountall has failed?
<Phlogistique> I believe I would have to de-activate mountall but still emit the events that it would emit on success
<nikkie> Hi folks.  I'm having some issues with a pair of upstart scripts.  I'm running several instances of the same job, so I have a start-this-once script and a many-many-instances script.  The jobs stop correctly and start, but when I run start, it hangs on the invocation instead of telling me the job started.  Upstart doesn't have the pid of the N jobs it starts.  Here are my scripts:
<nikkie> https://gist.github.com/nikolawannabe/4f5bcdd1a6954038f23f
<nikkie> I removed task and it no longer hangs. Not sure if that is the correct fix.  Any commentary would be appreciated!
#upstart 2014-06-27
<shamilton> hey, I want to start a daemon for each network interface after local-filesystems, I'm trying to do this with instances but it's not working, is this actually doable?
#upstart 2014-06-28
<shamilton> specifically I have two jobs, one is instanced on $INTERFACE, the other is a task which starts on (started network-interface and local-filesystems) and just starts an instance of the first job
<shamilton> is this a reasonable approach?
<shamilton> my guess is the second one may need to be instanced as well, so that it can maintain state for each network-interface in the case that local-filesystems has not yet fired
<shamilton> simplified it to a single job, seems to work if the interface comes up before local-filesystems, presumably because then the state exists for that interface, but if the interface comes up after, I guess the instance is created and it never sees the local-filesystems event
<xnox> shamilton: hey
<xnox> shamilton: local-filesystems event is only emitted once, thus all subsequent tasks (which trigger on network-interface) are "stuck" waiting on local-filesystems to be emitted again, which will never happen.
<xnox> shamilton: you can have "start on network-interface" and it will be started on each interface (one at a time, or multiple if you also use instance in the task)
<xnox> shamilton: but, on debian/ubuntu systems it's best to use if up & if down scripts anyway. As they are more closely related to network configuration / deconfiguration
<shamilton> okay, but my daemon actually does require local-filesystems -- should I just poll for it in my pre-start script?
<xnox> shamilton: if it is a daemon, it's not a task.
<xnox> shamilton: why not make it "start on runlevel [2345]" ?
<shamilton> yeah, previously I had a separate task which was spawning the daemon due to some other mapping logic I require, but I've since removed it to try to get something simple working
<shamilton> I need an instance per network interface
<shamilton> so forget about everything above, current situation is I have a single job which starts an instance on (started network-interface and local-filesystems)
<shamilton> but it doesn't start if the network interface comes up after local-filesystems
<xnox> shamilton: you will ever have one of those. Since "local-filesystem" is one time event (which fires only once) then it waits for e.g. one network interface to fire, after which local-filesystem event is retired.
<xnox> shamilton: and during a lifecycle of a single boot local-filesystem is never repeaded.
<shamilton> my understanding is that each job remembers that local-filesystems has already fired, so I'm thinking if I could "touch" the jobs for the interfaces which I know will come up in the future, I could get it working, though it's a bit hacky
<xnox> shamilton: no, nothing remembers anything. That would state preservations, there is no state.
<xnox> shamilton: write a simple job which does this:
<xnox> start on A and B
<xnox> stop on C
<xnox> $ initctl emit A
<xnox> $ initctl emit B
<xnox> $ status test job
<xnox> start/running
<xnox> $ initctl emit C
<xnox> $ status test-job
<xnox> stop/waiting
<xnox> $ initctl emit B
<xnox> $ status test-job
<xnox> stop/waiting
<xnox> ..... waiting for event A to be emitted again.
<shamilton> does it not remember that A has fired, so that it can start for real when you emit B?
<xnox> so you can have "instance INTERFACE \ task \ start on network-interface"
<xnox> shamilton: no, it does not remember, because upstart is event driven, not state driven.
<xnox> shamilton: it's widely documented and explained in multiple times in the cookbook.
<shamilton> http://upstart.ubuntu.com/wiki/JobEventExpressions "When an event occurs, each node in the tree is checked, and the value changed if the event matches. Each parent node is then updated to the new value."
<shamilton> my interpretation of this is that it maintains state
<xnox> shamilton: please see cookbook. http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions
<xnox> shamilton: there are other sections as well about it.
<xnox> shamilton: and just read through http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions it has examples of all common cases, including mutually exclusive tasks and those that need 1 to 1 mapping
<shamilton> so in your example above, you remove "initctl emit A", "initctl emit B" would no longer start the job, correct?
<shamilton> I don't see how it could be stateless if so
<xnox> it's implemented as follows
<xnox> event fires, iterate across known waiting/blocked jobs and check the events it keys on.
<xnox> if any match, mark it as satisfied, free the event.
<xnox> if last condition is satisfied start the job.
<xnox> so for example:
<xnox> $ initctl emit A
<xnox> $ initctl emit B
<xnox> $ initctl emit A
<xnox> $ stop test-job
<xnox> $ initctl emit B
<xnox> will _not_ start the job. (as event A arrived whilst the job was running thus no conditions are tracked)
<shamilton> okay, got it, that's roughly how I understood it
<xnox> it's all to avoid deadlocks, circular dependencies and keep the core very simple 1-time event propagation.
<xnox> there is no multi-pass.
<xnox> shamilton: but yeah, in your case you should "instance $INTERFACE \n start on network-interface" and in the pre-start block until all other things are satisfied (e.g. mountpoints mounted et.al.)
<shamilton> suppose hypothetically I could touch all the instances I expect in advance at "startup", would it not then remember that local-filesystems has fired, and behave desirably?
<shamilton> ignoring the restart thing, which isn't a problem
<shamilton> I guess at that point there isn't much reason to use instances
<xnox> shamilton: hm, no, and typically one uses instances only when you do not know ahead of time how many instances you will have.
<xnox> shamilton: e.g. for hot-plug type of things. If you do know all the interfaces you expect to have, then I'd store it in a config file somewhere and then have 1 arbitrator job which is "start on local-filesystems" and instance job without any start on conditions at all.
<xnox> then arbitrator would do: script \n for i in $DESIRED_INSTANCES; do start --no-wait worker INTERFACE=$i; done \n end script
<xnox> shamilton: what is the actual thing you are running? and why does it have to be started on per network interface?
<xnox> shamilton: can it not just start one daemon that e.g. connects to network-manager over dbus to monitor networking events and act appropriately on them?
<shamilton> it's basically tcpdump, which I want running as early as possible, but I do need a separate instance per interface
<xnox> shamilton: right, true. why do you need local-filesystem them?
<xnox> shamilton: with recent enough upstart stdout & stderr is collected and stored into /var/log/upstart/job-instance.log
<xnox> shamilton: and that is done irrespective of filesystems (e.g. it's cached and flushed to disk, once disk becomes writable)
<xnox> shamilton: check $ man 5 init to see if you have "console log" (the default) available to you. 
<xnox> shamilton: .... and networks can be established in the initramfs /before/ upstart is run.
<shamilton> root filesystem is RO, the RW disk doesn't come up until a bit later, the packet inspector needs RW to the filesystem
<shamilton> also this is just my piece of the puzzle, unfortunately I'm not at liberty to make sweeping systemic changes
<shamilton> some kind of process controller would be ideal, but in the interest of getting things working quickly, I'm trying to do it with usptart
<shamilton> and just polling for the filesystem in a pre-start should do the trick, though it feels suboptimal
<shamilton> however, I can leave a comment saying it was vetted by an upstart dev
<xnox> shamilton: what upstart version you are using?
<shamilton> # /sbin/init --version
<shamilton> init (upstart 1.5)
<shamilton> unfortunately
<shamilton> might be able to drop in a newer one if it wouldn't break anything
<xnox> shamilton: and i'm not sure why packet inspector needs RW, if you can redirect output to just plain stdout upstart will collect it for you, from early boot even whilst filesystem is RO.
<xnox> shamilton: and i'm not sure what you mean "vetted by an upstart dev". I didn't veto anything =)
<shamilton> inspection engine has a local database, so unfortunately it's not as simple as stdio buffering
<shamilton> again not my call
<shamilton> okay, "discussed with someone who sounded like they knew what they were doing"
<xnox> shamilton: well, you can get away without a pre-start
<shamilton> oh?
<xnox> shamilton: so have your thing start on network-interface - aka worker. And have another job which is called "check-conditions" which is also an instance "start on starting working" which would block until file systems are writable et.al. Not really that different, but you'd be able to optimise those checks to short-circuit them after it succeded the first time.
<xnox> with "start on starting foo" you can pre-empt and block foo from starting until this other job completes.
<xnox> shamilton: again this is also described in the cookbook. Do please read the cookbook's common examples, to see if there is inspiration to organise your jobs.
<xnox> http://upstart.ubuntu.com/cookbook/
<xnox> 11 COokbook and Best Practises
<shamilton> so I have a task which is start on starting tpcdump, it blocks until the filesystem is available, correct? not quite sure what you mean by short circuit the tests
<xnox> shamilton: yeah. Short cirtuit - e.g. cache the result, at the end touch /var/run/life-is-good, and that filesystem check can start with: if  [ ! -e /var/run/life-is-good ]; then block until filesystem is mounted; fi exit 0
<shamilton> k, that's what I thought you meant, but the filesystem test is also a -e, so in this case I don't win much
<shamilton> think the pre-start script is the simplest approach
<shamilton> guessing there's no chance for future statefulness
<xnox> shamilton: we did plan to introduce state tracking. E.g. "while mounted MOUNTPOINT='/' and running webserverd" stanza and then monitor and start/stop when state is correct/incorrect.
<xnox> shamilton: but that was very vague plans. Currently in the pipeline are cgroups support & non-blocking process spawning (speed up)
<xnox> shamilton: nobody is working to design nor implement statefulness at the moment.
<shamilton> thanks for your help. I'm not completely satisfied with the end result, as I was really hoping it could be completely event driven (sans polling,) but at least I can put it to bed
#upstart 2015-06-23
<Xpersona> HI! Someone can help me?
<Xpersona> #start on (starting network)
<Xpersona> #start on (runlevel [345] and started network)
<Xpersona> #start on runlevel [2345]
<Xpersona> #start on (starting session-manager)
<Xpersona> start on started
<Xpersona> stop on runlevel [016]
<Xpersona> respawn limit 20 5
<Xpersona> #setgid user
<Xpersona> setuid user
<Xpersona> exec /usr/local/bin/ipython notebook -pylab --profile=nbserver --ipython-dir=/home/ubuntu/.ipython
<Xpersona> I need to exec ipython like non-priviliged user; this option run ipython like user but the web service is not exec...
#upstart 2015-06-25
<lnykryn> kde ze je posledni verze toho patche?
<lnykryn> sorry wrong tab
<stamak> Hi here
#upstart 2015-06-26
<frew> hey guys, I am dealing with an ubuntu 12.04 VM and initctl is a shell script containing exit 0
<frew> so like, I can't seem to enable daemons or anthing
<frew> ideas?
<frew> aha: https://github.com/tianon/docker-brew-ubuntu-core/blob/67accc07b2f77dbf00dc4e2d5b90c00abc225ec6/precise/Dockerfile#L10
#upstart 2015-06-28
<bonhoeffer> hey -- anyone know if this means success: tart: Rejected send message, 1 matched rules; type="method_call", sender=":1.39" (uid=1002 pid=5818 comm="start improvement.rocks ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
<bonhoeffer> nope -- failure from permissions problem
#upstart 2016-06-27
<hallyn> hm, so in upstart system there's this process that just is 'exec /proc/self/fd/9' and always has a sleep 0.2 child;  parented by init, restarts when i kill it.
<hallyn> strace shows [pid 32392] connect(3, {sa_family=AF_LOCAL, sun_path="/dev/socket/property_service"}, 31) = -1 ENOENT (No such file or directory)
<hallyn> some android thing?  /me confused
<hallyn> it actually takes a non-negligible amount of battery, besides just looking suspicious
<hallyn> hm, ok it's urfkill
<hallyn> lol who wrote that job
<AnrDaemon> An enemy of mankind?
<hallyn> :)
#upstart 2016-07-01
<Azoff> Hello
<Azoff> I've got a server running Ubuntu 14.04 LTS (upstart 1.12.1-0ubuntu4.2) where I get 'start cryptdisks' to hang without any output to the screen or any other response. Ctrl+C terminates it, so it's not a zombie process
<Azoff> Background: The server can boot a basic system on an unencrypted partition. Once booted, I can ssh to the server and unlock a partition that contains the configuration files (linked from /etc/) that allows me to mount a few other data partitions. All these data partions are encrypted.
<Azoff> I've been using the layout for a few years, but recently got into trouble issuing '/etc/init.d/cryptdisks restart'.
<Azoff> I've traced the issue as far as I can see that cryptsetup thinks it's done with the stuff it's supposed to do, but 'start' never returns
<Azoff> running strace on 'start cryptdisks' ends with the following 3 syscalls repeating over and over again until stalled at poll(): poll() = 1, recvmsg() = -1, clock_gettime() = 0
<Azoff> any idea what I could try next to find out why it's stuck there?
<Azoff> Hi JanC 
<Azoff> Ok, some more details. It looks like dbus_pending_call_block(pending_call) never returns, and the error_handler or reply_handler is neither called. Could it be due to that the conf-file does not contain anything but 'task' and 'pre-start script'?
<Azoff> :q
<AnrDaemon> Azoff: It is a wonder the job even tried to start.
<Azoff> AnrDaemon: ok? How so?
<Azoff> Just for the record, I've not written this conf-file.
<AnrDaemon> Without start script or exec, the behavior is undefined, IIRC.
<AnrDaemon> And any undefined behavior is a can of worms, typically.
<Azoff> ok? this is the default conf for cryptdisks (cryptsetup) in ubuntu since at least 14.04
<Azoff> have you seen the conf?
