#upstart 2007-06-04
<HTSJacket> I'm having trouble understanding this sentence in the getting started page: This should be one of output (input and output from /dev/console), owner (as output and Control-C also sent the process) or none (the default; input and output to /dev/null).  Can anyone explain what "as output and Control-C also sent the process" means here?
<Keybuk> morning all
<reppel> why upstart does not pass kernel cmdline argumments as env variables to jobs?
<reppel> hi Keybuk 
<Keybuk> reppel: because it doesn't yet (missing feature)
<reppel> Keybuk: ah ok
<Keybuk> jobs should be able to select which variables they want to receive with "env VAR" in their definition
<reppel> Keybuk: nice
* Starting logfile irclogs/upstart.log
<Keybuk> hmm
<Keybuk> who needs config file code anyway?
<shawarma> Does upstart have some sort of in-memory idea about which jobs exist? If so, how do I make it rethink that list?
<Keybuk> yes
<Keybuk> there's no way (yet) to make it reload that list
<shawarma> I see. Hm.
<shawarma> That kind of sucks. :)
<Keybuk> why?
<Keybuk> (do you need to make it reload)
<shawarma> I want to have upstart manage a newly added daemon.
<shawarma> So yes, I need to make it reload.
<shawarma> Unless I'm missing something obvious?
<shawarma> It's been known to happen.. :(
<Keybuk> why not just write the file? :)
<Keybuk> bet you if you do "initctl list", the new daemon's there
<Keybuk> inotify is a wonderful thing
<Keybuk> <g>
<shawarma> Keybuk: It seems not?
<Keybuk> which version of upstart/
<shawarma> oh..
<shawarma> Not making syntax errors in the job file helps a lot.
<shawarma> :)
<cort> how does it ensure that it only reads the file once it's been written?
<cort> or can inotify tell you that the newly-created file has been closed
<Keybuk> cort: IN_CLOSE_WRITE
<cort> cool
<Keybuk> (closed and written to)
<shawarma> When does upstart consider a job to be started?
<shawarma> I.e. without --no-wait, when will "start jobname" terminate?
<Keybuk> depends whether it's a task or a service
<shawarma> Since it's a deamon I want supervised, I expect I should pass it arguments to run in the foreground?
<Keybuk> if it's a task, start will not terminate until the job terminates
<Keybuk> if it's a service, start will terminate once the job is running
<Keybuk> right
<Keybuk> you should make sure it runs in the foreground
<Keybuk> and make sure "respawn" is in the job definition
<AlexExtreme> it helps not to leave duplicate values around in the profile from testing <g>
<Keybuk> heh
<Keybuk> I changed the job code today to not bitch about duplicate stanzas
<AlexExtreme> heh
<shawarma> Keybuk: Oh, so "respawn" tells it that it's a service? Got it.
<Keybuk> shawarma: respawn tells it that it's a service that should be respawned
<Keybuk> shawarma: "service" tells it that it's a service that should not be
* AlexExtreme will have fun merging the changes in main to the profiles branch
<shawarma> Keybuk: Oh, ok.
<Keybuk> AlexExtreme: <g> did you look at them yet?
<AlexExtreme> not in detail yet
<Keybuk> it should make things a lot easier for you
<Keybuk> you just need a parse_profile.c with a parse_profile() function
<AlexExtreme> sweet
<Keybuk> takes the usual file, len, pos, lineno parameters, and probably has stanza_*() functions and a table to parse that block of text
<Keybuk> pretty much everything else will be handled for you
<Keybuk> (watching the directory, tracking reloads & deletes, etc.)
<AlexExtreme> nice
* AlexExtreme reads through his commit mails
<Keybuk> you get commit mails?
<AlexExtreme> yeah
<AlexExtreme> if you subscribe to a branch you can configure it to send you mails on new commits ;)
<Keybuk> neat
<Keybuk> does it attach diffs?
<AlexExtreme> yep, as long as the diff is under a certain size
<Keybuk> shiny
<Keybuk> I never knew about that
<AlexExtreme> The size of the diff (10342 lines) is larger than your specified limit of 1000 lines
<AlexExtreme> yeah, i only found that feature the other day ;)
* AlexExtreme likes launchpad
<Keybuk> what diff was that?!
<AlexExtreme> rev 693
<Keybuk> wow
<Keybuk> no wonder my fingers hurt yesterday
<AlexExtreme> :P
<AlexExtreme> oh, 696 is bigger ;)
<AlexExtreme> 2968 lines
<Keybuk> 2968 < 10342 ?
<AlexExtreme> whoops
<AlexExtreme> misread it with an 0 on the end for some reason :p
<AlexExtreme> s/an/a/
<AlexExtreme> so, with the new code, i would ignore duplicate values and overwrite the old value with the new one instead?
<Keybuk> right
<AlexExtreme> k
<mbiebl> Keybuk: I spotted a small glitch. Patch is here: http://pastebin.ca/536963
<Keybuk> mbiebl: yeah, that'll be needed, thx
<Keybuk> committed
<AlexExtreme> brb, testing the NihHash-ified profile code
<mbiebl> Keybuk: thx
<AlexExtreme>         /* FIXME: Read configuration */ << if we don't read the configuration, does this mean the current bzr doesn't work? :)
<Keybuk> right
* AlexExtreme will hold back on updating the profiles branch to the latest main then :p
<Keybuk> 08:23 <Keybuk> is it bad to push incomplete code to main? :p
<AlexExtreme> just checking in case you've made it working today
<Keybuk> no, not yet
<Keybuk> it's a complex problem that I want to solve
<Keybuk> and I find it difficult to work in the afternoon, for some reason
<AlexExtreme> heh
<AlexExtreme> np
<AlexExtreme> btw, i'm assuming we shouldn't disable jobs from automatically starting on the stalled event?
<Keybuk> AlexExtreme: why not?
<AlexExtreme> because say a user does "disable *" and doesn't enable any jobs specifically, the system will just hang at boot with no useful message. surely it should give them an opportunity to login and fix their blunder?
<Keybuk> quest upstart% bzr diff -rtag:0.3.8.. | diffstat | tail -1
<Keybuk>  34 files changed, 7423 insertions(+), 6014 deletions(-)
<Keybuk> whee
<AlexExtreme> http://codebrowse.launchpad.net/~keybuk/upstart/main/changes << umm :P
<AlexExtreme> 500 Internal error
<AlexExtreme> The server encountered an unexpected condition which prevented it from fulfilling the request.
<Keybuk> poked lp
<AlexExtreme> k
<Keybuk> AlexExtreme: heh, broken by having tags, apparently
<AlexExtreme> lol
* Keybuk is still trying to figure out the registry stuff
<Keybuk> it's a little complex right now
<Keybuk> the theory is:
<Keybuk>  - a hash table for each type (Job, State, Profile, etc.)
<Keybuk>  - each entry is a Name structure that has the name, a pointer to the current holder of that name, and a list of available entries with that name
<Keybuk> when we parse a config file, we add all entries to the available list in their relevant namespace
<Keybuk> then if the current holder of the name is replaceable immediately, we pick the new best current name
#upstart 2007-06-06
<Keybuk> this whole configuration/namespace issue is hard :-/
<Keybuk> in fact
<Keybuk> this is, if anything, more boring and tedious than the IPC code
* rgl has no clue what the issue is
<Keybuk> rgl: making it so upstart supports reloading its configuration
<rgl> Keybuk, oh I imagine :/
<Keybuk> https://launchpad.net/upstart/+download
<Keybuk> neat
<Keybuk> codebrowse seems to work again, too
<AlexExtreme> my connection would die just as i try to open that link, wouldn't it.
<AlexExtreme> there we go
<AlexExtreme> neat :)
#upstart 2007-06-08
<Keybuk> meh, don't really have anything new to talk about for LCA 2008 :-/
<kylem> Keybuk, er, are you new at this?
<kylem> you put in the abstract, *then* write the new code.
<kylem> 8)
<Keybuk> kylem: I'm still writing the code from last time <g>
<kylem> lol.
<AlexExtreme> Keybuk, talking of LCA, do you have a copy of your presentation from LCA2007? It's quite hard to read the text on the video
<Keybuk> it should be linked on the lca website no?
<AlexExtreme> no, the actual slideshow
<AlexExtreme> i have the video here
<AlexExtreme> just the text on the slideshow is all fuzzy :p
<Keybuk> that's what i mean
<Keybuk> oh, I see, the slides are a 404
* AlexExtreme didn't even notice there was a link to them :p
<Keybuk> usual post-conference "not bothering to finish the website" syndrome there I think
<AlexExtreme> yeah
<Keybuk> unfortunately I can't seem to find a copy of the presentation!
<AlexExtreme> darn
<Keybuk> which is actually quite irritating
<ion_> I dont think i downloaded it either. :-\ Perhaps someone reading the mailing list has a copy.
<ion_> I did watch the presentation.
<Keybuk> I have an old draft of it, not the actual presentation
<Keybuk> hmm
<mbiebl> AlexExtreme: Maybe google cache has it...
<AlexExtreme> looks like they never had a copy of it on the site :/
<mbiebl> oh
<AlexExtreme> google cache doesn't have it
#upstart 2007-06-09
<mbiebl> This proposal looks awful: http://fedoraproject.org/wiki/FCNewInit/RC
<ion_> Eww
<cortana> egads
<AlexExtreme> ewww @ the Fedora new RC thing
<AlexExtreme> I saw the discussion on their mailing list about switching to an alternate init system, would you beleive that they were discussing shipping every init system by *default* and have scripts for each one in every package that needs one
<ion_> http://heh.fi/tmp/saukonpuisto-panorama
#upstart 2007-06-10
<Keybuk> #6  0x0804b322 in test_source_reload () at tests/test_conf.c:288
<Keybuk> 288             TEST_EQ_P (item->job, job);
<Keybuk> (gdb) p job
<Keybuk> $1 = (Job *) 0x0
<Keybuk> (gdb) p item->job
<Keybuk> $2 = (Job *) 0x806c8b0
<Keybuk> (gdb) p item->job->name
<Keybuk> $3 = 0x806c9c8 "tmp/test_conf.c-test_source_reload-213-12871/foo"
<Keybuk> heh
<Keybuk> oops
<AlexExtreme> heh :p
<Keybuk> hey Michael
<mbiebl> Keybuk: hi
<Keybuk> how goes it?
<mbiebl> Fine, thanks.
<mbiebl> How about you?
<Keybuk> not so bad
<Keybuk> making an attack on the new conf code today
<mbiebl> Made a pull today and noticed that you were quite active the last couple of days ;-)
<Keybuk> yeah, beware that the current code isn't actually working
<Keybuk> ie. not finished
<mbiebl> What's your aimed release date for 0.3.9?
<Keybuk> no idea
<Keybuk> soon
<Keybuk> once the new conf code is working
<mbiebl> Does that also involve a change in the directory layout?
<Keybuk> maybe
<Keybuk> if I carry that, I'll renumber it to 0.4
<Keybuk> /etc/event.d will become /etc/init/jobs.d at some point
<Keybuk> but I may hold off and just use the new code to do /etc/event.d for now
<Keybuk> (or even sneakily support both)
<mbiebl> I'm currently preparing for Debconf (will be flying there on saturday)
<Keybuk> cool
<Keybuk> Edinburgh is a very pretty city
<mbiebl> Hopefully I'll be able to convice the fellow DDs, which are so keen on the meta-init-script format, that it's imho not such a great idea. 
<Keybuk> meta-init-script?
<mbiebl> There was some blogging and discussion a month ago about a meta-init-script format.
<mbiebl> From which initscript for the existing init systems should be generated.
<mbiebl> http://blog.incase.de/index.php/2007/04/17/init-script-generators/
<mbiebl> I'm pretty sure, such a system will not work.
<mbiebl> We would end up with something that would be even worse than we have today with sysvinit.
<ion_> *shiver*
<mbiebl> imo a initsystem is something important like the package format of a distro.
<AlexExtreme> fedora came up with a similar idea on their mailing list, i don't know what happened to it though, but instead of having a script generator they would simply provide a script in packages for most init systems. ugh
<mbiebl> That's a maintenance night mare.
<AlexExtreme> yep
<mbiebl> Even the metascript idea is not much better there, because the testing will be a nightmare.
<AlexExtreme> that's exactly what i was thinking as i read the thread
<Keybuk> Fedora are being odd
<Keybuk> cblizzard's post seems to think that starting things when you need them is a revelation
* Keybuk knows for a fact that he was sitting in my LCA Upstart talk
<mbiebl> And D-Bus all the way ;-)
<Keybuk> dbus people still seem to think that system services are the way forward
<Keybuk> "We have this great hammer ... I know this looks like a job for a screwdriver, but it works if we hit it hard enough with the hammer too!"
<AlexExtreme> heh :)
<ion_> Lets replace IRC with D-Bus.
<mbiebl> I also think that this whole D-Bus system service activation is crazy.
<mbiebl> Unfortunately the HAL guys are not much better in that respect.
<mbiebl> As much as I value what HAL brought for the Linux desktop,
<mbiebl> cramming everything into HAL, power management, disk formattting (shrug) etc, seems insane.
<mbiebl> (at least to me)
<Keybuk> they're not quite into HAL
<Keybuk> they sit alongside it, exposing themselves as HAL methods
<Keybuk> that makes some amount of sense
<Keybuk> the alternative is something like network-manager, which is its own daemon, with own communication properties, etc.
<Keybuk> using HAL for the communication actually makes it easier
<Keybuk> network-manager could be a hal add-on that implements "change essid" type properties on network interfaces
<Keybuk> which would make programming easier
<Keybuk> the separation is about the same, since the communication is still dbus, and the daemon is still separate
<Keybuk> you're just using a particular kind of dbus call (HAL methods)
<mbiebl> Well, if you make NM a HAL addon, you also lose some good features:
<mbiebl> The ability to start/stop it on its own.
<mbiebl> separate logging
<mbiebl> clear separation, so systems which don't use it, don't have to install it.
<Keybuk> hal addons are seperate daemons, so they can be start/stop'd on their own, etc.
<mbiebl> Really? Don't they have to be spawned from the hald process?
<mbiebl> And the standard service management tools will not work with hal addons.
<Keybuk> not sure whether they have to be or not
<Keybuk> I think the communication is just dbus, so they don't need to be
<Keybuk> ICBW
<mbiebl> Doesn't matter. It's just me, rambling a bit ;-)
<mbiebl> OT: Did you read this story: http://www.msnbc.msn.com/id/19088976?GT1=10056
<mbiebl> I really had to smile
<ion_> Hehe
<AlexExtreme> heh
<ion_> In case someone didnt notice this one, ill rudely spam it again. http://heh.fi/tmp/saukonpuisto-panorama
<mbiebl> cool. would make a perfect wallpaper for a 4-monitor xinerama setup ;-)
<mbiebl> bbl
<AlexExtreme> nice
* Keybuk has patches to nautilus/compiz to make paranoma wallpapers work across multiple viewports
<ion_> Do you make nautilus create a transparent background and compiz render the background?
<Keybuk> yup
<ion_> Thats great.
<Keybuk> http://people.freedesktop.org/~racarr/nautilus.debdiff
<Keybuk> you also need http://people.freedesktop.org/~racarr/libeel.debdiff
<Keybuk> and the compcomm wallpaper plugin
* AlexExtreme wonders when there will be a compcomm release
<ion_> Ive thought thats the way to go forever. A wallpaper image could be replaced with a nice non-distracting animation, on which the desktop stuff would be composited.
<wasabi> hah cool racaar did it
<Keybuk> yeah he did
<Keybuk> urgh
<Keybuk> messyness has ensued in the "job replacement" code :-/
<theCore> is the cron-like functionality in Upstart got implemented yet? 
<theCore> nevermind
<Keybuk> not yet
<theCore> Keybuk: yeah, I understood that, when I saw "Events generated at timed intervals or scheduled times" under planned features
<theCore> on the front page of upstart website
<Keybuk> *nods*
<Keybuk> File 'conf.c'
<Keybuk> Lines executed:71.04% of 221
<Keybuk> conf.c:creating 'conf.c.gcov'
<Keybuk> *sigh*
<Keybuk> 29% to go
* AlexExtreme really hates bugs
<ion_> Heh
* Keybuk really hates testing
<theCore> Keybuk: you're not the only one 
<theCore> at least, testing pays off on the long run
<Keybuk> truwe
<Keybuk> ok, whew
<Keybuk> the config code should now be roughly compatible with the old code again
<Keybuk> (except that this new code is ready to support -HUP/initctl reload; and also has the necessary smarts to be modified to support job definitions in larger files and multiple overlapping sources of jobs)
#upstart 2009-06-01
<ion_> So, Upstart 1.0 comes out this week, right? :-P
<ion_> Along with apt-sync, KMS for my video adapter, Gnome 3 and all the other exciting things.
<sadmac2> Keybuk: http://upstart.ubuntu.com/wiki/728_german-specifics-of-austria-and-german-speaking-switzerland
<sadmac2> Keybuk: is this topical?
<sadmac2> it almost looks like spam, but I don't see a phishing link
<sadmac2> yeah... the wiki is under some sort of attack
<sadmac2> ion_: would you know how to proceed?
<ion_> Iâd just restore an earlier backup of the database. :-P
<ion_> To stop the attack, well...
<ion_> Require a wiki admin to approve new users?
<sadmac2> ion_: I was hoping you had some sort of access to put into effect these measures
<ion_> Nope
<sadmac2> also moin sux use mediawiki
<sadmac2> but that's OT
<ion_> Iâm not saying moin doesnât suck, but mediawiki sucks badly as well. :-P
<sadmac2> it sucks less
<ion_> Letâs just use Google Wave for the wiki when it comes out. :-P Iâm sure someone will hack up a web UI for Wave that looks just like a wiki, but with all the benefits of the platform.
<sadmac2> ion_: haven't looked at google wave yet
<sadmac2> also, its The Google
 * sadmac2 fears The Google
<ion_> At UDS, people edit specs in realtime over the network with gobby. After UDS, they *manually* move the changes to wiki.ubuntu.com. Then random people (including me) add comments to the wiki markup (also losing the edit history â wait, i donât think gobby even creates one). Thereâs no clean way to display the pure article without the comments. Wave would handle *all* of that in a single platform, and judging from the >1 hour video i watched, it handles it ...
<ion_> ... very well.
<ion_> Wave is an open protocol. Google doesnât need to be involved at all.
<sadmac2> ah cool
<ion_> Whoops, i was supposed to add the comment about not getting an edit history from gobby after âmanually move the changes to...â
 * sadmac2 comes to the staggering realization that he can't distinguish random sequences of letters from scandinavian-language text
<ion_> :-)
#upstart 2009-06-02
<sadmac> Keybuk: are you here?
<Keybuk> I have always been here
<ion_> Keybuk is above our confinement to this âtimeâ thing.
<Keybuk> I wish ;)
<Keybuk> I'd settle for cloning
<Keybuk> but then I suspect I'd just end up having an orgy with myself
<sadmac> Keybuk: have you noticed the wiki spam?
<Keybuk> no
<sadmac> Keybuk: take a look at the recent changes page
<Keybuk> fun
<Keybuk> I hate wikis
<ion_> Letâs switch to Wave. Oh, wait, itâs not out yet.
<sadmac> ion_: you are a meme
<damjan> well, anyway it's the time of yearly vacations, so we can all go on the beach until Wave is out
<ion_> Letâs plan this beach trip of ours in Wave. Oh, wait, itâs not out yet.
<sadmac2> Keybuk: can we add captcha to the wiki to stop the hemorrhaging?
<Keybuk> we're going to switch to using LP auth
<sadmac2> oh. that works
<sadmac2> Keybuk: http://screwyouenterpriseedition.blogspot.com/2009/06/upstarts-return-to-open-source.html
<Keybuk> hardly "returned"
<Keybuk> ;)
<sadmac2> well you must expect some vitriol. my chinchilla-on-pcp lovability is what makes me such a joy to work with.
#upstart 2009-06-03
<ion_> keybuk: http://www.netsplit.com/ Couldn't write to: /srv/www.netsplit.com/htdocs/wp-content/cache/wp-cache-ffb167c5eaec6916b1841e6f7b5beea6.html 
<ion_> I was attempting to open your blog in case iâd find current information about how Upstart 1.0 works.
<ion_> Next up: the mailing list archive.
<Keybuk> *blink*
<Keybuk> fsck errors
<Keybuk> on a UML
<Keybuk> go figure
<Keybuk> fixed anyway
<ion_> keybuk: I liked The Siege. :-)
<sadmac2> ion_: what's The Siege?
<Keybuk> http://www.netsplit.com/2009/02/26/drabble-contest-the-siege/
<Keybuk> I guess
<sadmac2> ah yes. fun.
 * sadmac2 considers starting a lipogram planet meme
#upstart 2009-06-05
<ion_> âWindows systems often come with a full "reinstall this system from the beginning" recovery image - apparently a useful feature on that platform.â âLWN
<ilowe> hi guys, how would I specify different commands to startup and shutdown a service? It looks like the "stop on" stuff just kills the process and I want to allow it to shut down gracefully. Any ideas?
#upstart 2010-06-07
<jefimenko> hello
<jefimenko> i'm trying to setup upstart for a custom service
<jefimenko> i already have a legacy sysv initscript for this service and my main goal is to have the service respawned if it crashes etc.
<jefimenko> but i'm finding the docs on upstart light and not that many people seem to be using it yet
<jefimenko> it seems great though
<jefimenko> i'm on ubuntu-server, btw
<jefimenko> could anyone give me a little guidance on this?
<freshtonic> Is it possible to have an upstart service start and supervise a group of processes as a single logical service?  i.e. I want an instance of a process to run for each CPU core on my system, and if one crashes it must be restarted.
<freshtonic> I suspect that it doesn't support this usecase and I'll need to write some master process that is managed by upstart and master process manages the group of worker processes.
<freshtonic> But it would be good to be wrong :)
<jefimenko> i'm trying to write a jobfile and would like to do sanity checks in the pre-start script
<jefimenko> if any of these checks fail i would like to log debug information somehow
<jefimenko> with sysv initscripts i used to just use echo or something
<jefimenko> is there a way to do this in upstart?
<jefimenko> anyone awake?
<tstone> which is the most simplest shutdown config. I've looked at the ubutuntu 10.4 stuff but it used runlevels. I'd like to use s.t. without any runlevels.
<tstone> hi, im still working on the ptxdist integration for upstart. Right now i confused which might be the simplest shutdown system, without any runlevel support?
<Keybuk> tstone: however you like, I guess
<tstone> mh, is there a way to wait for all "managed" processes to be stopped
<tstone> more precicely without knowing which processes are all configured/running
<tstone> or put the other way: is there an event if everything is stopped, otherwise i would need a dependency for every package installed, without knowing which packages will be installed, no?
<Keybuk> I'm not sure I follow you, sorry
<tstone> have to leave right now... thanks for listening
<ion> tstone: With Upstart 0.10, there will probably be a job called âsystemâ or something like that. It will have a shutdown command in postinst and other jobs will have something like âwhile systemâ, so theyâll be stopped just before the shutdown command is run. You can do something similar, although not as nice, with current Upstart: do the same thing (and add âstart on startupâ to the system job), but since we donât have âwhileâ, use something like ...
<ion> ... âstart on started system, stop on stopping systemâ in jobs that only depend on that (and not e.g. filesystem).
<Keybuk> pretty much exactly like that, yeah
#upstart 2010-06-08
<tstone> ion: thanks for elaborating, i'm still a little confused about timing. So i have dbus with "stop on runlevel [06]" and a shutdown.conf with "start on runlevel [06]". Will shutdown be run after dbus has stopped?
<mgoetze> tstone: in principle those two things will happen in parallel, so perhaps you want "start on stopped dbus"
<tstone> mgoetze: which is kind of bad if this is a "reboot -f"
<tstone> it would be nice to have an event if all managed jobs are stopped
<tstone> without having to name all these jobs
<tstone> is there a reason that under ubuntu 10.4 dbus is configured to --fork. I thought that it would be better to start the services without forking?
<ntr0py> I have an issue with upstart in Ubuntu 10.04 starting gdm too early (resulting in low graphics mode error). How can i tell upstart to wait with gdm's start until nvidia/dkms is ready?
<ion> With the âsystemâ job, there would be no shutdown job: the system job would handle shutdown/reboot in post-stop.
<ion> If you know and control exactly how the jobâs main process behaves wrt. forking, itâs okay.
<ntr0py> ??
<ion> tstone: â
<tstone> ion: ok, but why fork, i mean dbus-daemon can also be started without forking. And i've got the impression that upstart sometimes gets the state of dbus wrong whith this "forking" behaviour.
<ion> It indicates the service is ready. In which scenario does it get the state wrong?
<ntr0py> does someone know where the start for gdm is defined in ubuntu lucid?
<tstone> ntr0py: just add a "and started SERVICENAME" to the line beginning with start.
<tstone> ion: i *think* (unfortunatly unverified) that it happens if dbus-daemon doesn't start when the pid file is left over.
<ion> Upstart doesnât care about pid files.
<tstone> ion: yes, but dbus-daemon unfortunatly does :-/
<ntr0py> tstone: im not exaclty getting it... what do you mean ?
<tstone> ntr0py: just do a "cd /etc/init; grep ^start" and try to understand
<tstone> ntr0py: ahem "cd /etc/init; grep ^start *"
<ntr0py> thx already did that...
<tstone> ntr0py: thats the way you can add addtional deps for starting a service
<ntr0py> tstone: do you know what starts the nvidia proprietary driver?
<tstone> ntr0py: sorry don't know but you can enable debugging by adding --debug to the cmdline.
<tstone> i would gues module-init-tools
<ion> I would guess the X.org driver.
<tstone> strange if i remove the --fork and the expect fork from dbus.conf dbus-deamon gets started but is listed as not running by initctrl?
<plautrba> tstone: you can still have <fork/> in your dbus-deamon config file
<tstone> plautrba: yes, but i was curious why thats in there. Probably it has s.t. to do with the dbus interface of upstart...
<ntr0py> tstone: i absolutely have no experience with upstart but i would GUESS it should be sth like "graphics-device-added /dev/nvidiactl PRIMARY_DEVICE_FOR_DISPLAY=1" ? Pls correct me if im wrong...
<ntr0py> or is it /dev/nvidia0 ??
<ion> Iâm quite sure the proprietary driver handles all that.
<ntr0py> ion: yes i want to trigger gdm start on nvidia driver beeing ready...
<tstone> ntr0py: sorry don't know
<tstone> is it correct that if devtmpfs is activated udevtrigger.conf is obsolete?
<AxillIum> I hope it's not too much of a n00b question, but I do not seem to find it in the documentation: how do I set a variable in a /etc/init/foo.conf script so I can use it in both pre-start script and the script part for starting the actual job?
<mbiebl> AxillIum: man 5 init
<mbiebl> look for env
<AxillIum> I have found the section, but unfortunately, it does not specify where to put the line. On the highest level it will not get accepted. In the pre-start script it will not keep the value after the pre-start script.
<mastamind> does upstart really depend on dbus?
<tech404> I'd like to start a bittorrent daemon as a user on startup with upstart. I've done some reading on this but I'm not sure about how to approach it. I know there isn't official support now and I'm guessing 'exec su me -c "exec deluged"' is the right way to go as start-stop-daemon would have to much overlap. I'm not sure what other options I should use though. I would think that if I was starting as root I would use 'expect fork' an
<JanC> AxillIum: why wouldn't it get accepted "on the highest level" ?
<ion> mastamind: The protocol implementation, yes. The daemon, nope.
<mastamind> ion: does the initctl (or what ever is used to emit events) need dbus to talk to the daemon?
<tech404> nm i guess I would expect fork.. As no one know I'll try without respawn for now to make sure I don't get some crazyness
<tech404> didn't follow far enough
<tech404> nm, sorry I'm just thinking out loud now
<mastamind> ion: ldd /sbin/init shows that dbus is a required library... :-(
<ion> Whatâs the problem?
<mastamind> upstart depends on dbus.
<ion> Whatâs the problem?
<mastamind> that IS the problem.
<mastamind> :-)
<ion> Upstart also depends on libc. That sucks. Letâs implement our own malloc, strndup, open, fork etc!
<mastamind> ion: do you really think, that impresses me?
<mastamind> or anyone else here?
<ion> Nope.
<mastamind> :-)
<JanC> "I hate DBUS, so I'm l33t"
<ion> In Soviet Russia, D-BUS hates you.
#upstart 2010-06-09
<MarcWeber> Is pre-stop always executed in 0.6.5 ?
<AxillIum> JanC: If I put the env directive on the highest level of the conf file, it says the service is unknown (start myservice: start: Unknown job: myservice).
<AxillIum> JanC: The highest level = not within a sub structure in the conf file, like on the same level as description or author.
<AxillIum> JanC: BTW: I have just found out that this problem only exists when I want the variable to include the output of some shell command: env MYVAR="prefix-"$(echo $UPSTART_JOB | cut -c 1-2)"-postfix"
<AxillIum> JanC: But it is exactly this output I need. These are just examples, I use some other, more service specific commands, but you get the idea I guess.
<mbiebl> AxillIum: I don't think upstart does any shell evaluation in env
<tstone> does anybody has an idea why:start on runlevel [06]\n task \n script\n reboot -f \n end script ,does not get started on reboot,shutdown?
<AxillIum> mbiebl: That's too bad, now I will have to find another way to make this work. Perhaps I can just put everything in the script sub, instead of using pre-start.
<AxillIum> Then, a new question, is there a way to give parameters like: start myservice 1.2.3.4:123 (IP address + port), wihtout using KEY=VAL pairs?
<tstone> the above skript does work with "shutdown -r" or "shutdown -h" but not with a plain shutdown? Any idea why a plain shutdown does not work?
<tstone> it seems as if shutdown goes to runlevel 1 by default...
<MarcWeber> Are there any problems know with pre-stop? It doesn't seem to be run here (upstart-0.6.5)
<Gadi> good morning, all. Has anyone here successfully used "start on kbdrequest" on an ubuntu 10.04 system?
<Gadi> the keymaps seem to be in order, but I cannot generate KeyboardSignal
<Gadi> with alt-uparrow
<desadoc> hi ppl
#upstart 2010-06-10
<hackel> Is there any way to determine the configuration file associated with an upstart job?  Preferably via dbus?
<JanC> hackel: file & job have the same name?
<hackel> JanC, is that always a certainty or merely a coincidence?
<hackel> That's what I wound up doing, it just felt like a bit of a hack.
<JanC> it's explained in the first section of the manual...
<hackel> Okay, thanks.
<Omahn> I have a *really* basic upstart script that hangs when I try to stop it and I've no idea why. If I manually send a TERM signal to the exec'd process then the process stops fine so I'm at a loss why upstart is seemingly hanging. Any clues? Script is here: http://paste.ubuntu.com/447777/
<plautrba> Omahn: "expect fork" doesn't work with "script"
<Omahn> plautrba: Ok, is the solution moving my domainname line to a pre-start section and then just using an exec rather than script section?
<plautrba> Omahn: i think it is
<Omahn> plautrba: I'll give that a try then, thanks.
<Omahn> In addition to the above change, a switch to 'fork daemon' appears to have resolved my issue.
#upstart 2010-06-11
<Omahn> What's the correct way to abort startup of an upstart job in the pre-start script?
<Omahn> Ah, possibly just 'exit 1' ?
<Omahn> Seems to work. :-)
<ion> Thatâs okay for an error. For a graceful abort, run âstopâ.
<Omahn> ion: I was just going to ask about that. So, for a misconfiguration in the setup of a given daemon, detected during pre-start, I should use exit 1. If the daemon is simply disabled in the daemon, I should use 'stop' and that will prevent the 'exec' from firing. Is that correct?
<Omahn> *disabled in the configuration, that should say
<ion> Yep
<Omahn> ion: Great, thanks.
<ion> Also note that the scripts are run with -e. In some cases, exit 1 may be redundant since the shell would exit with a non-zero value anyway.
<Omahn> Noted, thanks.
<yarihm> hi everybody
<yarihm> I'm currently trying to get a fedora 13 container working in openvz. I'm new to upstart but if I got that correctly, the jobs are defined under /etc/init/<name>.conf in a pretty straight forward way. From what I can tell (initctl list) openvz starts init properly but that in turn is only able to start one of the jobs (the one that spawns mingetty), the others are listed as 'stop/waiting'. When I try to start the stopped job
<yarihm> s I get 'initctl: Job failed to start' with no place to start debugging.
<Omahn> yarihm: From my limited knowledge, it's probably something in one of your script sections exiting with non-zero. Maybe try increasing the log level of upstart with 'initctl log-priority debug' and then watching the log files. (/var/log/daemon on ubuntu, not sure on Fedora)
<yarihm> Omahn, actually I tried that, too :) Let me try again, but I think initctl fails to log anything even though I started the syslog daemon
<yarihm> Let me give it another shot
<yarihm> ok, it doesn't log much actually, but I tried it with a test-job and that seems to be working
<yarihm> I wrote a task with a pre-start script that touches a file in /tmp and a script that touches a different file in /tmp. when starting that job, initctl outputs
<yarihm> [root@backend99 init]# initctl start test2
<yarihm> test2 stop/waiting
<yarihm> if I add something that doesn't detach (top) in the script, it fails. Is the expectation that the started daemon/binary detaches or not?
<yarihm> also: there's no logging anywhere about why this procedure fails
<ion> top probably just dies immediately due to there not being a terminal.
<yarihm> ah
<yarihm> I see some logging in /var/log/messages BTW
<ion> Task jobs arenât for daemons, service jobs are.
<yarihm> Uh, i see some issue here anyway, the mingetty-task seems to respawn because it tries to attach to the wrong device node
<ion> gettys should be services, not tasks.
<yarihm> what are tasks for then?
<ion> Task is something you expect to run once and then end when started. Service is something you expect to keep running indefinitely when started.
<yarihm> I removed the getty thing now, it's not needed in a openvz-container anyway AFAICT
<ion> E.g. a job that runs sysctl -p on startup would be a task, since it should happen once and be done. Gettys are more like daemons, so they should be services. They should additionally respawn, so you get a new getty when you log out from a session.
<yarihm> mhm, makes sense
<yarihm> I copied an openvz-task from an ubuntu template (trying to get fedora core 13 running), that has this section here:
<yarihm> task
<yarihm> pre-start script
<yarihm> #mount -t devpts devpts /dev/pts
<yarihm> #mount -t proc proc /proc
<yarihm> if [ ! -e /etc/mtab ]; then
<yarihm>         cat /proc/mounts > /etc/mtab
<yarihm> fi
<yarihm> end script
<yarihm> however, when trying to start that openvz task, I get
<yarihm> init: openvz pre-start process (82) terminated with status 32
<yarihm> ... how can that be? /etc/mtab actually evaluates to true
<yarihm> I mean [ -e /etc/mtab ] does
<ion> Just after the pre-start script line, add:
<ion>   exec >/dev/something.log 2>&1
<ion>   set -x
<yarihm> you mean exec >/tmp/something.log I guess?
<ion> /dev is a safe assumption of something writable, /tmp might not be. If you know /tmp is writable, sure.
<yarihm> ah, ok :)
<yarihm> well, it seems that the if statement just evaluates to 32 ... whatever, I added 'true' before end script so this works now. Now it's the main-script that fails, I'll try to debug that
<ion> Curious. I donât see how the if statement could return 32.
<yarihm> yeah, me neither
<yarihm> is the script running as if it were 'set -e'?
<yarihm> in other words, does it terminate with the first command that returns non-zero? maybe the mount commands return 32 (but they are commented out)
<ion> Yes, -e is on by default.
<ion> The only things i can see failing are cat opening /proc/mounts for reading and the shell opening /etc/mtab for writing.
<yarihm> well, actually since the file /etc/mtab exists that should never be an issue
<yarihm> cu guys l8er
#upstart 2010-06-12
<thewoolleyman> anyone home?
<thewoolleyman> how can I tell upstart to call a stop script which is different than a start script?  e.g. start is /bin/start-myservice and stop is /bin/stop-myservice?
<ion> pre-stop exec /bin/stop-myservice. But make sure Upstart actually tracks the process started by start-myservice. The easiest way is to make it not daemonize.
<thewoolleyman> ion: if I make it not daemonize upstart will keep track of the process?
<ion> Yes. And if you add a respawn stanza, Upstart will also restart it if it dies.
<thewoolleyman> ion: the docs are extremely unhelpful on that.
<thewoolleyman> ion: so what does the stop action do by default?
<thewoolleyman> ion: how does it know what to stop and how?
<ion> It runs the pre-stop command, if any, then sends SIGTERM to the main pid, then sends SIGKILL if itâs still running after a timeout and finally runs the post-stop command, if any.
<ion> The main pid being the one âstatus jobnameâ prints.
<thewoolleyman> ion: ok, thanks.  the docs don't make that clear at all.  where should I submit a doc bug/patch?
<ion> https://launchpad.net/upstart
<thewoolleyman> ion: thanks a lot for your help.
#upstart 2010-06-13
<crankharder> this file is /etc/init/god.conf : http://pastebin.com/V0caSUg9 -- however it's not actually starting god, there's nothing in syslog about it blowing up either -- however after booting I can "sudo start god" just fine, any ideas?
<crankharder> system is default ubuntu 10.04 server booting into RL 2
<mbiebl> crankharder: you can't specify multiple start on or stop on conditions
<mbiebl> only the last line will match
<mbiebl> this behaviour changed between 0.3 and 0.6
<mbiebl> crankharder: use something like
<mbiebl> start on runlevel [2345]
<mbiebl> stop on runlevel [06]
#upstart 2011-06-07
<sveinse> According to man 5 init, I can use "manual" to prevent a service to start automatically. But if I do, initctl start does not recognize the service. (I'm running on ubuntu natty)
<sveinse> How can I add an upstart service which can only be started manually?
<sveinse> Nope. If I add "manual" below "start on" in my mcbapp.conf file, init responds with "start: unknown job: mcbapp"
<sveinse> Take manual away, and everything's fine again
#upstart 2011-06-09
<tylerflint> I'm hoping someone could point me in the right direction...
<tylerflint> I'm trying to change the reload signal to USR2
<JanC> tylerflint: I think that's currently not possible, but will be in the future
<tylerflint> thanks
<tylerflint> what language is upstart written in?
<tylerflint> and is it open for collaboration?
<JanC> tylerflint: it's written in C
#upstart 2011-06-10
<wraiden> Hello :)
<wraiden> *reading job_emit_event*
<Keybuk> wraiden: good luck
<Keybuk> the last person who went in there never came out
<wraiden> hehe
<wraiden> i think i have found the point to add the alias handling
<Keybuk> it would be in there, yes
<wraiden> i think i move the environment construction into an helper as i have to construkt the environment for the job event itself and all aliases that might be set...
<wraiden> or is it possibe to overwrite the JOB in an already constructed environment ?
<wraiden> that would make it very easy *G*
<Keybuk> yeah, you can keep setting JOB to overwrite it
<Keybuk> see environ.c
<wraiden> and it will hold its position as the first env var on the event?
<Keybuk> yes
<Keybuk> see environ_add()
<Keybuk> (provided you go through that function, of course)
<Keybuk> environ_set() calls environ_add() fwiw
<wraiden> nice and handy *g*
<wraiden> where does the code actualy block until all jobs that hook into a blocking event are processed?
<Keybuk> the code doesn't block per-se
<Keybuk> job_change_state sets job->blocker to the return value of job_emit_event
<Keybuk> and doesn't change state to the next one, so ends
<Keybuk> event_finished() is what, when an event reaches zero blockers, calls job_change_state to unblock the job
<wraiden> if i implement the aliases as multiple independent blocking events...
<wraiden> then i have to check if no other alias event is still blocking
<wraiden> mhm
<Keybuk> interesting
<Keybuk> yeah you may have to extend things
<wraiden> if i understand the code right than i can add multiple blocking events to the main jobs event->blocking
#upstart 2012-06-04
<tcr> If you have a post-start script which is blocking (e.g. polling for a non-existing resource), and you stop the job when it's in "start/post-start" (with two processes associated to it, the main process, and the post-start process), the job will change into "stop/post-start" with *both* processes still running.
<tcr> Similar with a pre-start script.
<tcr> I find this behaviour surprising. I'd have expected the post-start process along the main process to get killed in this situation.
<tcr> (Upstart 0.6.5)
<tcr> I wonder if there's a detailed state diagram somewhere, along the lines of the one http://upstart.ubuntu.com/wiki/JobStates but that has its edges labelled with the conditions to trigger that particular state transition
#upstart 2012-06-06
<greylurk> So, i'm trying to write an upstart script for a process, and it appears to fork 56 times before settling in to a single PID.  Is there any hope of writing an "expect" statement to deal with it?
<ion> Can you tell it not to do that? :-P
<greylurk> I'm not sureâ¦ I'm trying.
<JanC> seems like that process is somewhat insane  ;)
<greylurk> It's actually "clone"ing not "fork"ing, so it might just be a bunch of threads to read configurations and such.
<greylurk> I'm investigating.
<JanC> there are always tricks with pre/post start/stop & script you can use (see the cookbook for some ideas)
<swine_> hey, what would cause a pre-run section of an upstart config file not to ever run ?
<roderick__> hi, is there a way to give an instance a default value in the upstart script, so it's optional for "start myapp ..."?
<qzio> I'm trying to get nginx to use upstart, not sure what I've done but doing start nginx or stop nginx just sits there doing nothing.
<qzio> can't find anything in syslog either, or the nginx log.
<qzio> I've installed nginx using the passenger gem, so it sits in /opt/nginx.
<qzio> I'm using the upstart script described in http://wiki.nginx.org/Upstart with the modification of DAEMON=/opt/nginx/sbin/nginx
<JanC> qzio: *s*bin?
<JanC> are you sure it's not in /opt/nginx/bin/ instead?
<qzio> yes I'm sure.
<qzio> I can get nginx to start. but not to stop.
#upstart 2012-06-07
<xaka> hello there! i have service A and B, and i want A to be running when B starts. the problem is that i can't modify A's config file. what can i do?
<xaka> i know i could use "start on A" in B config file, but i dont want to start it automatically when A starts
<lnykryn> why can't you modify A?
<xaka> it's provided by ubuntu (the package) so i can't/don't want to modify it
<xaka> i need someting like "REQUIRED" in rcNG or "dependencies" in SMF
<lnykryn> xaka: so you can't override it by override file
<xaka> nope, because that means i would have to maintain it for ever
<xaka> i just need to start A if it's not running when i start B
<lnykryn> another ugly solution would be to start a with pre-start stanza
<xaka> that is what i'm looking at at the moment :) but that is really ugly, agree
<xaka> it's like how packaging works - if you install B and it depends on A, apt-get will install A, but B wont be installed if only need A
<mitsuhiko> hey everybody. how do i run jobs under a specific user?
<jY> mitsuhiko: what version of upstart?
<mitsuhiko> jY: whatever comes with ubuntu precise
<jY> setuid and setgid
<jY> setuid username
<jY> for example
<mitsuhiko> jY: i apparently fail very much at googling. where do i find docs for this?
<jY> http://upstart.ubuntu.com/cookbook/#setuid
<jY> it is new in 1.4
<mitsuhiko> thanks
<mitsuhiko> jY: i guess it would make sense to remove the wiki at this point
<mitsuhiko> the stuff there is heavily outdated
#upstart 2012-06-08
<xaka> why "stop" would hang?
<xaka> start works, tracking PID is corret, when i do stop the process finishes succesfully, but the command itself hangs 
<jodh> xaka: what does "initctl status <job>" show? maybe you 'post-stop' is still running?
<xaka> i don't have post-stop. after some time i stopped it by Ctrl+C. status is "stop/killed, pid ...". then i tried to start it again and even start hanged
<jodh> xaka: can you show me the conf file?
<xaka> jodh: http://pastebin.com/nMV1s7YD
<jodh> xaka: firstly, you need to be careful with those pre-start commands since if any fail, the job will not run. See http://upstart.ubuntu.com/cookbook/#develop-scripts-using-bin-sh
<xaka> jodh: i understand, but that pre-start is the only solution for my case that i was talking about yesterday here
<jodh> xaka: are you sure that Upstart is tracking the pid correctly? Does "nms" definately fork only once?
<xaka> it starts with no issues, after that "status" shows correct PID
<xaka> it even stops the process, but "stop" command doesn't finish
<xaka> jodh: i have the simple script that you can use to reproduce the situation, let me paste it
<xaka> jodh: http://pastebin.com/jityDGxg ( don't ask why it's been written in this way :) )
<xaka> jodh: btw, are you going to add support for dependencies like SMF has? i was talking/complaing about it yesterday. i want to say that B depends on A so when B is started and A isn't running yet, A has to be started first.
<xaka> that is the only reason i have that pre-start hook - i don't want (and i haven't) to modify ntp/mongodb conf files, but i still want to be sure that the services are running 
<jodh> xaka: the problem is that your perl script is attempting to "manage" the service by killing the child. However, you've told Upstart that the child PID *is* the service so Upstart is tracking the forked child process. Either remove the "expect fork" or stop the perl script from killing the child - Upstart will do that for you as it kills the process group.
<xaka> jodh: the wrapper doesn't kill the child (those INT/TERM handles only for developers). the simple is chain is: fork->exec->waitpid
<xaka> btw, does the upstart kill the process group of forked child or the parent?
<jodh> xaka: please see my comments above.
<kevmo> How can you tell upstart to get the pid from a pid file on the stop command
#upstart 2013-06-03
<stgraber> jodh, xnox: So we now have user session support in kubuntu, xubuntu, lubuntu and ubuntu-studio. Just have ubuntu-gnome and gnome-session-fallback left.
<stgraber> then flip all of those by default in a couple of weeks and we'll be able to assume that anything that all official flavours use upstart user sessions
<xnox> stgraber: great. I shall start testing starting ubiquity under all of those.
<stgraber> ubuntu-gnome done (existing gnome-session job works with just "gnome" added to upstart-xsessions)
<stgraber> and gnome-fallback tested too, that should be all for all supported flavours
#upstart 2013-06-04
<bencc> setting nofile limit in /etc/security/limits.conf has no effect on a server started by upstart?
<jodh> bencc: Upstart doesn't support PAM directly (although it does support rlimits and OOM limits), but you can trigger it to be used if you wish using su/sudo/etc. See http://upstart.ubuntu.com/cookbook/#changing-user.
<bencc> jodh: I increased nofile limit in limits.conf but checking /proc/<pid>/limits show it still has 1024 limit
<bencc> when adding this to my upstart script the limits are raised limit nofile 30000 30000
<bencc> is this specific to upstart or do I need to do the same for init.d script as well?
<jodh> bencc: the "limit" stanza is upstart-specific, but you can easily convert it to the shells ulimit syntax.
<bencc> jodh: do I put it inside the script ... end script block?
<bencc> or in the main block?
<jodh> bencc: ?
<bencc> jodh:  is this how I use "limit" ? http://dpaste.com/1210781/
<bencc> or do I need to put it between lines 20 and 25?
<jodh> bencc: it's an upstart stanza, so it does needs to go outside any script stanza as the shell won't understand it. it's fine on line 11 as shown. I thought you already said you had that working??
<bencc> jodh: until 10 minutes ago I only used /etc/security/limits.conf
<bencc> now I'm trying to understand if I need to do the same for nginx in /etc/init.d/nginx 
#upstart 2013-06-05
<xnox> jodh:  https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html#Parallel-Test-Harness
<jodh> ack.
<jodh> xnox: I've just updated lp:~jamesodhunt/upstart/serialise-remaining-objects with the new tests we discussed yesterday. Can you review when you get a chance so we can discuss the backporting after lunch?
<xnox> jodh: right. I was starting to rereview your changes from 18h ago. will pull again.
<jodh> xnox: thanks
<xnox> jodh: hmm..... shouldn't there also be: upstart-1.8 +full_serial +apparmor? since as soon as we merge this branch that's what the current format is going to become
<jodh> xnox: yep - on it...
<jodh> ok - branch updated.
<xnox> jodh: looks good. I guess none of the jobs use apparmor_switch yet?! all dumps just have it as "null" and thus, well it's just forwards compatible stanza then =)))))
<jodh> xnox: correct. I guess I could add in some apparmor_switch values for completeness...
<xnox> jodh: do you just run your store-dump patch to generate these dumps? are those merged into lp:upstart already
<xnox> jodh: to be honest no need, as there are other tests which correctly test strings in that field.
<xnox> and i'm sure that we are able to serialise/deserialise strings =)
 * xnox prefers real dumps vs artificially constructed dumps.
<jodh> xnox: that was my view :)
<xnox> ah, write_state_file is in this branch.
<xnox> jodh: how do you distinguish between: confsources serialised and fail to deserialise vs not-present.
<xnox> and is it possible to distinguish.
<jodh> xnox: I think we'd need the STATE_VERSION bits to distinguish between those 2 scenarios reliably.
<xnox> jodh: hmm... i would have thought conf_source_deserialise would for example return -1 if 'conf_sources' key is not found in json, and -2 if 'conf_sources' key was found but failed to deserialise in any other way.
<xnox> cd ../
<jodh> xnox: there is no point distinguishing in fact since we don't know the serialisation format version of the init which is feeding us data. Hence, we error on any unexpected scenario and let the caller decide what to do. And since we only latterly added serialisation of ConfSources but don't have a version number, the best we can do is display a warning.
<xnox> jodh: that's  not what I was after. if we do feature detection, and 'conf_sources' key is present in the serialisation format, we expect conf_source_deserialise_all to succeed. Yet, if for example, somewhere inside conf_sources the stream got corrupted (single bit flip in ram), the call to conf_source_deserialise_all will fail, yet state_from_string will return success.
<xnox> which is imho wrong.
<xnox> this is for the case of latest upstart doing stateful rexec to latest upstart.
<xnox> jodh: something like this? http://paste.ubuntu.com/5735811/
<jodh> xnox: I guess we could do that, but we'd need to do a bit of rework to make the code consistent in that respect.
<xnox> jodh: so is above unreasonable?
<jodh> I guess it makes sense to add that check. We still can't detect of course that the ConfSources are missing when we actually expect them to be present, but I can add the extra check.
<xnox> jodh: sure, and that's kind of a limitation of feature-based-testing. i wonder if we should be checksumming the serialisation =)
<slangasek> xnox: if they're absent and supposed to be present, that's not going to be a bit-flip error :)
<slangasek> jodh, xnox: reading scrollback, I agree that we want to distinguish between "this new bit is absent" and "we failed to deserialize this bit".  The -2 == warning isn't very idiomatic, however.  What about just returning 0 for this case?  Or, having the caller check for conf_sources and skip the call to conf_source_deserialise_all() if absent?
<jodh> slangasek/xnox: yeah, I vote for the latter as there is already precendent for that.
<xnox> slangasek: yeah "-2" is a bit out of the blue. I prefer "having the caller check for conf_sources and skip the call to conf_source_deserialise_all() if absent?" over the '-2' hack.
<slangasek> ok
<jodh> xnox: it's a shame as it imbues the caller with knowledge of the format of the json, but as you would say "meh" :)
<slangasek> then we all agree :)
 * jodh is on it...
<jodh> slangasek/xnox: branch updated.
<xnox> jodh: looks good to me.
<xnox> jodh: are you planning to make a release, or simply take a single cherrypick of this both into raring & saucy?
<jodh> xnox: well, I had planned on making a release once all the o/s branches had been merged. However, as I'm away for a while, maybe a cherry-pick would be the most expeditious option?
<slangasek> xnox: so given that jodh is effectively on [vac] already, I think we need to go the cherry pick route
<slangasek> bonus: that means we get to test the cherry-pick in saucy /before/ SRU to raring
<xnox> ack.
#upstart 2013-06-07
<jessepollak> does anyone know how to create an upstart script that contains a command which needs a password (PEM phrase for SSL certificate)?
<SpamapS> jessepollak: For apache you can have apache ask for a passphrase via a program..
<SpamapS> jessepollak: for other things, you'd probably have to hack that in.
<jessepollak> ah, shucks. I'm not using apache
<SpamapS> jessepollak: since it is a manual step anyway, you probably are better off just starting the program from a CLI.
<SpamapS> jessepollak: note that there are projects to make this kind of thing more automatable. See: Barbican
#upstart 2013-06-08
<walltender> This is my last hope here, some one tells me this is an upstart error: the second screen shot: http://unix.stackexchange.com/questions/77945/what-prevents-my-system-from-shutting-down
#upstart 2013-06-09
<walltender> Dear upstart expert, will some one tell me what this means?
<walltender> http://i.stack.imgur.com/rCLl1.jpg
<walltender> People says I shall ask upstart devs.
#upstart 2014-06-02
<afournier> hi
<afournier> is it possible to get exec exit code in post-start ?
<afournier> no it's not because post-start is runned before job is started
#upstart 2014-06-04
<jodh> xnox: Still having problems with my ->valid branch but it's demonstrated that current upstream is still iterating through job_change_state() too many times; try applying http://paste.ubuntu.com/7588618/ and booting!
<xnox> jodh: we don't gurantee clean process_data[process] at that point.
<xnox> jodh: we only reset it to null after a job is starting from stopped.
<jodh> xnox: the point is that we're calling job_process_data_new() multiple times for the *same* job process
<xnox> true.
<xnox> but old one might be invalid at that point already. hm, need to transverse through this again.
#upstart 2014-06-05
<xnox> jodh: when is unmounted-remote-filesystems emitted? before or after rc job for shutdown?!
<jodh> xnox: it's emitted by /etc/init.d/umountnfs.sh :-)
<xnox> jodh: excellent!
<nicksloan> I'm getting a syntax error on the following line: env MYLIST=(a b c d e f)
<nicksloan> any ideas as to why?
<grobe0ba> Ubuntu 14.04 LTS, amd64, latest updates, upgrades, etc. Using only default repos. Upstart fails to find new or use new services added. I have added none of my own, everything is via apt. I have in no way modified this installation. initctl reload-configuration fails to make even a small difference. In this instance, the package is vsftpd.
<grobe0ba> initctl check-config /etc/init/vsftpd.conf  or check-config vsftpd  returns Invalid job class
<grobe0ba> any commands to 'service' return Unknown job
<grobe0ba> does anyone have any pointers?
#upstart 2014-06-06
<jodh> xnox: Hi - have you had a chance to look at that async issue (iterating through job_change_state() too many times?)
<xnox> jodh: nope. (you mean the one exposed when dropping valid from process_data? or the one from the racy test-case?)
<xnox> jodh: the builds are all happy, but on powerpc. And alas, I cannot reproduce it on the porter box for powerpc.
<jodh> xnox: the former. That issue should be in lp:upstart too.
<xnox> powerpc builds hang in test_job_process and i'm not sure why.
<jodh> xnox: saw the ppc MP - I'm not sure that's going to be reliable. I need to pick over that test case more closely...
<jodh> xnox: I thought we removed the state_only param from job_process_terminated()... ?
<xnox> i did, it caused regressions, we didn't merge.
<xnox> it was the same type of story as with ->valid
<jodh> xnox: sure? seems to be in both lp:upstart and lp:upstart/async
<xnox> jodh: what do you mean? removing state_only was in a merge proposal, that didn't get merged. Thus lp:upstart still has state_only arg on job_process_terminated
<xnox> and lp:upstart/async is fully merged into lp:upstart now, so shouldn't be used any more.
 * xnox requested ppc64el and arm64 to be added on daily non-virt builds
<jodh> xnox: sorry - misremembering the order of changes :) We need to resolve http://paste.ubuntu.com/7588618/ - the behaviour is incorrect atm fwics - we should not be allocating these objects twice. Do you want me to look at this?
<xnox> looks like arm64 is also hanging - https://code.launchpad.net/~canonical-foundations/+recipe/upstart-daily-nonvirt
<xnox> =(
#upstart 2014-06-07
<ZacS1234> hi
<ZacS1234> I have an upstart script that I am trying to build that is behaving strangley. I am trying to use curl to fetch the EC2 instance metadata in the pre-start script section, but when run on boot, /etc/environment is never written to, the script works fine if I run it once logged in. the script is:
<ZacS1234> http://pastebin.com/SgQeJN4W
<ZacS1234> any ideas?
#upstart 2015-06-05
<l3on> Hi All.. I'm trying to run bash via upstart and prevent users to have a max num of process children in that session .. is it possible you think ?
<xSmurf> l3on: sounds like you want cgroups
<l3on> that's what I'm looking at right now ... xSmurf 
<l3on> but I can't find a max.tasks settings
<xSmurf> yeah now that I think of it I don't think there is such a setting
<xSmurf> because it could be dangerous as the kernel can't tell whether a process is actually critical or not, CPU limiting is not good enough for you?
<l3on> So, since I want prevent forkbomb .. which limits of cpus and memory you think can be used ?
<xSmurf> I see
<xSmurf> you want a per user ulimit I guess
<l3on> It's odd .. my users connect to my docker with same username
<l3on> so I can't have it by user, I have to create a cgroup at each connection
<l3on> I would like to understand what limits can I use ..
<xSmurf> if they are all sharing the same user then I don't know
<l3on> they are
<xSmurf> if they had their own accounts then ulimit would work
<l3on> I know .. just my architectures does not work with ulimit
<xSmurf> why can't they all have their own user and share a group instead?
<l3on> dunno, not my choice
<xSmurf> I see
<xSmurf> in that case I have no idea, sorry
<mustmodify> Hey, I've been using upstart in trivial ways for a while. I'm looking at using it to manage resque *and* my www service... is there an easy way to have `sudo start app` start both `app-resque` and `app-www` ?
#upstart 2016-06-06
<flaf> Hi, I have a little problem with a upstart job in ubuntu trusty 1.12.1.
<flaf> When I try to start a job (start ceph-osd id=x) I have an curious error, like if upstart tried to use an old version of the job.
<AnrDaemon> pastebin the job file please.
<flaf> ok.
<flaf> AnrDaemon: http://paste.alacon.org/41419
<flaf> AnrDaemon: the point is in /var/log/upstart/ceph-osd-ceph_13.log where I have â/proc/self/fd/9: 8: /proc/self/fd/9: /usr/libexec/ceph/ceph-osd-prestart.sh: not foundâ.
<AnrDaemon> I'd remove "respawn" stanzas until you 101% sure it works as intended. Before bad things happen.
<AnrDaemon> That's not your job log.
<flaf> And the file â/usr/libexec/ceph/ceph-osd-prestart.shâ is not mentioned in the job file _but_ it was present in the previous version of the job start. Because I have updated the ceph package.
<AnrDaemon> You don't even log anything in your job, to begin with.
<AnrDaemon> upstart job logs are named after the job, with optional instance name added after it.
<flaf> AnrDaemon: I'm not sure to understand. I have to edit the job file and remove the 2 "respawn" stanzas, correct?
<flaf> And I retry to start my job?
<AnrDaemon> And i strongly suggest moving "instance" and "export" stanzas up.
<AnrDaemon> Comment them out.
<AnrDaemon> And add "console log" while you're at it.
<flaf> If I add "console log", where the log will be created?
<AnrDaemon> Where you expect them.
<flaf> in /var/log/upstart/ ?
<AnrDaemon> Of course :D
<AnrDaemon> Also, I'm not exactly sure, what upstart is going to do with "instance ${cluster:-ceph}/$id"
<flaf> I have tried. After âstart ceph-osd id=13â, I have the error âstart: Job failed to startâ and no log is created in /var/log/upstart/.
<AnrDaemon> It is supposed to be one variable, passed to the job from parent. Do make a check.
<flaf> The only file updated in /var/log/upstart/ after my âstartâ command is /var/log/upstart/ceph-osd-ceph_13.log
<flaf> and during my âstartâ command the line â/proc/self/fd/9: 8: /proc/self/fd/9: /usr/libexec/ceph/ceph-osd-prestart.sh: not foundâ is added in /var/log/upstart/ceph-osd-ceph_13.log
<AnrDaemon> init-checkconf your job file.
<flaf> As I said the ceph package has been updated (apt-get) and the new version of /etc/init/ceph-osd.conf doesn't contain /usr/libexec/ceph/ceph-osd-prestart.sh. But the previous version of /etc/init/ceph-osd.conf (before the âapt-get upgradeâ) contains this string. Is it possible that the âstartâ command still use the previous and deleted version of /etc/init/ceph-osd.conf ?
<flaf> init-checkconf /etc/init/ceph-osd.conf => âFile /etc/init/ceph-osd.conf: syntax okâ
<flaf> In the âpre-startâ stanza, I have tried to add âecho test >/tmp/logâ etc. but after the âstartâ command no /tmp/log was created.
<flaf> AnrDaemon: another curios behavior: âmv /etc/init/ceph-osd.conf /root ; start ceph-osd id=13â => âstart: Job failed to startâ
<flaf> AnrDaemon: normally the error should be âstart: Unknown job: ceph-osdâ.
<AnrDaemon> That's why am I not using these shortcuts. Only initctl, only hardcore.
<flaf> (because the file is moved to /root)
<flaf> initctl start ceph-osd id=13 => initctl: Job failed to start
<flaf> same message.
<flaf> In fact, I have the feeling that a reboot could solve my problem. But I'm not sure and this a server in production.
<AnrDaemon> You can force upstart to reconsider the jobs.
<flaf> ah, how?
<AnrDaemon> man initctl
#upstart 2016-06-10
<RainMan28> Hello, I am trying to get an upstart script to run a bash script, and for some reason I get completely different output when running the bash script via upstart versus me just running the bash script from command line. Both the upstart and me running the script manually are done under the user root.
<bfig> hello, how can I start an upstart job in a specific directory?
<AnrDaemon> bfig: chdir
<AnrDaemon> It's all in http://upstart.ubuntu.com/cookbook/
#upstart 2016-06-12
<hallyn> slangasek: hey.  so, just curious.  is there a current maintainer?  i assume not jodh, nor xnox...
<slangasek> hallyn: upstart is no longer being actively maintained, no
<AnrDaemon> â¦
<hallyn> slangasek: and libnih?
<hallyn> i wonder whether 'apt rdepends libnih1' is an accurate indicator of who uses it
<hallyn> if so i can switch it over to use epoll and switch over the users, without the added complexity of supporting two mainloops
