#upstart 2007-01-22
<chillywilly> anyone else run edgy on a server and notice that when you turn quiet off but the splash screen on that you do not always get pass/fail output for each script/job?
<chillywilly> is there anyway to make the terminal output any prettier?
<chillywilly> or more consistent for that matter
#upstart 2007-01-27
<_ion> mbiebl: Hi. Did you receive my message?
<mbiebl> yeah
<mbiebl> I'm looking at it atm.
<_ion> Thanks
<mbiebl> And already filed a bug against pkg-config
<mbiebl> ;-)
<mbiebl> Seems as if pkg-config --variable handlersdir deskbar-applet is not working on Debian/Ubuntu
<_ion> Hm, worksforme. Anyway, the change i did in the attached diff.gz doesn't need it. I thought it isn't necessary to build-depend on the whole deskbar-applet package when all you need is the knowledge of the dir /usr/lib/deskbar-applet/handlers.
<mbiebl> What platform are you using?
<_ion> Feisty on plain x86
<mbiebl> Had some problems loading the deskbar-applet on feisty
<mbiebl> Which needs a small patch to fix.
<_ion> Both deskbar-applet and the plugin from the tracker 0.5.4 package work for me.
<mbiebl> Yeah, because you precompile tracker-handler.py. 
<_ion> in postinst, yes.
<mbiebl> If you only install the python file it will complain that the file has a wrong encoding and it doesn't load the applet.
<mbiebl> There are also two lintian warnings, which are simple to fix. 
<mbiebl> Besides that, your patch looks fine.
<mbiebl> Oh, one thing though: libdeskbar-applet is Architecture:all
#upstart 2008-01-23
<LowLander> where can i find what syntax the config files for 0.3.9 have 
<LowLander> some how i have the feeling all the stuff in the wiki is for newer or older version 
<AlexExtreme> Keybuk: some interesting stuff for you about Upstart in Fedora - looks like they plan for it in Fedora 9:
<AlexExtreme> http://screwyouenterpriseedition.blogspot.com/2008/01/upstart-in-fedora.html
<AlexExtreme> http://fedoraproject.org/wiki/Features/Upstart
<Keybuk> AlexExtreme: yeah they do
 * Keybuk has been talking to them a lot :-)
<AlexExtreme> ah :)
 * AlexExtreme looks forward to seeing it in Fedora (I use it on my desktop now)
<AlexExtreme> bbl
<LowLander> does anybody have any pointers to docu for version 0.3.9 ?
<LowLander> i am trying to setup upstart on my embedded system but can't find any docu that actually fits a certain version , just plans and specs and so on that do not work with 0.3.9
<Keybuk> what kind of documentation are you looking for?
<Keybuk> there's the "getting started" page on the website
<Keybuk> that covers 0.3.9
<LowLander> well i was trying to figure out how to start somethings depending on two other things
<LowLander> but that only seems to be possible in "trunk"
<Keybuk> right, Upstart is still in development
<Keybuk> you can do dependencies though
<Keybuk> if X depends on Y, X can have "start on Y started"
<Keybuk> err start on started Y
<Keybuk> or if you want start X to start Y, Y can have "start on starting X"
<LowLander> yeah but not "start A if  B or C have started"
<Keybuk> sure
<Keybuk> start on started B
<Keybuk> start on started C
<Keybuk> "OR" is easy
<LowLander> uhhh AND i mean
<Keybuk> and is only possible in trunk
<LowLander> yeah OR worked
<Keybuk> start on started B and started C
<LowLander> any idea on the arrival time of a next stable version ?
#upstart 2008-01-24
<kimrhh> hi, I'm having some troubles with upstart tests, 4 of them are failing
<kimrhh> first one concerns the with of the pty, where the test tests if the width equals 40
<kimrhh> it reads the COLUMNS env var, which is set to 210 on my system
<kimrhh> so, why does it need to be 40 ?
<kimrhh> I have the details here: http://rafb.net/p/fzMvim46.html
<Keybuk> kimrhh: please file bugs for each of the four failures, attaching relevant information
<Keybuk> include details of your system, library versions, etc.
<kimrhh> Keybuk: ok
#upstart 2008-01-25
<to0om> hi all
<to0om> how can i customize upstart?
<to0om> i'd like to have the kernel modules loaded earlier in the boot process
<ion_> keybuk: An idea occured to me: how about disallowing nih_ref when the object has a parent (so that it always has a reference count of 1 and nih_unref would be used just like nih_free is now â not callect directly on the object), thus reference counting could *optionally* be used with parentless objects?
<ion_> Children would be released whenever their parent is released, and the refcounting may be used with the parent when appropriate just by using nih_ref.
#upstart 2009-01-20
<sadmac2> notting: read my blog?
<notting> saw it. have not looked at the code.
<sadmac2> cool
<Keybuk> ion_: I wrote a new allocator over the weekend ;)
<ion_> Ooo
<sadmac2> Keybuk: get my email?
<Keybuk> sadmac2: yes.  I still think your state machine is crazy
<Keybuk> ion_: nih_alloc and nih_free still work as before (alloc with parent, free anyway)
<Keybuk> but now you have nih_alloc_ref (add a new parent), nih_alloc_unref (drop a parent) and nih_discard (throw away only if there are no parents)
<sadmac2> Keybuk: and I still haven't seen you propose a mechanism behind that pretty syntax of yours
<ion_> keybuk: Alright
<ion_> keybuk: Does unref automatically discard?
<Keybuk> ion_: yes
<Keybuk> sadmac2: err, I've told you exactly what I'm going to do - it hasn't changed since plumbers
<sadmac2> Keybuk: really? because I haven't read about it the same way twice
<sadmac2> depsolving keeps disappearing and reappearing...
<Keybuk> "depsolving" ?
<sadmac2> if you start foo, which depends on bar, does it start both or just error and tell the user "Fix it?" I've heard you tell it both ways
<Keybuk> no you haven't
<sadmac2> there was an auto keyword at plumbers
<sadmac2> that vanished last time we spoke
<Keybuk> err, that vanished after a lengthy debate both on the mailing list and on here
<sadmac2> must've missed it here. Dunno where it was on the mailing list
<Keybuk> "upstart configuration", Nov 2008
<sadmac2> ah, so its add a manual now
<Keybuk> no
<sadmac2> the functionality is still there then
<Keybuk> it's treat disabling jobs as a separate thing to their definition
<Keybuk> a sysadmin can flag a job as disabled
<Keybuk> bit more like SMF
<Keybuk> I ran it by our server team here, their eyes lit up with joy, so it's a keeper
<sadmac2> ok, so the fundamental difference is in your system states/jobs are first class objects
<sadmac2> where my system essentially doesn't have a first class object
<sadmac2> can you solve all the use cases with yours? mounting? (dbus I know you've done)
<Keybuk> I suspect that leads to a lot of differences, both fundamental and trivial
<sadmac2> I'm fairly certain yours could be implemented on top of mine (not that we should, but its very significant that we can).
<Keybuk> stateless mounting still can't be solved in yours, so I don't see that to be a useful example
<sadmac2> can you mount at all?
<sadmac2> can you manage the state for stateful mounting?
<Keybuk> yes, of course
<sadmac2> 0.5 can't do /either/ that's the importance of the case
<Keybuk> I can manage the state for stateful mounting without Upstart at all
<Keybuk> just by using udev and some shell scripts
<Keybuk> so I'm not sure that's a useful example either
<sadmac2> I don't know that you can easily express virtual states either (explanation follows):
<sadmac2> so my usecase would be SELinux
<sadmac2> its damn useful to know if the system is enforcing or not and act based on this.
<sadmac2> you can check if the system is enforcing by running getenforce
<sadmac2> but its hard to get an event stream from which you can derive it
<sadmac2> in my model its not hard to describe states coming from anywhere. so you could define:
<sadmac2> selinux: test-by /usr/bin/getenforce
<Keybuk> and it would run that how many times a second?
<sadmac2> Keybuk: it would run it when it needed to know. When the user lists states or when dependency checking is interested in the selinux state
<sadmac2> the rest of the time selinux would be neither up nor down
<sadmac2> its "quantum." neither running nor not running until observed
<Keybuk> it needs to know continually
<Keybuk> otherwise how would it know when to stop a service because selinux is no longer being enforced?
<Keybuk> also would it only check that if a sysadmin issues a start command?
<Keybuk> otherwise when would it check that for other reasons?
<sadmac2> when the service came up
<sadmac2> Keybuk: and this can be used in combination with regular ons and when (event1..event2)
<Keybuk> how can the service come up if it's waiting on a dependency using test-by?
<sadmac2> Keybuk: if there's an exec stanza, then it goes by the usual method (it can verify the test after execing, or not, that's a bit more of a philisophical question)
<Keybuk> sorry
<Keybuk> but it sounds like you really haven't thought this through
<Keybuk> since you're not bothering to answer the question
<sadmac2> Keybuk: on setenforce(1)..until setenforce(0)
<sadmac2> Keybuk: the events can still stop it
<Keybuk> ok, let's do a worked example
<sadmac2> Keybuk: /but/ we don't get the initial setenforce, because its done in initrd (and there be pjones)
<Keybuk> give me a real example of a service that would depend on selinux in this fashion
<sadmac2> so the additional test-by is necessary
<sadmac2> Keybuk: setroubleshootd
<sadmac2> no, that runs in permissive too. If we had one for "disabled" then that works
<Keybuk> ok, let's use setroubleshootd for a moment
<Keybuk> how would its definition be expressed?
<sadmac2> setroubleshootd when selinux
<Keybuk> no : s ?
<Keybuk> no paths or arguments ?
<sadmac2> that's just the setroubleshootd ->selinux dep
<Keybuk> setroubleshootd has no other dependencies (not even filesystem writable or mounted?)
<Keybuk> please don't shorthand
<Keybuk> give the full example
<Keybuk> use pastebin if you like
<sadmac2> setroubleshootd
<sadmac2>     when selinux
<sadmac2>     when can-exec("/usr/bin/selinux")
<sadmac2>     exec /usr/bin/selinux
<sadmac2> can-exec test-by [ -x %1 ]
<sadmac2> selinux
<sadmac2>     test-by getenforce
<sadmac2>     when (setenforce(1)..setenforce(0))
<sadmac2> #eof
<Keybuk> ok
<Keybuk> now give me a worked example of a system boot
<Keybuk> it's just come up
<Keybuk> Upstart has started
<Keybuk> now what happens?
<Keybuk> well, assumedly it parses the job definitions
<Keybuk> so let's say it's done that <g>
<Keybuk> now what?
<sadmac2> shit. missing a line
<sadmac2> can-exec when mounted
<sadmac2> ^^for efficiency. not mandatory
<Keybuk> you haven't defined mounted in the above, so please do that
<Keybuk> (feel free to just claim it's a state that comes up at some useful point)
<sadmac2> Keybuk: its a state that comes up whenever a filesystem is mounted.
<Keybuk> what brings that state up?
<Keybuk> I think if you're going to rely on such a thing right now, you need to define it ;)
<Keybuk> it might be easier for your example just to assume that there's only one filesystem and no such state
<sadmac2> yeah, ignore that. there's some particulars to this stage of boot I'm not thinking of
<sadmac2> ok, so we're up
<Keybuk> ok
<Keybuk> so we're up
<Keybuk> what happens now?
<sadmac2> we trip an initial event, say startup.
<sadmac2> this triggers a whole bunch of states not relevant to this example.
<Keybuk> perhaps
<Keybuk> though that event is not referenced in your above example
<Keybuk> so let's ignore it
<sadmac2> ok.
<Keybuk> upstart has started, it has parsed its configuration, what happens next?
<sadmac2> it triggers some state which wants setroubleshootd
<sadmac2> setroubleshootd in turn wants selinux
<sadmac2> selinux was enabled with setenforce, but this happened in initrd, so we don't know
<sadmac2> this being a fresh boot, the state is indeterminate, so we run test-by
<sadmac2> getenforce tells us selinux is up. we clear that dependency for selinux'
<sadmac2> can-exec is never triggered by anything but the test-by.
<sadmac2> so we run the test stanza there
<sadmac2> it tells us we are allowed to execute /usr/sbin/selinux.
<sadmac2> */usr/bin/setroubleshoot
<sadmac2> we bring the state tentatively up, and tell the service manager to run /usr/bin/setroubleshoot
<sadmac2> it returns a service handle, which we add to our parameters, and come all the way up
<sadmac2> this triggers a netsplit
<Keybuk> wb
<Keybuk> <sadmac2> this triggers a whole bunch of states not relevant to this example.
<Keybuk> <Keybuk> so let's ignore them
<Keybuk>  your example is all that interests me
<Keybuk>  and it is self-contained
<Keybuk>  it makes no reference to other events, or other states
<Keybuk>  upstart has started, it has parsed its configuration, what happens next?
<Keybuk> -- 
<Keybuk> that's as far as things got before the split
<sadmac_> Keybuk: ok, what'd we collectively miss?
<Keybuk> <Keybuk> wb
<Keybuk>  <sadmac2> this triggers a whole bunch of states not relevant to this example.
<Keybuk>  <Keybuk> so let's ignore them
<Keybuk>   your example is all that interests me
<Keybuk>   and it is self-contained
<Keybuk>   it makes no reference to other events, or other states
<Keybuk>   upstart has started, it has parsed its configuration, what happens next?
<Keybuk>  -- 
<Keybuk>  that's as far as things got before the split
<Keybuk> --> sadmac_ (n=sadmac@nat/redhat/x-6753e36432a1150f) has joined #upstart
<sadmac> Keybuk: ok, well, we need one more state: running_normal
<sadmac> Keybuk: it has lots and lots and lots of deps. one of them is setroubleshoot
<Keybuk> a goal state
<sadmac> if you so please
<Keybuk> one that lists the services that should be running in normal configuration?
<sadmac> yes
<Keybuk> I consider this a failure
<Keybuk> if we're going to have goals, let's just use initng
<sadmac> umm, what?
<sadmac> why?
<Keybuk> the reasons I wrote Upstart, instead of just modifying something that already exists, is that I expressly did not want goals, runlevels, or anything similar
<Keybuk> it's the _only_ difference between Upstart and those other systems
<sadmac> Keybuk: and its the _most_ requested feature I get from people
<Keybuk> then those people should use initng or launchd or smf
<sadmac> Keybuk: the advantage here is 1) goals aren't mutualy exclusive
<Keybuk> they aren't mutually exclusive in initng either
<sadmac> 2) goals are named, and there are infinitely many
<Keybuk> they are named in initng
<sadmac> 3) they can be expressed in terms of each other
<Keybuk> goals in initng can depend on each other
<sadmac> Keybuk: ok, how do I start a predefined subset of my usual services from the command line?
<Keybuk> in initng?  ngc start wibble I think
<Keybuk> it's been a while since I played with it
<sadmac> in upstart
<Keybuk> in my plan for Upstart ?
<sadmac> yes
<Keybuk>   start my-predefined-subset-of-my-usual-services
<Keybuk> which is a file that looks something like:
<Keybuk>   while service1 and service2 and service3
<sadmac> a goal state
<Keybuk> you can also just do:
<Keybuk>   start service1
<Keybuk>   start service2
<Keybuk>   start service3
<Keybuk> and that has the same effect
<Keybuk> no, it's not a goal
<sadmac> a set of goal states
<sadmac> yes it is
<Keybuk> no, it really isn't
<sadmac> why not?
<Keybuk> let's put this discussion on abeyance for a moment
<Keybuk> and go back to your example
<Keybuk> <sadmac2> setroubleshootd
<Keybuk>      when selinux
<Keybuk>      when can-exec("/usr/bin/selinux")
<Keybuk>      exec /usr/bin/selinux
<Keybuk>  can-exec test-by [ -x %1 ]
<Keybuk>  selinux
<Keybuk>      test-by getenforce
<Keybuk>      when (setenforce(1)..setenforce(0))
<Keybuk> that is what you defined
<Keybuk> and upstart has started, has parsed its configuration, and is now waiting
<Keybuk> what happens next?
<sadmac> it knows its supposed to start running_normal (from other configuration, kernel cmdline, your pick)
<sadmac> and so it does, and it depsolves it as it starts it
<Keybuk> running_normal isn't defined above
<Keybuk> so please, again, do not reference anything outside your example
<sadmac> I defined it as I came in
<sadmac> in syntax..
<sadmac> running_normal:
<sadmac>     when setroubleshoot
<Keybuk> ok
<sadmac>     when <lots of other stuff we won't talk about>
<Keybuk> upstart is waiting
<Keybuk> what tells it to start "running_normal"?
<Keybuk> what tells it to start "setroubleshootd"?
<Keybuk> what tells it to start "selinux?"
<sadmac> upstart's first action on running is always to start some kind of "strap state" which in our case is configured (one way or another) as running_normal
<Keybuk> ok
<Keybuk> that is what I call a "goal"
<sadmac> it does a solve-and-start on the strap state
<Keybuk> goal, strap state, runlevel, etc.
<sadmac> ok
<Keybuk> upstart has a predefined state it tries to reach
<sadmac> I'm not disputing its a goal
<Keybuk> this state is defined as a series of dependencies
<Keybuk> to reach it, it solves the dependency set, starting each service in term
<Keybuk> perhaps applying some kind of ordering to that
<Keybuk> congratulations, you've designed a dependency-based init daemon
<Keybuk> http://initng.org/  - enjoy ;P
<sadmac> Keybuk: what of this strategy are you escaping with upstart?
<Keybuk> Upstart, in its very original definition, is an event-based system
<Keybuk> not a dependency-based system
<sadmac> which is broken
<Keybuk> from the very first document I wrote on the subject, I outlined this as the distinction between Upstart and what else exists out there today
<Keybuk> if that is broken, then Upstart is a failed project and should be abandoned
<Keybuk> our efforts would be better spent on the pre-existing dependency based init daemons
<sadmac> what are we changing then?
<Keybuk> (if you consider that not broken)
<sadmac> what does your plan do that is not a goal?
<Keybuk> if you truly believe that Upstart, as an event-based init daemon, is broken
<Keybuk> and you believe that a dependency-based init daemon works, then you should look into one of the dependency-based daemons
<Keybuk> initng is the prime example here
<Keybuk> if the licence isn't a problem, SMF might be appealing - though it isn't as flexible
<sadmac> ok
<sadmac> but how is an event based init daemon /that solves the problems in 0.5/ still different?
<Keybuk> the difference between the two can be defined quite simply
<Keybuk> a dependency-based init daemon knows where it's going, and figures out how to get there
<Keybuk> an event-based init daemon has no idea, and just does whatever it can
<sadmac> ok, I see your problem. let me adjust my example
<sadmac> to setroubleshoot add:
<sadmac> when running_normal
<sadmac> auto
<sadmac> (the auto is an artifact of the present syntax. It can be massaged out)
<sadmac> and delete running_normal's definition altogether
<sadmac> same result
<sadmac> actually, that's better
<sadmac> now there's no depsolving in standard boot
<Keybuk> so let's go back to the same worked example
<Keybuk> upstart has parsed its configuration
<Keybuk> what does it do next?
<sadmac> well, it marks running_normal as up, by config. This is now just a marker though. It has no deps
<Keybuk> a ground state?
<Keybuk> ie. replace startup with a state?
<sadmac> yes
<Keybuk> (would just "on startup" not be a valid example there?)
<sadmac> ok. I think in the long run this way is better for a few reasons, but sure.
<sadmac> running_normal on startup
<Keybuk> that fulfills one of setroubleshootd's when clauses
<Keybuk> but not the other
<Keybuk> sorry, not the other TWO
<Keybuk> it has a dep on the can-exec("/usr/sbin/selinux") state
<Keybuk> and the selinux state itself
<sadmac> and it doesn't /trigger/ it, let's go into that for a second and then we'll look at those
<sadmac> so running normal comes up.
<sadmac> as upstart finishes doing this, it adds an event to the event queue: trigger-auto-services
<sadmac> this causes setroubleshootd to be brought into question
<sadmac> upstart iterates through setroubleshootd's deps. theres running_normal. that's satisfied.
<sadmac> there's can_exec. upstart looks at the can_exec state and sees that it is undetermined and has a test_by
<sadmac> it runs the test by and finds that /usr/bin/setroubleshootd is accessible
<sadmac> so can_exec is up
<sadmac> note that it does not /come/ up
<sadmac> it /is/ up
<sadmac> upstart just didn't know it before :)
<sadmac> selinux is much the same way. its test_by is run and it is determined to be up.
<Keybuk> for the sake of argument
<sadmac> setroubleshootd's when's now satisfied, it leaps upward
<Keybuk> let's say that selinux is not up
<Keybuk> the test-by fails
<sadmac> test-by fails, selinux remains undetermined, and no setroubleshootd
<sadmac> /now/
<sadmac> suppose we added this line to our config
<Keybuk> no
<Keybuk> no changing things
<Keybuk> setroubleshootd didn't come up on boot
<sadmac> fine
<Keybuk> the sysadmin notices that, and realises that selinux wasn't enabled
<Keybuk> and enables selinux
<Keybuk> what happens now?
<Keybuk> nothing
<sadmac> no
<sadmac> selinux had 2 lines of config
<Keybuk> nothing tells your system to re-evaluate its test-by clauses
<sadmac> look at number 2
<sadmac> and let me elaborate
<sadmac> when (setenforce(1)..setenforce(0))
<sadmac> the sysadmin brings up selinux
<Keybuk> you didn't define setenforce in your example, so I ignored it
<sadmac> you didn't mention this hypothetical appendix in your example
<Keybuk> err
<sadmac> so I didn't elaborate on the mechanisms that would make that case work
<Keybuk> the whole point of working an example is to find out what happens ;)
<sadmac> no, I /know/ what happens
<Keybuk> that means working through all the cases
<sadmac> the point is to tell you
<sadmac> ok, we'll define setenforce
<sadmac> setenforce, through whatever syntax is defined on inotify noticing a change in /selinux/enforcing
<sadmac> (yes, said file supports inotify)
<sadmac> it is emitted with one argument: the contents of that file.
 * sadmac needs selinux auto
<sadmac> yeah, I'll work on getting the auto thing out of the syntax
<sadmac> its kinda a pain
<sadmac> so the sysadmin changes enforcing, and this satisfies selinux's one and only when clause
<sadmac> from here there's a couple things it could do, and I'm flexible as to which:
<sadmac> we could re-run the test-by to be sure (not certain I like that)
<Keybuk> this is my fundamental issue with test-by
<Keybuk> you have to re-run it periodically
<sadmac> or, and this is my assumption, we simply jump right up. once up, if we are configured with a debug flag, we run the test clause, and if it disagrees with what we just did, we through -EDUMBASS
<sadmac> Keybuk: but we've run it exactly 2 times now, both times deterministically
<sadmac> no interval timer yet
<sadmac> Keybuk: the other thing is even if its unreliable it can still be useful in some form. for example
<sadmac> mount(type: nfs, host: *)
<sadmac>    when network-up(%host)
<sadmac> network-up test-by ping %host
<sadmac> even the ingrained unreliabilities there are better than we could do otherwise.
<sadmac> when it fails due to insufficient repitition the mount just takes longer to timeout
<sadmac> when it works though we have a bit more verification and probably a quicker abort,
<Keybuk> to be fair, I should give how I'd do it
<Keybuk> I'm not familar with selinux, but judging above the above
<Keybuk> selinux would look like:
<Keybuk>   pre-start exec getenforce || setenforce
<Keybuk>   post-stop exec setenforce 0
<Keybuk> --
<Keybuk> setroubleshootd would look like:
<Keybuk>   while selinux
<Keybuk>   exec /usr/sbin/selinux
<Keybuk> the worked example would be
<Keybuk> upstart parses its configuration
<Keybuk> the selinux job has no while condition, so can be immediately started
<Keybuk> if selinux was enabled already, getenforce would succeed so the state would be up
<Keybuk> if selinux was not enabled already, getenforce would fail, so setenforce is run and the state would be up
<Keybuk> (it setenforce failed, then selinux would be down)
<Keybuk> selinux coming up fulfills the while condition for setroubleshootd
<Keybuk> so that would exec /usr/sbin/selinux and come up
<sadmac> what if sbin isn't mounted
<Keybuk> no need for any startup event or ground state, etc.
<Keybuk> you mean /usr ;-)
<sadmac> Keybuk: you've known saner storage admins than me I gues
<sadmac> s
<sadmac> :P
<Keybuk> /sbin cannot be on a separate filesystem
<Keybuk> it contains init
<Keybuk> anyway
<Keybuk> now, the above has a slight disadvantage in that it requires you to not use setenforce directly, but instead use "stop selinux" or "start selinux" as the commands
<Keybuk> that in of itself isn't insane, but it's maybe annoying to experienced sysadmins
<Keybuk> I'd solve that the same way you would
<Keybuk> redefine selinux in terms of the contents of /selinux/enforcing
<Keybuk> that might be something like
<Keybuk>   while file-contains /selinux/enforcing 1
<Keybuk> where file-contains was a built-in that used inotify
<sadmac> you've mostly talked me out of test-by
<sadmac> barring that then, what else is different between the mechanisms?
<sadmac> syntax is somewhat an artifact and somewhat not. I don't care about the syntax but the differences in mine are an artifact of it doing things yours doesn't
<Keybuk> the fact that everything my way is first class
<Keybuk> and it's massively simpler to understand
<sadmac> not really
<Keybuk> I'll go back to what I said months ago
<Keybuk> when I figured it out
<sadmac> foo(bar: baz)  == all foos with bar = baz have these properties:
<Keybuk> yours can be summed up as
<Keybuk> <state>: <actions>
<Keybuk> ie. when the state on the left is true, the actions on the right are performed
<sadmac> no
<sadmac> that's very wrong
<sadmac> because there are no actions
<Keybuk> that's how you defined it yourself not so long ago ;)
<sadmac> its declarative, and its backward
<Keybuk> oh, no
<Keybuk> sorry
<Keybuk> <state>: <tests>
<Keybuk> the state on the left is true, while all of the tests on the right are true
<sadmac> I wouldn't go with that either
<Keybuk> confusing it with something else I was thinking of
<sadmac> <set of states>: <properties>
<sadmac> the state[s!] on the left behave in the manner described on the right
<sadmac> my model never talks about one state
<sadmac> it always talks about sets of them
<sadmac> mounted(type: nfs, mountpoint: /) is a subset of mounted(type: nfs) is a subset of mounted()
<sadmac> if you want a model for it, its awk
<sadmac> pattern: transformation
<sadmac> Keybuk: if you put filename: at the top of all your files, how does yours behave differently than mine?
<sadmac> serious question.
<Keybuk> probably in terms of such things as instancing
<sadmac> yeah. that is it
<Keybuk> not to mention arguments, which your system fundamentally relies on
<sadmac_> Keybuk: what'd I miss? last thing I saw was last thing I said to you
<Keybuk> <Keybuk> not to mention arguments, which your system fundamentally relies on
<sadmac> Keybuk: you don't have any arguments at all?
<Keybuk> let me describe things as I see them
<Keybuk> you define in files, or over D-Bus, services, tasks, states and other objects you would like Upstart to control
<Keybuk> as far as Upstart is concerned, these are all just different names for the same thing
<sadmac> ok
<Keybuk> let's call them Objects for now
<Keybuk> (to avoid any inference of behaviour from previous versions)
<sadmac> same so far. except I don't give them different names
<Keybuk> Objects have three basic attributes
<Keybuk>  - the condition in which they may be running
<Keybuk>  - an activation which starts them
<Keybuk>  - and what to do
<Keybuk> a fun fictional example that uses all three
<Keybuk>   while apache2
<Keybuk>   on control-alt-delete
<Keybuk>   exec echo "don't kill my web server" | wall
<sadmac> ok
<Keybuk> if an object has no condition, then it may be running at all times
<Keybuk> if an object has no activation, it will be activated as soon as the condition is true
<Keybuk> if an object has nothing to do, it is simply a state
<Keybuk>   while apache2
<Keybuk> is valid, except exceedingly pointless
<Keybuk>   on control-alt-delete
<Keybuk>   exec shutdown -r now
<Keybuk> is valid, it may be run at any time when control-alt-delete is pressed
<Keybuk>   exec /sbin/udevd
<Keybuk> is valid, it defines a service that should always be running
<Keybuk> ok so far?
<sadmac> yes
<Keybuk> ok, great
<Keybuk> Objects are just definitions
<Keybuk> Instances are the important thing
<Keybuk> when an Object is running, what we really mean is "there is an Instance of Object"
<Keybuk> when an Object is not running, what we really mean is "there are no Instances of Object"
<Keybuk> when I start apache2, I am not starting the apache2 Object, I am creating an Instance of the apache2 Object and starting that instance
<Keybuk> (not quite true actually, but the definition suffices for now)
<sadmac> ok
<Keybuk> it would be more truthful to say that you start and stop an Instance of the apache2 Object - you don't create it
<Keybuk> Objects reference each other in their matches
<Keybuk> if an Instance of an Object is created, then an Instance of all Objects that reference it are created as well
<Keybuk> that's a very complicated way of saying something very simple
<Keybuk> you can have as many copies of apache2 running as you like
<Keybuk> and for each copy of apache2 that you run, you will get a second copy of everything that depends on apache2 as well
<sadmac> what if you try to run something that depends on apache2 after that?
<Keybuk> Upstart only exposes *Instances*
<Keybuk> if there is something defined that depends on apache2, you will see two copies of it in the list
<Keybuk> so you'd inherently be picking which one you want to run (or probably both)
<Keybuk> and Upstart knows which apache2 instance each is linked to
<Keybuk> Instances have two additional attributes over Objects
<Keybuk>  - state (up or down)
<Keybuk>  - environment/properties (FOO=BAR)
<Keybuk> an Instance's environment is taken from the exported list of environment of Instances that created it - and optionally the sysadmin's own start command
<sadmac> how do you prevent the rooting problem?
<Keybuk> "the rooting problem" ?
<sadmac> ok, so you have fooservice which depends on barservice
<Keybuk> err
<Keybuk> no I don't
<Keybuk> I can have fooservice which includes barservice in its condition
<sadmac> ok then
<Keybuk> I *very* explicitly avoided the term "depends on"
<Keybuk> fooservice is conditional on barservice? :p
<sadmac> 17:03 < Keybuk> and for each copy of apache2 that you run, you will get a second copy of everything that depends on apache2 as well
<sadmac> depends on
<sadmac> gotcha!
<Keybuk> oh, damn
<Keybuk> :p
<Keybuk> got me
<Keybuk> I'm trying very hard not to call them jobs :p
<Keybuk> anyway
<Keybuk> the rooting problem
<Keybuk> fooservice has while barservice in it
<sadmac> ok, so you have 2 copies of fooservice, and 2 copies of barservice (instances rather
<Keybuk> right
<sadmac> now bazservice comes along, and it has when fooservice, and when barservice
<sadmac> how come you don't get 4 copies of it?
<Keybuk> ok
<Keybuk> I'll talk this one through forwards
<Keybuk> we have a barservice Object
<Keybuk> we have a fooservice Object
<Keybuk> we have a bazservice Object
<Keybuk> fooservice links to barservice
<Keybuk> bazservice links to fooservice and barservice
<Keybuk> right?
<Keybuk> we create an instance of barservice
<sadmac> k
<Keybuk> let's call it bar1
<Keybuk> this tracks back its links
<Keybuk> fooservice has a link, so we get a new instance "foo1" that links to bar1
<Keybuk> bazservice has a link to fooservice, so we get a new instance "baz1" that links to "foo1" that links to "bar1"
<Keybuk> bazservice has a link to barservice, but there's already the baz1->bar1 instance
<Keybuk> so no instance needs to be created
<sadmac> what ensures that order
<Keybuk> let's create the second instance the other way
<Keybuk> we create an instance of barservice "bar2"
<sadmac> suppose we evaluate "bazservice has a link to barservice" first?
<Keybuk> bazservice has a link to barservice, but its condition on fooservice is not yet met, so no instance is created
<Keybuk> fooservice has a link, so we get a new instance "foo2" that links to "bar2"
<Keybuk> bazservice has a link to fooservice, so we get a new instance "baz2" that links to "foo2" that links to "bar2"
<sadmac> ok, swap those last two:
<Keybuk> you can't swap the last two
<Keybuk> it's a tree
<Keybuk> a -> b -> c
<sadmac> we have foo1, bar1, foo2, bar2
<Keybuk>  -> c
<sadmac> we go to evaluate bazservice:
<Keybuk> we don't "go to" do anything, we follow trees
<sadmac> what's to keep bazservice from grabbing bar1, then foo2
<Keybuk> we have a tree
<sadmac> oh, I get it now
<Keybuk> a -> b -> c
<Keybuk>   -> c
<sadmac> but the deps aren't necessarily a tree
<sadmac> in fact they aren't now
<Keybuk> there are two valid ways to iterate that
<Keybuk> a, b, c, c
<Keybuk> or a, c, b, c
<Keybuk> either way, c always ends up last ;)
<Keybuk> they damned well are trees
<sadmac> ok, so consider only one foo1 and one bar1
<sadmac> cut the 2s
<Keybuk> ok
<Keybuk> you have
<sadmac> so we have foo1->bar1, baz1->foo1, baz1->bar1
<Keybuk> bar1
<sadmac> triangle
<Keybuk> foo1->bar1
<Keybuk> baz1->foo1,bar1
<sadmac> that's triangular
<sadmac> thats not a tree
<Keybuk> no it's not?
<sadmac> draw it
<Keybuk> a -> b -> c
<Keybuk>   -> c
<Keybuk> that's a tree
<Keybuk> I can do it the other way too
<sadmac> those 2 cs are the same node
<Keybuk> c -> b -> a
<Keybuk>      b -> a
<Keybuk>           a
<Keybuk> that's still a tree
<Keybuk> just a baobab ;P
<sadmac> no, it has a cycle
<Keybuk> sure
<Keybuk> it's a bit of a twisty tree ;)
<Keybuk> but it's still a tree
<sadmac> its not a tree
<sadmac> its a directed graph
<Keybuk> (actually it is a digraph because foo could depend on baz)
<Keybuk> but we're not considering that case here :p
<sadmac> digraph is short for directed
<Keybuk> I know
<sadmac> if you can start at any node and get to another by more than one route without backtracking its not a tree
<Keybuk> exxxxcept
<Keybuk> that the only way to iterate it is as a tree
<Keybuk> it's self-breaking
<Keybuk> so while the mesh of objects is a digraph
<Keybuk> the mesh of instances is a tree
<Keybuk> actually, it's more of a bag than anything else, but hey :p
<sadmac> so it has an MST
<sadmac> that just makes it a graph
<sadmac> and well connected
<Keybuk> so now we're finished arguing about terminology, you can see that it works? :p
<sadmac> more or less
<sadmac> go on
<Keybuk> well, that's it really
<sadmac> ok
<sadmac> mine actually doesn't have states the more I think about it.
<sadmac> I keep wanting to call them that, but they're not
<Keybuk> you can never end up with four copies of baz because the instances ref-count each other
<Keybuk> you'd have two instances ref-counting the same instance
<Keybuk> and that's not allowed by model
<Keybuk> oh, one more thing
<Keybuk> you can avoid inheriting instances
<Keybuk> so you only get one instance no matter how many instances of your parent there are
<Keybuk> but in that case, you don't get any environment from them
<Keybuk>   any <Object>
<Keybuk> a good example to all of the above is a D-Bus interface to Bind9 (replacing rndc?)
<sadmac> right
<Keybuk>   while dbus and bind9
<Keybuk>   exec /usr/sbin/bind9dbd
<Keybuk> you get a copy for each dbus bus daemon you run and each bind9 bus daemon you run
<Keybuk> interconnecting each of them
<Keybuk> (dbus exports the session bus address, assumedly bind9 exports the socket address)
<Keybuk> if you had another service that depended on that and dbus
<Keybuk>   while bind9dbd and dbus
<Keybuk> you get a copy for each bind9dbd
<Keybuk> connected to that dbus daemon
<Keybuk> it doesn't multiply
<Keybuk> in fact, in many cases, it gives you fewer than you might actually expect, but usually the number you need
<Keybuk> err, sorry, you get a copy for each dbus connected to a bind9dbd on that dbus daemon
<Keybuk> had that backwards
<sadmac> sounds ok
<sadmac> its actually more complicated than mine  XD
<Keybuk> it's far simpler to describe though
<Keybuk> without technical terms
<sadmac> Keybuk: most of the difficulty is I've been insistent on calling them states and dealing with it in this way
<Keybuk> To define your DNS service, create a file /etc/init/bind9 and in that put "exec /usr/sbin/bind9"
<sadmac> Keybuk: I think I can explain it now
<Keybuk> if that DNS service may only be running during certain times, add "while blah and blah or blah" to that file
<sadmac> Keybuk: so you have a computer on/under your desk, right?
<Keybuk> yes
<sadmac> now, there's a lot of things you could say about this computer. "Its fast" (kind of subjective) "Its purple" (maybe maybe not) etc.
<sadmac> my "state machine" manages statements like this
<sadmac> when you configure it, you tell it what can and cannot be true. It then reads events and works out what is true.
<sadmac> "Apache is running" implies that "The harddisk is mounted"
<Keybuk> how do I run apache when the harddisk isn't mounted?
<sadmac> "Apache is running" implies that "The harddisk is not mounted"
<sadmac> now obviously this is too verbose, so we allow shorthand
<Keybuk> no
<Keybuk> I mean
<Keybuk> I'm a sysadmin
<sadmac> apache when not disk
<Keybuk> I have booted, and the hard disk failed to mount
<Keybuk> but I need to start apache
<sadmac> the example is contrived
<Keybuk> hardly
<sadmac> no I mean perhaps the rule is bad
<Keybuk> replace apache with any other service that might normally be only running in a full multi-user condition but for which I might need
<Keybuk> here's a good one
<Keybuk> syslog
<Keybuk> I often need to start that one when debugging
<Keybuk> your system *only* permits you to do the things the daemon allows
<Keybuk> there's no separation
<sadmac> Keybuk: my system is necessarily equivalent to yours
<sadmac> its second order logic. you can define all of computing with it
<sadmac> unless yours isn't a piece of software...
<Keybuk> well, use my example then
<Keybuk> unless I'm mistaken, in order to have two dbus daemons, I would need to define two different dbus daemons
<sadmac> no
<sadmac> well, that's getting ahead actually
<Keybuk> well, dbus with two different possible arguments
<sadmac> ok, that's true
<Keybuk> the point being, the person who wrote the dbus service has to allow, up front, the sysadmin to have multiple copies of it
<Keybuk> it's kinda like the 0.5 instance model
<Keybuk> the service has to define the limits of instantiation
<sadmac> why do you need 2 identical copies of the same service?
<Keybuk> chroot
<Keybuk> namespace
<sadmac> 2 /identical/ copies
<Keybuk> no, you're missing my point
<Keybuk> your system requires that the service define the ways in which they may be different
<sadmac> yes
<sadmac> with the exception that they propagate their arguments
<Keybuk> if you want to allow dbus to be run on different bus addresses, the service has to, up-front, accept an argument to allow that
<sadmac> (this is a recent change)
<sadmac> so different deps yields a different service
<Keybuk> if you want to allow dbus to be run in different chroots, the service has to, up-front, accept an argument to allow that
<Keybuk> it all has to be up-front designed
<sadmac> Keybuk: watch closely. this isn't far from possible:
<sadmac> *(*): when namespace
<Keybuk> use the chroot example?
<sadmac> dbus: exec /usr/bin/dbus-daemon | us_set %bus_id
<Keybuk> *(%chroot): chroot %chroot ?
<Keybuk> everything takes a chroot argument that specifies its chroot?
<sadmac> Keybuk: propagation has been made automatic now
<sadmac> so no %s
<Keybuk> ok
<Keybuk> so the dbus example
<Keybuk> the bus_id is actually set by starting dbus
<sadmac> right
<sadmac> you can see in the script how it works
<sadmac> 17:45 < sadmac> dbus: exec /usr/bin/dbus-daemon | us_set %bus_id
<Keybuk> how do you create a second one?
<sadmac> Keybuk: if you say start dbus, you get dbus(bus_id: deadbeef)
<sadmac> if you say it again you get dbus(bus_id: feedface)
<Keybuk> so if I say start bind9, but there's a bind9 running
<Keybuk> how does that *not* create another bind9?
<sadmac> because bind9's script doesn't set any variables inside of it
<Keybuk> so it has to parse its own exec/script stuff to figure out whether it might set any variables?
<Keybuk> what happens if that just looks like:
<Keybuk>   script
<sadmac> Keybuk: it doesn't have to know ahead of time
<Keybuk>     echo < FOO
<Keybuk> you might want to use us_set %bus_id
<Keybuk> FOO
<Keybuk>   end script
<Keybuk> yes it does
<sadmac> nope
<Keybuk> it has to know *before* it starts bind9!
<sadmac> no it doesn't
<Keybuk> it doesn't know that it shouldn't start another dbus-daemon until it's started it
<Keybuk> because it doesn't know what the value of that variable is until it's read the output
<Keybuk> therefore it cannot know *not* to start bind9 either
<sadmac> Keybuk: but it knows the first time a variable was set
<Keybuk> no it doesn't
<sadmac> yes it does
<sadmac> Keybuk: it attempted to start dbus(*)
<sadmac> Keybuk: only dbus(bus_id: deadbeef) came up
<sadmac> Keybuk: another (infinity-1) services didn't launch
<sadmac> its worth trying again to launch one of them
<sadmac> foo(bar: baz) is a statement. A sentence
<sadmac> It reads "any thing foo such that bar = baz is true"
<sadmac> if you also say foo
<sadmac> it reads "any thing foo is true"
<sadmac> if the second is true, the first must be by definition
<sadmac> so if foo() is up, then foo(bar: baz) is up by definition, but the converse is /not/ true
<sadmac> so for your bind9 example
<sadmac> the first one starts bind9()
<sadmac> the second one can't hope to start bind9(foo: bar), bind9(chicken: never), bind9(wibble: wobble) because these are /already true conditions/
<sadmac> Keybuk: with me?
<Keybuk> yeah
<Keybuk> I still say your state machine is insanely complicated
<Keybuk> I prefer mine
<sadmac> its logic
<sadmac> its not hard
<sadmac> plus the last 3 ways you got it wrong all would have yielded correct configuration files in most situations :D
<sadmac> In a way I agree that its complicated, but I think the user has to understand it less completely
<sadmac> most guesses will result in you operating it correctly
<sadmac> plus implementing it is really nice
#upstart 2009-01-21
<Keybuk> \o/  libnih builds again
<Keybuk> its test suite doesn't, of course
<sadmac2> yaay for building!
<sadmac> Keybuk: I came upon an interesting, if possibly a bit-too-fringe real-life usecase the other day
<sadmac> Keybuk: basically what it boils down to is: might we want some kind of policy mechanism such that unpriviliged users can start and stop certain things?
#upstart 2009-01-22
<JohnFlux> Hey all!
<JohnFlux> Does upstart have a dbus interface now?
<JohnFlux> I saw some comments about it awhile ago
<sadmac> JohnFlux: 0.5 does
<JohnFlux> sadmac: awesome.  am I able to turn a pid into a service name?
<JohnFlux> I'm interested in adding upstart support to the kde task manager
<sadmac> JohnFlux: not sure if you can. the mapping isn't really 1:1 anyhow
<sadmac> JohnFlux: I'd talk to Keybuk about all this. not sure its a good time to start integrating upstart into things
<JohnFlux> I'll wait for now then
<JohnFlux> I come in here every 6 months or so
<JohnFlux> to check on the status :-)
<sadmac> heh
<JohnFlux> sadmac: I picture having a view that shows just the currently running services
<JohnFlux> allowing the user to view the cpu/memory usage of the Apache service etc
<sadmac> JohnFlux: sounds nice'
<JohnFlux> and when the user choses to kill a process, allow them to just stop the service instead
#upstart 2009-01-23
<sadmac> Keybuk: did you see the patch we just got on bugzilla?
<ion_> bugzilla?
<sadmac> ion_: redhat bugzilla
<sadmac> ion_: someone wrote a state save-and-restore patch for 0.3.9
<sadmac> out of nowhere
<ion_> Save and restore what? :-)
<sadmac> ion_: state. across re-execs
<ion_> Ah
<Keybuk> did he base it off the patch for 0.2?
<sadmac> Keybuk: I dunno
<sadmac> Keybuk: doesn't look like it. Its off-style
<sadmac> Keybuk: Ibex still uses 0.3.9 right?
<Keybuk> right
<sadmac> and you said you likely wouldn't deploy 0.5 between now and 0.10?
<Keybuk> right
<sadmac> ok cool
<sadmac> notting: ^^
#upstart 2009-01-24
<sadmac> the patch works
<sadmac> \o/
#upstart 2009-01-25
<Keybuk> void foo() {
<Keybuk>     nih_local char *foo;
<Keybuk>     foo = nih_strdup (NULL, foo);
<Keybuk> }
<Keybuk> \o/
 * Keybuk is a genius
<Keybuk> that pointer will be automatically freed when the function returns ;)
<ion_> keybuk: Ooh. How does it work? Using some gcc extension, i presume.
<Keybuk> ion_: yup ;)
<Keybuk> only works because of the new allocator, of course
<Keybuk> the great thing is, that this works:
<Keybuk> void foo() {
<Keybuk>      nih_local char *foo;
<Keybuk>      foo = nih_strdup (NULL, foo);
<Keybuk>      pass_to_some_func (foo);
<Keybuk> }
<Keybuk> if pass_to_some_func() references foo, it won't be freed :-)
<ion_> Neat
<Keybuk> but if it doesn't, foo is freed ;-)
<ion_> Heh, if i type â? libnihâ to the address bar, Firefox opens http://fi.wikipedia.org/wiki/Gottfried_Leibniz
<ion_> libnihâs trunk doesnât seem to contain nih_local. What is it defined as?
<Keybuk> I haven't pushed it yet
<Keybuk> uses __attribute__((cleanup))
<Keybuk> which calls a function and passes a pointer to the variable when it goes out of scope
<ion_> Alright
<Keybuk> I thought about just having something like
<Keybuk>   nih_local_context ctx;
<Keybuk> where you'd pass that in instead of NULL for the given block
<Keybuk> but decided that "nih_local type *var;" was nicer ;)
<ion_> Yeah
<sadmac> Keybuk: what else is on the list of nih improvements?
<Keybuk> d-bus properties
<Keybuk> signal handling, etc.
<Keybuk> better main loop
<sadmac> Keybuk: do you have asynchronous method calls for dbus? That'd help for some initctl stuff
<Keybuk> that's on the todo list
<sadmac> is there enough on launchpad for me to pitch in?
<Keybuk> for the d-bus stuff?
<Keybuk> it hasn't changed in months
<Keybuk> and I believe I suggested it as something for you to do months ago, and gave you notes ;-)
<sadmac> Keybuk: I assume the new memory management would want to be underneath all of it though.
<Keybuk> I don't think the D-Bus functions use anything that has changed
<Keybuk> only functions that call nih_alloc_reparent are affected
<Keybuk> otherwise the API is entirely compatible
<keesj> is nih used for other projects?
<sadmac> keesj: no, and its really not set up to be right now
<sadmac> it operates more as a code patch than an actual library
<sadmac> we only barely get away with that because upstart is the only consumer
<sadmac> (and its due to change soon)
<ion_> My idlemeter uses libnih. :-P
<Keybuk> my train set controller uses libnih too ;)
<Keybuk> it wasn't even originally written for upstart (which is why upstart uses less than half of it)
<Keybuk> it was originally written for dpkg2 ;-)
<Keybuk> keesj: if you treat it as a library that changes API on a whim, it's quite usable
<Keybuk> ie. don't bzr update libnih in your tree unless you've read the coming changes
<keesj> in the old days it was lib.
<sadmac> Keybuk: but right now nobody else other than us and the trains are using it, right?
<keesj> I see.
<keesj> tha's why the compiling upstart from bzr is so stangely not compiling nih but only configuring...
<sadmac> oh, and ion_
<sadmac> Keybuk: so my thoughts on not waiting for dbus reply is to simply not wait if the user NULLs out the out arguments.
<Keybuk> my thought was just to use the async function and NULL the callback ;)
<sadmac> that works too.
#upstart 2010-01-25
<einstein1969> hi
<einstein1969> how to change level to single mode in ubuntu?
<solj> hey everyone, i'm very new to upstart and trying to write a simple script that will run during startup; i have http://upstart.pastebin.com/m6f8fa569 working when run manually, but fails to start during startup
<solj> this is on lucid
<solj> i'm sure i'm missing something simple, but couldn't find the answer on the website
<solj> is there an update-rc.d analog for upstart?
<sadmac> solj: it looks right, but I'm betting it runs before the xserver
<solj> sadmac: so, the init process will automatically look at any conf files in /etc/init?
<sadmac> solj: it detects when they're modified and reloads them
<solj> sadmac: hmm, it doesn't appear to run at all during startup :-/
<sadmac> solj: no idea why. output should be suppressed if you're looking for evidence of it that way
<solj> well, that command should configure xorg.conf for me (which it does when i do a 'service start <servicename>')
<solj> just doesn't run during startup
<JanC> solj: maybe it runs before something it needs is loaded and doesn't work because of that, or something like that?
<JanC> (just guessing)
<solj> yeah, i also tried changing it to run only during runlevel 5, but that didn't appear to help
<solj> i guess i just need to figure out a way to debug it
<JanC> well, you can add a simple command that writes something to a file before running nvidia-xconfig to make sure whether it gets started or not
<JanC> or redirect nvidia-xconfig's output (stout & stderr) to a file?
<solj> JanC: tried adding debug statements in there and get nothing
<solj> so, it's definitely not running at boot
<sadmac2> solj: they'll be hidden unless you explicitly direct them to /dev/console
<solj> sadmac2: it's not being run; i'm going to try adding a boot option to run init with --debug
<sadmac2> ok
<solj> sadmac2: ok, i confirmed it's not being run; i do see it as having been registered previously
<solj> so, i have no idea what to do to debug now
<solj> since the only things logged when running init verbosely are those things which get started
<sadmac2> solj: why do you need to rewrite xorg.conf on every boot btw?
<sadmac2> solj: at any rate try making it start on foo and then use initctl emit foo to start it
<solj> sadmac2: i don't; i wanted to get an upstart job running at boot so i can do something more interesting
<sadmac2> solj: ah :)
<sadmac2> solj: yeah, see if you can event-trigger it via another event
<solj> k, i'll try that
<solj> sadmac2: doing that works
<sadmac2> solj: ok, so the startup event is the issue...
<solj> i also tried doing the runlevel syntax
<sadmac2> solj: you tried start on runlevel 5?
<solj> let me try just 5
<sadmac2> weird
<solj> i think i had tried multiple ones before
<solj> that didn't work either
<solj> hmm.
<solj> not sure if it helps any, but this is on lucid
<solj> and grep emit /etc/init/* only returns http://upstart.pastebin.com/m66e3e86b
<solj> sadmac2: got it to work :-/
<solj> start on started tty1
<sadmac2> solj: intriguing
<sadmac2> solj: it should work as you had it I'd think
<solj> sadmac2: that's what i thought
<solj> sadmac2: anything i can do to test for you, let me know
<sadmac2> solj: it'd be good to know if you see the startup event getting emitted during boot
<solj> sadmac2: i'm not seeing it
 * sadmac2 tries to remember if it was scrapped
<sadmac2> solj: you'd need debug on to see it
<sadmac2> solj: init=/sbin/init --verbose
<solj> sadmac2: right, i already added that
<sadmac2> solj: do you see the runlevel stuff?
<solj> sadmac2: only numerous "Handling runlevel event" messages
<solj> actually, it looks like one per boot
<sadmac2> ok so the runlevel event should have worked I'd think
<solj> sadmac2: i don't see any runlevel {1,2,3,...} being emited
<solj> just the handling message
<sadmac2> solj: yeah the event is just "runlevel"
<sadmac2> the number would be an argument
<solj> hmm, ok
<sadmac2> ok fedora rcS.conf uses the startup event...
<solj> lucid uses "start on runlevel S"
<sadmac2> I don't know this lucid thing
<solj> sadmac2: ubuntu lucid?
<solj> karmic+1
<sadmac2> solj: ah. heh :)
<sadmac2> solj: I don't follow ubuntu.
<sadmac2> as much as I should really
<solj> ah, i see
<sadmac2> Scott hasn't been around to clue me in either
<solj> the main reason i'm trying this is because we are working on preparing a customized ubuntu distro which we use and would like to convert our init scripts to upstart if possible
#upstart 2010-01-26
<gianluca_r> hello all
<gianluca_r> i'm using Ubuntu9.10 server, putting nginx under upstart, 'start nginx' cmd makes nginx starting and runnig but the job is registered and then unregistered while nginx keeps runnig, when use 'stop nginx' get: "stop: Unknown instance:"
<gianluca_r> some hint?
<JanC> yep, sounds like it forks more often than upstart expects
<JanC> what "expect" line do you have?
<gianluca_r> JanC: don't an 'expect' line
<JanC> you probably need an "expect daemon" line or such (see "man 5 init")
<gianluca_r> ok thnx a lot, try immediatly
<gianluca_r> i tried before the with a line only containing 'daemon' it resulted in error
<gianluca_r> JanC: yes it's ok now, thnx
<gianluca_r> i was reading this: http://upstart.ubuntu.com/wiki/Stanzas and it was clear to me
<gianluca_r> is there some other docs about upstart 0.6.3?
<gianluca_r> ...and now the 'stop' cmd hangs
<JanC> docs --> see the manpage I pointed to
<gianluca_r> ok thnx
<gianluca_r> it stpos it correctly though
<gianluca_r> bye all, JanC thanks again
<Jaja_> hi
<Jaja_> is anyone alive here?
<Tartaros> I wonder if it makes sense in the current state of affairs to actually use upstart for definition of my own services/tasks
<Tartaros> I mean, is it stable enough/
<Tartaros> ?
<Tartaros> stable as in api
<Tartaros> also there seem to be quite a lack of tutorials/documentations...
<mbiebl> man init
<mbiebl> regarding the API, are you referring to the job file syntax?
<Tartaros> yeah I guess so
<mbiebl> afaik it is not set in stone. It won't be before 1.0 is released
<JanC> "man 5 init" actually, if you want to see the syntax documentation
<ion> I use Upstart for my jobs. The syntax may change in the future, but iâll just do the changes needed when upgrading to a new distro release.
<mbiebl> JanC: yes, thanks
<ion> 0.10/1.0/whatever may implement backwards compatibility for 0.6 jobs, though.
<Tartaros> well as of current state, do I understand correctly that basically all ubuntu services still have their old init.d scripts, which are only used by "placeholder" simple scripts in /etc/init ?
<mbiebl> Tartaros: I assume that given Ubuntu uses upstart heavily in 9.10, it will keep compat for 0.6
<mbiebl> Tartaros: that is no longer correct since 9.10
<ion> The most essential Ubuntu stuff has already migrated to Upstart.
<JanC> everything that runs on the default desktop I think
<Tartaros> so what'
<Tartaros> what's /etc/init.d for?
<mbiebl> Tartaros: It's kept for backward compatibility
<Tartaros> I mean how is it still so full?
<Tartaros> so, is it being used or not?
<mbiebl> Tartaros: are you running 9.10?
<Tartaros> yes, 9.10
<JanC> actually, there are fake sysvinit scripts in there  ;)
<mbiebl> most of them are symlinks
<mbiebl> check with ls -la
<Tartaros> fake? yeah I know but they point somewhere
<mbiebl> Tartaros: sys admins are used to type /etc/init.d/<service> <action>
<mbiebl> /lib/init/upstart-job is a tiny, simple shell script
<Tartaros> so that's all they're for? if you don't type this manually, they're not used?
<mbiebl> which basically runs the native upstart jobs
<mbiebl> yeah, they are only for sysadmins convenience
<Tartaros> oh, ok then
<Tartaros> and the "service" command is upstart based or initv based?
<mbiebl> Better check /etc/rc?.d/
<mbiebl> symlinks in there point to services that are still sysv
<mbiebl> rcS.d and rc2.d are pretty nowadays on a default Ubuntu desktop install 
<mbiebl> pretty empty, i.e.
<ion> The service command it designed as the proper way to call sysvinit scripts.
<ion> is
<Tartaros> aso for upstart one should use initctl right?
<ion> Or the symlinks to it, such as start, stop and restart.
<Tartaros> yeah
<Tartaros> ok
<Tartaros> as for creating a service - all one is supposed to do is adding a new myjob.conf file in /etc/init, right?
<Tartaros> and also, is there a way to list events that are in use?
<Tartaros> say I want to run something "when network is on" but I don't know what even(s) that means... where do I look?
<ion> /etc/init, yes. As a personal preference, i put my local jobs under /etc/init/local/ for easy access.
<mbiebl> Tartaros: grep for "emit"
<mbiebl> emits, actually
<mbiebl> in /etc/init
<mbiebl> this list is not exhaustive though
<Tartaros> there are "inbuilt" events?
<Tartaros> where are they liste
<Tartaros> d?
<ion> Upstartâs internal events are documented in init(5). Some of the events emitted by jobs are documented under /etc/init as mbiebl mentioned. ifupdown installs the script /etc/network/if-up.d/upstart, which emits the net-device-up event.
<Tartaros> cool
<Tartaros> one last thing :)
<Tartaros> when I want something to be run as a specified user, is there some sort of support for that?
<ion> For now, use su.
<Tartaros> or do I just do se
<Tartaros> su
<Tartaros> yeah
<Tartaros> ok
<Tartaros> thanks :)
<ion> PAM sessions support is in TODO, but not implemented yet.
<Tartaros> so without su, it's run as root right?
<ion> Yes
<Tartaros> ok
<Tartaros> thanks for all the info :)
#upstart 2010-01-27
<mase_wk> can upstart be used to monitor a file event ( like a file being modified) ?
<ion> mase_wk: Not yet, but thatâs in TODO.
<mase_wk> ion: thanks 
<wasabi_> So. I just had a problem where I booted up my server, and init stopped starting proceses before I had a usable console.
<wasabi_> Looks like it got hung up trying to contact dbus.
<wasabi_> single mode was in a similar shape. break=mount got me in, and I just removed dbus
<wasabi_> And now it boots.
<wasabi_> Guess if I install dbus while the system is running, init will get -USR1 and attempt to connect... and maybe freeze in the same way
<wasabi_> But I should still have a system usable enough to debug it. ;)
<wasabi_> init: Unable to connect to the system bus: Connection ":1.0" is not allowed to own the service "com.ubuntu.Upstart" due to security policies in the configuration file
<wasabi_> imaginging there is supposed to be some sort of system.d/upstart.conf
<echa> hi there
<echa> i'd like to add a job in my ubuntu 9.10 startup to run an ethtool setting
<echa> is there a new way to do this?
<mtd> can/should I use upstart to communicate between non-root processes (source daemon fires event IM_HOME, which causes upstart to start a few daemons, for example), or is that better a D-Bus thing?
<echa> in debian i guess i would make a init.d script
<mtd> echa: sure, make an /etc/event.d script that runs on runlevels 2-5
<echa> ok
<echa> thanks
<mtd> echa: echo -e "start on stopped rcS\nconsole output\n/run/my/job/here" > /etc/event.d/my-startup-job-config
 * mtd supposed rcS is a bit more precisely "startup"
<JanC> upstart in Ubuntu 9.10 doesn't use /etc/event.d/
<echa> ?
<JanC> it uses /etc/init/
<JanC> read the manpages  ;)
<echa> so i just use /etc/init.d/myscript and link to it in rc5.d/?
<echa> that's the old way to do it
<echa> i thought upstart had changed all that, i'm confused
<ion> /etc/init â  /etc/init.d
<echa> ok, i see, so why are there still init.d scripts - is it just that not everthing has been migrated
<echa> ?
<ion> Basically, yes. Also, everything doesnât *need* to be migrated. There are benefits from migration, of course, but $randomsoftware that used to work with sysvinit will not be broken by upstart.
<echa> and i still don't know where to put my ethtool script. i'd like to know where to put the setting
<ion> What does the script to?
<echa> ethtool -s eth0 wol g
<echa> just enables wake on lan for my ethernet adaptor
<ion> Something like
<ion> start on net-device-added INTERFACE=eth0
<ion> task
<echa> hm
<ion> exec ethtool -s "$INTERFACE" wol g
<ion> in /etc/init/ethtool-wol.conf
<echa> right
<ion> My personal preference would be /etc/init/local/ethtool-wol.conf for easy access to my personal jobs.
<echa> right
<echa> keep them separate
<echa> where can i find a reference for the device triggers?
<ion> upstart-udev-bridge listens to udev events and emits upstart events with the format $SUBSYSTEM-device-{added,removed}
<echa> oh i see
<echa> ok
<ion> Its documentation could use some help.
<echa> hm
<echa> i'll try
<mtd> JanC: thanks, I was reading the Fedora manpages since I didn't have non-google access to the ubuntu ones (yeah I know echa asked about ubuntu...)
<JanC> what do you mean by non-google access ?
<mtd> JanC: presumably the ubuntu man pages are indexed by google a few times.
<JanC> they are at http://manpages.ubuntu.com/
 * mtd nods.
#upstart 2010-01-28
<Grimsqueaker13> Is there any proper current documentation for Upstart? Scott's blog posts are the only thing I can find and they're great but there's a ton of other things I need to know.
#upstart 2010-01-29
<lnx4ver> is it difficult to convert a rc.d script to upstart?
<JanC> lnx4ver: depends
<lnx4ver> my idea would be to convert all script in rc2.d to upstart but it doesn't seems to be an easy task, I'm wondering why some of them are not yet converted like sysklogd and  klogd on Ubuntu
<Md> lnx4ver: because it takes time. don't do it for distribution packages or you will break stuff
<ion> No, no, feel free to contribute patches converting distribution packages to Upstart. :-)
<lnx4ver> thanks for answers, well I'll take a look and see if I can find something there that don't have much depencies and is not indispensable to start with
#upstart 2010-01-30
<JohnFlux_> Hey all
<JohnFlux_> through dbus, how do I find the PID of a service?
<JohnFlux_> and why do I get AccessDenied  for everything ? :-)
<JohnFlux_> qdbus --system com.ubuntu.Upstart /com/ubuntu/Upstart/jobs/avahi_2ddaemon  name
<JohnFlux_> Error: org.freedesktop.DBus.Error.AccessDenied
<JohnFlux_> for example
<JohnFlux_> even running with sudo I get the same error
#upstart 2011-01-24
<ion> Left to right: open /var/log/foo for appending and replace fd 1 with it; replace fd 2 with a copy of fd 1. At that point, both file descriptors point to the file.
<tanepiper> yea thats better, no horrible output on the idle server screen now - thanks :)
<djszapi> How can I checkout the bazaar codebase, what is the VCS url ?
<djszapi> http://upstart.ubuntu.com/wiki/CompilingUpstart - http://upstart.ubuntu.com/wiki/ContributingCode - did not find the information here.
<plautrba> djszapi: On the first page is: 1. Get the code. Libnih is a utility library used by Upstart.  -> bzr branch lp:upstart
<plautrba> djszapi: web frontend is here https://launchpad.net/upstart
<djszapi> plautrba: that is just change the branch, but does not checkout the repository...
<djszapi> no, webinterface is not enough for hacking...
<plautrba>        bzr branch FROM_LOCATION [TO_LOCATION]
<plautrba>               Create a new branch that is a copy of an existing branch.
<djszapi> 10:23 < djszapi> plautrba: that is just change the branch, but does not checkout the repository...
<plautrba> djszapi: have you tried it?
<plautrba> lp:upstart is existing launchpad branch and you probably want local copy of that
<djszapi> k, it does not work
<djszapi> which port does it use ?
<plautrba> it works for me http://fpaste.org/YwdF/
<djszapi> glad to hear, but it does not help anything for me. Please try to answer my question, I am newbie at bazaar and I do not even like it.
<plautrba> sorry, i can't help you with bazzar, i use only three commands (branch, pull, diff) but try http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
<djszapi> pfff
<djszapi> it is not about frikking bazaar
<djszapi> come on I need the information which port it uses
<plautrba> $ grep bzr /etc/services 
<plautrba> bzr             4155/tcp                # Bazaar version control system
<plautrba> bzr             4155/udp                # Bazaar version control system
<djszapi> we have got a secure enough proxy, only http is enabled.
<djszapi> ty.
<djszapi> so I cannot checkout...
<djszapi> so I cannot work on it then...
<plautrba> djszapi: you can allways use tarball and apply patches
<djszapi> where can I download the  tarball of HEAD master ?
<plautrba> not sure if there is tarball of HEAD master but there is tarball of last release 
<djszapi> :))))
<djszapi> funny.
<djszapi> there is no http way in case bazaar to clone.
<djszapi> it is silly enuff.
<djszapi> A general way about a git repository: http/ssh/git/ protocol availability.
<djszapi> btw, last release does not really contain the updated codebase...
<djszapi> nor the libnih stuff...
<djszapi> logging.c fex.
<plautrba> there are 6 commits in upstart after release, it's not so much work to download patches from lp and apply them locally
<djszapi> pfff
<djszapi> no sorry I am not gonna spend my times with things I should not deal with.
<djszapi> I am just skippign this "patch is welcome" thingy.
<plautrba> it's like, sorry i locked my door so i can't go walk your dog ...
<djszapi> maybe that is why this software is abandoned
<djszapi> and no contributors apart from Scott.
<cchildress> hi all. i'm having trouble getting vsftpd and upstart to play nice. whenever i issue the "restart," "stop," or "status" commands on vsftpd, I get teh error "unknown instance"
<cchildress> if i issue the "start" command it tells me vsftpd is started/starting, and gives a pid
<cchildress> but then "sudo status vsftpd" immediately after gets "stopped/waiting"
<cchildress> like it says it's starting, but doesn't get started
<cchildress> any ideas? maybe i'm doing something wrong?
<JanC> cchildress: do you use "expect fork" or "expect daemon" ?
<JanC> it sounds like apport is looking at the wrong PID
<JanC> upstart I mean
<cchildress> JanC: not that i'm aware of
<cchildress> i'm not even sure what expect is haha
<JanC> "man 5 init" explains all stanzas you can use in upstart jobs
<cchildress> i'll check on that
<JanC> basically you tell upstart that there will be 1 or 2 forks to follow
<JanC> (in future versions this should become more flexible)
<cchildress> i'm sorry, but i'm not sure that i follow you
<cchildress> i know what a fork is, but what is meant by upstart following them?
<cchildress> all i really want to do, is be able to start or stop vsftpd
<cchildress> that's all
<cchildress> right now i can't seem to do either
<JanC> it needs to "follow" the forks to know what the PID of the actual running process is
<cchildress> ok
<cchildress> yes that makes sense
<cchildress> so are you saying that i'm getting the "unknown instance" error because it's not following the forked process correctly?
<cchildress> ok so i read through that manpage...but what am i supposed to make of it?
<cchildress> sorry i must seem pretty slow but i feel like i'm trying to do something so simple
<JanC> cchildress: it seems like vsftpd has an upstart job in Ubuntu 10.10, if you want I can put it on a pastebin for you
<cchildress> what would i do with that? place it in /etc/init?
<cchildress> and wouldn't that already be installed on my system when i installed vsftpd?
<JanC> are you using Ubuntu 10.10 ?
<cchildress> JanC: no, i believe i'm sticking with 10.04 for now
<JanC> cchildress: is there a vsftpd.conf in /etc/init/ ?  if not, 10.04 was still using a sysvinit script in /etc/init.d/
<cchildress> fwiw, http://ubuntuforums.org/showthread.php?t=1588568
<cchildress> yes, there is a vsftpd.conf in /etc/init
<JanC> that you on the forums?
<cchildress> so i see how i can keep it from running...but not how to check the status or stop it from the command line
<cchildress> no, just someone who has similar problems
<cchildress> i'm just trying to figure out why the standard "sudo service vsftpd stop
<cchildress> won't work
<cchildress> and why i can't check on the status
<cchildress> is there something wrong in the script or conf? or am i doing something wrong?
<JanC> vsftpd seems to start/stop/status/etc. fine on my 10.10 system
<JanC> did you change anything in the configuration of vsftpd?
<cchildress> no
<cchildress> i have avoided that because i don't want to break things
<JanC> no debug info in log files?
<cchildress> the vsftpd.log in /var/log is blank
<cchildress> what other log file can i check? there is not one for upstart
<cchildress> i'm at such a loss >.<
<cchildress> i loved the good old init.d scripts haha
<JanC> can you start vsftpd manually?
<cchildress> this thread has teh same problem: http://ubuntuforums.org/showthread.php?p=10361956
<JanC> hm, that looks like vsftpd forks one more time than expected?
<cchildress> maybe, but i don't know enough to say
<cchildress> i'm surprised that others haven't reported this problem
<JanC> do you also see the different PIDs like in that forum post?
<cchildress> my setup is pretty generic
<cchildress> i just checked through every running process...there is no vsftpd running
<JanC> so you start it, and then there is no vsftpd in ps output?
<cchildress> yeah
<cchildress> it gives me a pid, but i immediately check taht pid and nothing is running
<cchildress> it's like it's saying "ok i'm running here" but then silently failing or something
<JanC> but did you check for a vsftpd with another PID like in that forum thread?
<cchildress> yeah
<cchildress> not a single instance of vsftpd is running
<cchildress> even though the start command doesn't generate any errors
<JanC> do you have a listen option in /etc/vsftpd.conf ?
<cchildress> listen=yes
<cchildress> local_enable=yes
<cchildress> write_enable=yes
<cchildress> strange little problems like this drive me nuts
<JanC> cchildress: what happens when you run vsftpd from the command line?
<cchildress> 500 OOPS: config file not owned by correct suer, or not a file
<cchildress> i think we have a winner here...
<cchildress> fwiw, /etc/vsftpd.conf is root:root
<cchildress> /etc/init/vsftpd.conf is also root:root
<JanC> sounds right
<cchildress> so i don't know why it's complaining that the owner isn't right
<cchildress> i think i found my problem
<JanC> did you start vfstpd as root?
<cchildress> yeah i found my problem
<cchildress> vsftpd was failing to launch because "use_ssl" was enabled in /etc/vsftpd.conf
<cchildress> yet there was no rsa cert
<cchildress> so i commented out the line
<cchildress> and now it runs fine
<cchildress> for some reason, vsftpd never gave an error or even errored on the log, when run by upstart
<cchildress> only by manually running it as root did i get the error about ssl
<cchildress> so frustrating! lol at least it works now
<cchildress> thank you very much for patiently helping me, JanC 
<cchildress> btw, i'd like to report this as a "bug", since vsftpd gave no errors. would i report this bug to the upstart team, or vsftpd team?
<SpamapS> cchildress: just vsftpd I think. upstart already has a feature planned to log the output of jobs, but for now the programs need to handle their own error logging.
<SpamapS> cchildress: if vsftpd doesn't have a "check my configuration" option then I'm not sure we can do much.
<cchildress> fair enough
<cchildress> if upstart is already planning to log job output, then the "bug" will get fixed in time anyway
<cchildress> so i'll just leave it be. thanks for the info
<SpamapS> cchildress: its one of those things I'm really excited about for the future of upstart. :)
<SpamapS> Because I'm silly like that
<cchildress> yeah but that's an important feature!
<SpamapS> state rewrite.. mmm.. ok.. but log my job output to a ring buffer.. SWEET
<cchildress> for instance, if upstart had logged job output, i'd have known what teh problem was in the first few minutes...not after a half hour of head-scratching
<cchildress> but anyway yes that sounds like a great feature
#upstart 2011-01-25
<BaD_CrC> Is there a way to use Upstart as a daemon monitor? Currently I use 'monit' to monitor daemons, but it too is a daemon and tends to crash sometime. I'm just wondering if I can eliminate monit and put daemon checking in Upstart?
<JanC> BaD_CrC: upstart can restart daemons if they exit unexpectedly
<BaD_CrC> ok, the daemons currently start at boot, as expected. one daemon that crashes a lot is pdnsd. i want to figure out how to keep it running. like i said, i was using monit to watch it, but even it crashes sometimes.
<BaD_CrC> are there any good docs to lead me in the direction to using upstart for this task?
<JanC> init(5) documents all stanzas you can use in job definitions
<BaD_CrC> ok, i'll give it a shot. thank you.
<JanC> the 'respawn' stanza can be used to control respawning
<BaD_CrC> i think that's what i'm looking for.
<JanC> it also has a 'limit' parameter
<BaD_CrC> yeah, i'm looking over the manpage now. looks a little over my head at the moment. i'm sure if i go back and read it slowly, i'll get the jist of it. :D
<JanC> also check out existing jobs in Ubuntu as examples maybe
<BaD_CrC> yeah, i looked at the one for cron.conf and it gave me a good idea how to format the .conf file i will be making.
<BaD_CrC> i'm wondering if i should run the daemon directly or as 'exec service pdnsd restart'
#upstart 2011-01-26
<djszapi> Can upstart print now to the kmsg instad of the syslog with some option, configuration ?
<ion> kmsg can be written to by userspace programs?
<djszapi> ofc.
<djszapi> since 2002 or something very close to that.
<djszapi> this thread: http://lkml.indiana.edu/hypermail/linux/kernel/0208.1/1501.html
<djszapi> http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/bootlogd.c?root=sysvinit&view=markup
<djszapi> sysvinit can also do it.
<nodie> hi
<nodie> how can I set an environment using source ??
<ion> . /path/to/script
<ion> (!!!!!)
<nodie> :-m
<nodie> hi ion 
<nodie> exec . /path/to/script ?
<nodie> or just . /path/to/script ?
<ion> script
<ion>   . /foo/bar
<ion>   (use variables defined there)
<ion> end script
<nodie> ok
<nodie> and then, after the "." command I should use "exec program ...", isn't it?
<ion> yeah
<ion> Also note that the variables arenât exported. If you need that, do
<ion>   set -a
<ion>   . /foo/bar
<nodie> ok
<nodie> how can I get the output of the execution of a program?
<ion> As the first line of the script section,
<ion>   exec >/path/to/logfile 2>&1
<nodie> ok
<ion> Or >>/path/to/logfile if you want to append
<nodie> damn!! 
<nodie> I thought that the lines betwen script were in some special language xD
<nodie> and it was sh!
<ion> init(5)
<nodie> :)
<nodie> thanks ion, you saved my day :)
<nodie> the job name in "start on"/"stop on" is the same as the .conf file name?
<ion> yes
<nodie> so 
<nodie> if I add "stop on stopped X"
<nodie> and I stop X 
<nodie> then the process with "stop on..." should stop?
<ion> Yes. If you want your job to stop first, âstop on stopping Xâ
<nodie> ok
<nodie> I suppose it's the same for starting :)
<ion> yes
<nodie> :-m it doesn't work here
<nodie> do I need something more ?
<ion> If you run âstart yourjobâ, does it start properly? If you run âstop yourjobâ does it stop properly?
<nodie> yes
<nodie> call it job B (the one with "stop on stopping A" and "start on starting A")
<nodie> B start and stops
<nodie> A starts and stops
<nodie> but the event in A is not executed in B
<nodie> this is why I ask you if I need to add something more
<ion> Youâll most likely want either started/stopping or starting/stopped as the event pair for start/stop on.
<nodie> ok
<nodie> I want starting/stopped
<nodie> but it doesn't works here
<nodie> logs don't show anything special
<nodie> it just doesn't happens
<ion> Try running initctl log-priority info
<nodie> ok
<nodie> I see how process A (nginx) start and stops
<nodie> but I don't see any reference to process B (django)
<ion> Please pastebin django.conf
<nodie> http://dpaste.com/355958/
<nodie> oh! sorry
<nodie> I will paste the .conf
<nodie> http://dpaste.com/355962/
<ion> The latter start/stop lines override the former ones.
<nodie> o_O
<nodie> so?
<nodie> do I need to remove them or to change their position?
<ion> Remove them
<nodie> ok ion, I did that and now it works :D
<nodie> thank you very much!
<nodie> upstart is great but need better doc :-/
<ion> Granted, init(5) doesnât explicitly say multiple âstart/stop onâ lines donât work, but it does say how multiple start/stop events *are* given.
<ion> The documentation isnât that bad IMHO.
<ion> But sure, go ahead and file a bug report about the multiple âstart/stop onâ lines. Perhaps even provide a patch to the documentation. :-)
<nodie> I will try tomorrow if I've time 
<nodie> thanks ion :)
<nodie> bye!
<JanC> ion: there might still be how-tos about ancient upstart versions around that are now confusing people though (where multiple "start on" lines was allowed/required)
#upstart 2011-01-27
<kreign> hi, I'm trying to figure out what the upstart tool does on shutdown - eg. where the commands are defined that are run on shutdown
<kreign> there's /etc/init for startup but I'm not seeing where eg. filesystems get umounted on shutdown
<mbiebl> what distro?
<djszapi> JanC there ?
<djszapi> you tried last time to get the messages we discussed, can you remember ?
<djszapi> KeyBuk told me it is because upstart cannot log to the kmsg and the proper daemons are not running during the boot-session to get those messages into the syslog.
<djszapi> so I am trying to write a patch for upstart in order to be able to write into the kmsg for need.
<djszapi> JanC: so it should fex. work after the startup.
<SpamapS> kreign: shutdown happens on runlevel 0
<SpamapS> kreign: most of it ist still handled in /etc/rc0.d
<SpamapS> kreign: at least, in Ubuntu
<gp5st> i'm here (http://upstart.ubuntu.com/index.html) where can i find a list of all directives for an upstart script? the wiki seems more technical and doesn't help:(
<gp5st> but to the point, what i want to know is if there is respawn keyword, i've seen hints on other sites but i can't find one in the upstart page or man page
<JanC> gp5st: read the init(5) manpage
<gp5st> ah
<gp5st> the (5) is what must have got me
<gp5st> thanks:)
<JanC> http://manpages.ubuntu.com/manpages/maverick/en/man5/init.5.html
<gp5st> i found it, i was just doing man init before not man 5 init
<gp5st> :)
<JanC> there is a reference to init(5) at the bottom of init(8)  ;)
<gp5st> i'm sure:)
<kreignf> hi, I asked a question in here last night... does anyone know where the 'shutdown' time events are defined for upstart? eg. umount -a 
<JanC> kreignf: depends on how you or your distro configures it
<kreignf> JanC, :| ok, so where would I look? this is on ubuntu.
<kreignf> JanC, I've dug around a bit but can not find anything suggestive (eg. grep umount /etc/init/*)
<JanC> somebody answered that earlier today:
<JanC> <SpamapS> kreign: shutdown happens on runlevel 0
<JanC> <SpamapS> kreign: most of it ist still handled in /etc/rc0.d
<JanC> <SpamapS> kreign: at least, in Ubuntu
<kreignf> SpamapS, ah, thank you mate. ;P
<kreignf> JanC, didn't see it, passed out before I got a response. thanks.
<kreignf> not sure how i missed that on looking myself
<SpamapS> kreignf: its not very obvious honestly
<SpamapS> /etc/init/rc.conf covers it tho
<kreignf> SpamapS, I'm not so sure I like the... complexity... of upstart, vs. classic init, at this point. at least for a server.
<kreignf> SpamapS, seriously hope the intent is to have an all-in-one start/stop mechanism. 
<SpamapS> kreignf: its the complexity of the hybrid implementation that makes most uneasy. As it gets more purely upstart.. it will seem more elegant. :)
<kreignf> SpamapS, "sometimes it's set here and sometimes it's here" is not a good way to do it. :| 
<kreignf> SpamapS, right. 
<kreignf> SpamapS, I'm sure.
<kreignf> still, I'd think startup and shutdown would be handled by upstart, at the least. you know, 'system' tasks.. not relegating umount to rc
<SpamapS> I think that was the plan.. but the push in lucid was to get the bootup fast, not the shutdown. :)
<kreignf> heh
<SpamapS> and it actually works ok
<kreignf> well I know where to stick my command then
<kreignf> was kinda fading last night when I was looking into it
<SpamapS> there is a need for some more synchronization .. there are races right now that can lead to the fs's not unmounting I'm afriad.
<kreignf> not all cylinders were firing
<kreignf> SpamapS, oh joy. :|
<kreignf> SpamapS, where are the races?
<kreignf> in upstart?
<SpamapS> basically things that stop on runlevel [!2345] are not guaranteed to be stopped when fs's are unmounted
<kreignf> ah
<kreignf> eg. a long-terminating database process
 * kreignf considers a lengthy sleep
<kreignf> SpamapS, do the desktop guys push the ubuntu server direction quite a bit?
<kreignf> ubuntu server is a nice thing
<kreignf> (due to the newer kernel)
<kreignf> just not sure i like the... process refinement?
<kreignf> the resulting refinement is damn nice
<SpamapS> kreignf: ubuntu is ubuntu .. server and desktop are just different "seeds"
<SpamapS> kreignf: which affects the CD creation, and the length of security fixes.
<kreignf> SpamapS, I don't recall sources.list having a definite "server" tag ; what determines the seed, to the mirror?
<kreignf> or is it just a package selection that gets said support?
<SpamapS> I would say.. realistically.. lucid is just now stabilized and tested enough that I'd want to roll something out on it.. 10.04.2 is out in a week or two.. it has a lot of little weird things fixed.
<kreignf> SpamapS, yeah.
<kreignf> SpamapS, been a bit long in the uptake IMO
<kreignf> SpamapS, anything I can tell the kernel/upstart on boot to "tell me what you're doing!" ? I get "Starting /scripts/init-bottom... ; Done. Done. Finishing /scripts/init-bottom; Done - and then nothing
<kreignf> just hangs there
<kreignf> c-a-d reboots it
<kreignf> but other 'n that I can't do much
<SpamapS> kreignf: pass --verbose to the kernel
<kreignf> SpamapS, hmm 
<kreignf> SpamapS, would that be akin to "ro verbose" or do you mean --verbose?
<SpamapS> kreignf: at the end of the line in grub, add --verbose
<kreignf> SpamapS, the line starting linux, I presume
<kreignf> just not familiar with --verbose as an ammendum to kernel boot opts
<SpamapS> its unknown to the kernel, so the kernel passes it along to upstart
<kreignf> ah ok.
<kreignf> cool.
<kreignf> SpamapS, I'm getting some cryptic "init: hostname goal/state is start/stopping post-stop->waiting/etc." info here, and then it just hangs up /goes no further after "init: handling stopped event"
<kreignf> SpamapS, going to paste the image up
<kreignf> SpamapS, mind if I email you the image?
<SpamapS> kreignf: the lines before 'handling stopped event' are probably more interesting :)
<SpamapS> kreignf: what OS is this?
<kreignf> SpamapS, ubuntu
<kreignf> 10.04
<kreignf> LTS
<kreignf> SpamapS, that was a couple hours ago; I got by it. now I'm trying to figure out why the freaking modules I need aren't loading on boot (they're in /etc/modules) but load just fiiine on manual modprobe
<kreignf> heh
<kreignf> and it works on another system :P
<SpamapS> kreignf: /etc/init/module-init-tools.conf
<kreignf> SpamapS, so this is going to sound a bit cheap but I see something scroll by on intial boot 'failed' - but I'm not finding it in logs. it's directly before login starts. 
<kreignf> any idea where that'd be logged?
<SpamapS> alt-f7
<SpamapS> aka "the console"
<kreignf> yey
<kreignf> heh
<kreignf> unfortunately it does not appear to scroll. meh.
<SpamapS> kreignf: those should also end up in /var/log/boot.log
<kreignf> yeah
<kreignf> virtual console is slooow in vbox
#upstart 2011-01-28
<JanC> kreignf: are the modules not loading, or are they loading too late?
<JanC> remember that many upstart jobs run in parallel
<twb> Am I right in thinking that neither --verbose nor --debug show me the FOO=bar values associated with each event?
<twb> And if so, is there a way to see those values?
<kreign> SpamapS, I will say this... dear god it's awesome having a system boot 'completely' off of USB before I can walk the 5 feet to my keyboard
<kreign> ... and log in remotely
<twb> kreign: you using live-boot?
<kreign> twb, I'm not sure what live-boot is.
<kreign> twb, though it sounds interesting; what is it? :)
<twb> It's a fork of casper
<twb> With the idea of being useful for everybody, rather than just canonical
<kreign> twb, hmm no, I'm not all that familiar with it, to be honest. I was just trying to get upstart to work with zfs. 
<kreign> on ubuntu
<twb> zfs-fuse?
<kreign> no
 * twb blinks
<twb> There's an Ubuntu kFreeBSD now?
<kreign> no
<kreign> it's ubuntu with the CDDL ported modules. 
<kreign> just ubuntu
<kreign> takes about 10 minutes.
<kreign> ... just have to figure out the little 'ifs' and 'buts' :P
<twb> I guess that's OK if you don't redistribute the result...
<kreign> no
<kreign> but the knowledge of how to do so, or the deb packages, should be fair game.
<kreign> twb, if you're curious I'll stick in here tomorrow and give you the info
<kreign> time to put the kids to bed though
<twb> Not really; my money's on btrfs
<kreign> eh
<kreign> have you used zfs? :P
<twb> Yes, on osol.
<kreign> ah
<kreign> imo btrfs is years behind
<twb> Granted.
<kreign> I don't have time to wait around.
<kreign> for what I need, zfs is the trick
<kreign> stable or no
<kreign> (and it appears to be acceptably so, fwiw... I've not been able to break it yet, and the freebsd implementation is somewhat easy to cause issue with)
<kreign> at any rate
 * kreign poofs
<twb> But CDDL means that Debian can't ever distribute systems that support ZFS out of the box, so I'm not inclined to jump through hoops for it.
<twb> It's the same reason I avoid MP3
<JanC> kreign: there was somebody with the same problem last week or so
<SpamapS> twb: MP3 has an expiration date though
<twb> SpamapS: granted.
<JanC> kreign: and like I suggested before, your problem is that the module gets loaded too late
<SpamapS> if wikipedia is to believe, decoding may be patent free in the US just about the time the world ends, December 2012
<JanC> kreign: you need to make sure all zfs modules are loaded before trying to mount the ZFS filesystem...
<SpamapS> ahh yes
<SpamapS> startup and started udev will race with mountall
<twb> JanC: how do you do that?  Do you have to patch the mountall script to say start on [...] && modules?
<SpamapS> change it to 'start on mounting TYPE=zfs'
<SpamapS> mountall blocks on mounting and mounted events
<SpamapS> they are considered hook points
<SpamapS> its tricky, but if you look at the way nfs-ustils was recently patched in natty, you can actually use them in an and-like fashion with other events.
<SpamapS> ustils.. my typing has really suffered since losting my old MS elite keyboard.. need to go find another one. :-/
<JanC> I think a "task" that loads the zfs modules, and has "start on starting mountall" or something like that might suffice, but I would have to look into the logs what he finally used
<JanC> well, anything that makes mountall wait on that task to finish  ;)
<SpamapS> starting mountall might work too
<SpamapS> Actually yeah, since modules will always be on the rootfs, I think thats a nice simple solution.
<twb> SpamapS: no model M?
<djszapi> JanC: ping
<kreignf> JanC, for whatever reason, including the modules in /etc/modules does not result in them being loaded. not sure why.
<kreignf> JanC, also, I was that person with the problem last week. I never got it resolved then, though I figured out a workaround. :)
#upstart 2011-01-29
<Tack> "start rsyslog" outputs "start: Job is already running: rsyslog" but it definitely isn't.  "stop rsyslog" hangs indefinitely, but after which (if I ctrl-c it), "start rsyslog" no longer says it's running, but rather it hangs too.  Once I ctrl-c that, "start rsyslog" again says it's running.
<Tack> At no time does it get started though, and I'm quite confused as to what's happening.  Any ideas?
<Tack> (BTW this is on Ubuntu 10.04)
<ion> Have you modified /etc/init/rsyslog.conf at any time?
<Tack> ion: nope, it's stock.
<Tack> However ...
<Tack> https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/692919 is almost certainly what started it.  This happened following a package update last month some time.  I havne't had a chance to look into it until now.
<Tack> So it's entirely possible /etc/init/rsyslog.conf got replaced during the package upgrade.  It's dated 2010-12-10, so it's likely. 
<Tack> I've not modified it personally, though, nor changed its mtime.
<ion> What does âstatus rsyslogâ print?
<Tack> rsyslog start/starting
<ion> What does âpgrep -l rsyslogdâ print?
<Tack> Nothing, and it returns exitcode 1.
<ion> sorry
<ion> Ah, ok. (Had it printed anything, iâd have been interested to see pgrep -lf rsyslogd.)
<ion> âstatus rsyslog-kmsgâ?
<Tack> status: Unknown job: rsyslog-kmsg
<Tack> Possibly not present in Ubuntu 10.04
<ion> Ah, indeed.
<Tack> If I "strace stop rsyslog" it seems to be doing some dbus chatter over a unix socket (connect(3, {sa_family=AF_FILE, path=@"/com/ubuntu/upstart"}) and it hangs on poll() for that fd.   Maybe I need to bounce dbus-daemon?
<Tack> Nah, no effect. :)
<ion> No, thatâs not the problem and stracing start/stop/initctl doesnât help in diagnosing problems like this.
<Tack> Ah, I was afraid of that.
<ion> What does âstop --no-wait rsyslogâ print? How about âstatus rsyslogâ after that?
<Tack> # stop --no-wait rsyslog
<Tack> rsyslog stop/starting
<Tack> # status rsyslog
<Tack> rsyslog stop/starting
<ion> I guess youâll need to consult Keybuk for more ideas about debugging the issue. If you donât feel like waiting for him to appear on IRC, please file a bug in https://bugs.launchpad.net/ubuntu/+source/upstart (iâm not sure if itâs a bug in the upstart package or the rsyslog one) describing the symptoms (e.g. that âstop rsyslogâ blocks forever) and providing the output of âpgrep -lf rsyslogdâ, âstop --no-wait rsyslogâ, âstatus rsyslogâ, âstart
<ion> rsyslogâ and âstatus rsyslogâ again. Might as well attach the file /etc/init/rsyslog.conf as well, so it can be verified that the job definition hasnât become broken due to some bug.
<Tack> Can do, thanks.  Unfortunately I need to reboot this box soonish for a kernel upgrade, and that will almost certainly fix the problem.  I'll try to hold off for a couple days.
<ion> Alright, thanks
<Tack> Thanks for the tech support. :)
#upstart 2012-01-24
<trondm> Hi. I have an upstart job that emits an event. How can I get a different upstart job to restart when this event is emitted?
<jodh> trondm: creating a 3rd upstart job that specifies "start on some-event" and then "exec restart some-job" would do it.
<trondm> OK. Thanks.
<glenn___> Afternoon
<glenn___> Ive been working on precise for some days now, and im noticing that a lot of software doesnt have upstart scripts
<glenn___> What exactly are the guide lines on this?
<glenn___> Will each software package in precise come with upstart scripts?
<jodh> glenn___: we want to migrate SysV services to Upstart. See https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upstart-convert-main-initd-to-jobs
<glenn___> jodh: im trying to implement puppet
<glenn___> im having lots of troubles with init.d scripts, or non existent upstart scripts
<glenn___> fail2ban is not correct, postgresql fails
<glenn___> jodh: can I add software on that list?
<jodh> glenn___: Due to the number of packages available (incl. universe, multiverse, etc), we need help to work on this migration.
<glenn___> jodh: id be happy to help out with this
<jodh> glenn___: your help would be much appreciated; a lot of problems we see on Ubuntu come from SysV services (or the _interaction_ between SysV services and Upstart jobs). Life would be a lot simpler and safer if all the services were converted to Upstart jobs IMHO.
<glenn___> jodh: is it correct to say that if a good upstart job exists, all the /etc/rc* and /etc/init.d/ can be deleted safely?
<glenn___> for that package
<glenn___> jodh: im currently only seeing mysql and ssh in upstart for the software we support
<glenn___> jodh: my biggest issue is that even the sysv scripts are not working properly, i.e. status will give the wrong exit code
<jodh> "yes", atleast for Ubuntu, but the init.d scripts won't go away - they will still exist in debian. Added to which, when debian gets a current version of Upstart and the associated tooling support, the plan is to make the Ubuntu upstart jobs available in debian (since at that stage, debian will support multiple init systems).
<jodh> glenn___: please raise bugs if you find them.
<glenn___> jodh: what exactly is the way to go if i wanted to add an upstart script to a software package? 
<jodh> glenn___: you need to add a debian/<package>.upstart file.
<glenn___> jodh: i never did work on packages before, hence my question :)
<jodh> glenn___: I'd strongly recommend you read this first then: https://wiki.ubuntu.com/PackagingGuide/Complete
<glenn___> jodh: im only interested in the upstart scripts
<jodh> glenn___: although nominally as simple as creating that one file, it takes a lot of effort to test the package and to ensure you've written the upstart job correctly.
<glenn___> jodh: why dont package maintainers make the upstart scripts themselves?
<jodh> glenn___: ok, if you'd like to contribute some upstart conf files that would be great.
<jodh> glenn___: they do (?)
<glenn___> yeah
<glenn___> people just created packages without upstart scripts
<glenn___> its weird to me
<glenn___> or failing sysv scripts regarding the exit code
<jodh> glenn___: remember that a large number of ubuntu packages originate in debian - where upstart support is poor currently. Hence, there is currently little incentive for debian devs to create the upstart file as that wouldn't (couldn't really) be used in debian (currently).
<glenn___> upstart in precise: fail2ban, postgresql, puppet, varnishd, haproxy, denyhosts
<glenn___> jodh: oh ic
<jodh> glenn___: if you've found a bug with a failing sysv init script, please raise it providing as many details as you can.
<glenn___> jodh: that explains a lot
<glenn___> jodh: people arent really pushed towards creating upstart scripts in debian yet :)
<jodh> glenn___: we are trying to address these issues though. any help you can provide would be very valuable to debian+ubuntu.
<glenn___> jodh: so if i would create an upstart script for a package, i would actually have to create the package myself ?
<jodh> glenn___: no, but as you can see from the size of that packaging document, there is a lot of detail and process to understand before you can make changes to a package.
<glenn___> jodh: yeah its very big
<glenn___> jodh: but the upstart scripts seems pretty evident to me.. just 1 file in /etc/init 
<glenn___> jodh: at least, thats how i fix it now while testing precise
<glenn___> jodh: to be honest, it is not really easy to get an upstart script into a package :)
<glenn___> at least, thats how it looks te me
<jodh> glenn___: if you have manually converted a sysv job to an upstart .conf file, please raise a bug on the ubuntu package, attach your config and we'll review it and get it added to the package if possible.
<jodh> glenn___: if you haven't already seen it: http://upstart.ubuntu.com/cookbook/#how-to-establish-a-jobs-start-on-and-stop-on-conditions
<jodh> glenn___: testing is extremely important though - creating the .conf file is the first step. But testing is required to ensure it will work in all runlevels, if certain packages are not installed, etc.
<glenn___> jodh: so if correct, if i would have a upstart script, i could raise a bug on that package with my config in it?
<glenn___> jodh: and in regard to ubuntu versions, like LTS (lucid, precise), can they have the same upstart script?
<jodh> glenn___: yes - someone else with packaging experience can then add it to the appropriate package and test it.
<glenn___> jodh: thats cool, and works good for me
<jodh> glenn___: it's much more likely to be made available for precise.
<jodh> glenn___: great, thanks.
<glenn___> jodh: im trying to report a bug, would this title/summary make sense: SysV script returns the wrong exit code when fail2ban is not running
<jodh> glenn___: makes sense to me :)
<glenn___> jodh: it is just for the status command, should that be in there?
<glenn___> im trying to make sure im having a good example, for next bugs :)
<glenn___> perhaps this is better: SysV status script returns the wrong exit code when fail2ban is not running
<jodh> glenn___: right.
<glenn___> awesome
<glenn___> jodh: would package maintainers know enough if the bug is stating the exit code is wrong?
<jodh> glenn___: please give an actual example on the bug as this will make analysis and thus resolution easier.
<glenn___> i understand, but im more wondering if i should also put in the code to perhaps fix it
<glenn___> before i submit the bug :)
<jodh> glenn___: if you have a fix, yes please provide it. I wouldn't hold off raising the bug though.
<glenn___> https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/920995
<glenn___> i suppose this i something :)
<jodh> glenn___: thanks.
<glenn___> jodh: first of many :)
<glenn___> jodh: btw, thank you !
<glenn___> jodh: do you have an example bug for an upstart script request?
<jodh> jodh: np. you might want to hang out on #ubuntu-devel if you're interested in getting involved.
<glenn___> glenn: what exactly is nice about having in ubuntu-devel? :)
<glenn___> s/having/hanging
<jodh> take a look. This channel is for upstart-specific discussion, so we're getting a bit off topic here.
<jodh> afk...
<glenn___> ello
<glenn___> when im using upstart to start puppet im having troubles. upstart gives the wrong pid back.
<jodh> glenn___: Read this section carefully - http://upstart.ubuntu.com/cookbook/#expect in particular http://upstart.ubuntu.com/cookbook/#when-wrong-pid-is-tracked
<glenn___> jodh: that will help :)
<glenn___> jodh: it seems it forks 23 times after i start it, pretty weird if you ask me
<glenn___> tomorrow another day
<SpamapS> glenn___: its forking running things that it needs
<SpamapS> glenn___: perhaps it doesn't need to use 'expect fork' ?
#upstart 2012-01-25
<glenn___> spamaps: ive been trying out all the options, expect fork, expect daemon, expect stop... even tried no expect
<jodh> glenn___: you need to know how many times the app forks initially before it is ready to start its real work (in other words its initialisation phase).
<glenn___> jodh: i tried the count on fork/clones... it is about 22
<glenn___> but the strace is showing clones, not forks
<jodh> glenn___: the maximum any process needs to fork is twice before it is fully initialized.
<glenn___> jodh: so the guys cant code at puppetlabs? :)
<jodh> glenn___: any further forks are for setting up "helpers". You don't care about those though - you need the pid of the master parent process before it does its fork bomb.
<glenn___> jodh: the master process is about 22 pids later
<jodh> glenn___: it can't be.
<glenn___> ill show you
<glenn___> root@puppetclient:/etc/init# start puppet
<glenn___> puppet start/running, process 1142
<glenn___> root@puppetclient:/etc/init# ps auxf |grep puppet
<glenn___> root      1167  0.0  0.0   9744   876 pts/0    S+   10:46   0:00          \_ grep --color=auto puppet
<glenn___> root      1163  7.0  3.9 122540 40488 ?        Ssl  10:46   0:00 /usr/bin/ruby1.8 /usr/bin/puppet agent
<glenn___> root@puppetclient:/etc/init# 
<glenn___> i can use the init script to shut it down, not with upstart
<glenn___> init script is using the pid file
<glenn___> root@puppetclient:/etc/init# grep clone /tmp/strace.log | wc -l 
<glenn___> 24
<glenn___> 1217  clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6ee51809f0) = 1218
<glenn___> etc etc
<glenn___> 1217  clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6ee51809f0) = 1238
<glenn___> it behave the same for version 0.25 2.6 and 2.7
<glenn___> the expect options go to a max of 2, i think with daemon
<glenn___> so either upstart isnt the right tool, their daemon is weird, or i just dont get it
<glenn___> ive been trying for at least an hour :)
<glenn___> fyi, the daemon is just a ruby script, starting puppet from ruby
<glenn___> i suppose thats causing the problem
<jodh> glenn___: as stated, there is no reason to fork more than twice (that's why upstart only tracks up to 2 forks). I think you should talk to the puppet guys to understand what is going on there. For now, you might need to consider using start-stop-daemon with upstart: http://upstart.ubuntu.com/cookbook/#alternative-method
<glenn___> jodh: i think i picked the wrong software to test upstart :)
<jodh> glenn___: this isn't a problem with upstart - it's either ruby and/or puppet.
<glenn___> jodh: hence my point :) i picked the wrong software <- puppet
<jodh> glenn___: are you using "respawn" by any chance?
<glenn___> jodh: if i use any expect it all start will hang
<glenn___> s/it/at
<jodh> glenn___: but are you using "respawn"?
<glenn___> jodh: nope
<glenn___> that started the process several times
<glenn___> :)
<glenn___> jodh: sorry i misread i thought u said expect instead of respawn
<jodh> glenn___: ok. please keep us posted on this as we need to understand exactly what is going on here.
<glenn___> jodh: im trying to get it to work with start-stop-daemon first, then ill try the puppetlabs guys
<glenn___> which doesnt work at all :(
<glenn___> exec start-stop-daemon --start --exec /usr/bin/puppet agent
<glenn___> i did a reboot though, now its starting
<glenn___> still the same issue though, seems to make no difference
<jodh> glenn___: what problem? why are you rebooting? I'd get puppet working with start-stop-daemon on the command-line first, then put that into an upstart .conf file.
<glenn___> jodh: it is working on the commandline
<glenn___> jodh: i tried start puppet, it hangs, i reboot, i start it again and it works
<glenn___> jodh: i tried several reboots :) the upstart wass messed up
<glenn___> sometimes it even keeps track of the pid while that id is not even there anymore
<jodh> glenn___: that's telling you your .conf file is incorrect - upstart just does what you tell it to :)
<glenn___> there is just a few lines
<glenn___> to be exact 4
<glenn___> description     "puppet client"
<glenn___> start on filesystem or runlevel [2345]
<glenn___> stop on runlevel [!2345]
<glenn___> exec start-stop-daemon --start --exec /usr/bin/puppet agent
<glenn___> also when i try stop, it says unknown instance, which would mean the job is not running, while it is... 
<glenn___> need more spresso
<jodh> glenn___: your 'start on' is incorrect - that will try to start *two* instances of the job (which will fail).
<jodh> glenn___: make it 'start on runlevel [2345]'
<glenn___> same behaviour
<glenn___> i dont think this will work with upstart :(
<glenn___> for now
<glenn___> i have an idea perhaps it will help 
<jodh> glenn___: glenn: 'exec start-stop-daemon --start --exec /usr/bin/ruby /tmp/fork.rb' works as expected for me.
<glenn> jodh: thanks for checking
<glenn> jodh: it just does 1 fork i suppose?
<glenn> jodh: could show me the contents of that ruby file
<jodh> glenn: http://paste.ubuntu.com/816328/
<glenn> jodh: yup seems to work correct
<glenn> jodh: when i include their code in the fork.rb script it forks 21 times
<jodh> glenn: maybe you should raise a bug on that - sounds broken.
<glenn> this is kind of nice
<glenn> there is a flag called --no-daemonize, with that it works as expected
<jodh> glenn: great. please raise the issue with the puppet folk though as it sounds like there is a bug in there.
<glenn> im staring at their ruby code for half an hour now :) maybe ur right
<glenn> interesting material though
<glenn> they are using Process.detach
<glenn> lol :)
<glenn> jodh: jodh: im pretty sure its something weird in their code
<glenn> http://paste.ubuntu.com/816410/ http://paste.ubuntu.com/816411/
<jodh> 'music
<jodh> oops :)
<glenn> music? :)
<glenn> jodh: i appreciate ur help btw 
<jodh> ignore - tmux window searching :)
<glenn> learning a lot regarding upstart
<glenn> should just use spottify :)
<jodh> glenn: glad your'e making progress. afk for a while ...
<glenn> jodh: im filing a bug at puppetlabs right now after discussing it with someone in their irc-channel
<jodh> glenn: great news!
<glenn> jodh: Yup :)
<glenn> jodh: im not exactly sure what to file but hey :P
<glenn> its something with redmine facter within puppet
<glenn> its doing system calls to which, ifconfig, hostname things like that
<glenn> that seems to spawn the forks
<glenn> which seems correct because in the strace there is exec's to that
<glenn> jodh: and i probably have a workaround for now to upstart
<glenn> woot :)
<glenn> root@puppetclient:~# start puppet
<glenn> puppet start/running, process 1806
<glenn> root@puppetclient:~# stop puppet
<glenn> puppet stop/waiting
<glenn> nice
<glenn> :)_
<glenn> jodh: for my understanding, if software is daemonized, this should take no more then 2 forks?
<jodh> glenn: there is no additional benefit to forking more than twice.
<glenn> jodh: could you explain that a bit more
<jodh> glenn: not right now (in a meeting). it's standard unix/linux semantics though.
<SpamapS_> glenn: I'm curious what your workaround was
<glenn> spamaps: ah :) ill paste my script
<glenn> spamaps: im kind of confused still, regarding the max of 2 forks in upstart
<glenn> spamaps: im using the --no-daemonize function for puppet 
<SpamapS> glenn: puppet may be an example of something that reasonably *does* fork twice before daemonization for legitimate reasons.. I think this may be worth a bug report in upstart
<SpamapS> Why shouldn't a program be able to exec stuff before it daemonizes itself?
<glenn> spamaps; thats the same disucssion i had with our developers
<SpamapS> jodh: ^^ Perhaps 'expect exit' will fix this?
<glenn> spamaps: maybe it should track only forks of itself, instead of all other calls
<glenn> spamaps: upstart seems to track all pid's instead of just the forking of the daemon itself
<SpamapS> glenn: well its trying to figure out what the "main" pid is
<glenn> spamaps: i understand
<SpamapS> The method it uses works for most regular daemons.
<glenn> spamaps: but in the puppet case, it does about 20 system calls, and then it has all the information for starting the daemon (dont ask me why)
<SpamapS> glenn: I think I understand why.. and this is an example of where expect fork is just incapable of doing it right
<SpamapS> So --no-daemonize is the only other option.. though then you have the trouble of needing to write a post-start which determines when the daemon is actually ready
<glenn> its working properly already
<glenn> when puppet is not daemonized it will run in the foreground, and thus not doing forks to system calls
<glenn> or however i should pronounche this :)
<SpamapS> glenn: perhaps puppet should add a --upstart mode where it sends itself SIGSTOP when it is ready (upstart will SIGCONT it)
<SpamapS> glenn: then you could use 'expect stop'
<glenn> spamaps: yeah that would be a solution
<SpamapS> glenn: you're saying system calls, but what you mean is it is forking and execing system programs, I assume
<glenn> spamaps: i think so yes :)
<glenn> spamaps: correct me if im wrong, this is kind of new genre too me
<glenn> the paste right
<SpamapS> glenn: that should be valid and expected behavior for lots of daemons, not just puppet.
<glenn> spamaps: but its not really nice of upstart to say: build in an upstart function :)
<glenn> else we dont support you
<glenn> the problem exists because upstart wants to track the pid itself
<glenn> my mind is boggling
<glenn> http://paste.ubuntu.com/816657/
<glenn> there this is one works
<SpamapS> glenn: well its more of upstart saying "help us determine your pid"
<glenn> spamaps: puppet creates a pid file already
<glenn> spamaps: why would upstart need to find it again? :)
<SpamapS> glenn: IMO, upstart should have the ability to use pidfiles, but Keybuk is (was?) convinced that pidfiles are too unreliable.
<glenn> spamaps: upstart is more unreliable
<glenn> :)
<SpamapS> Not sure I agree with that
<glenn> spamaps: concerning starting software
<SpamapS> but I can see how it might feel that way given the difficulty in writing jobs
<glenn> i was reading the cookbook
<glenn> it seems really awesome
<glenn> a new init
<SpamapS> glenn: upstart is actually quite reliable.. its just that it reliably does weird things. :)
<glenn> its fast, parallel et
<glenn> but the pid tracking, is really weird
<glenn> i did some reboots, and even 2 reinstalls (through auto deployment)
<glenn> it was tracking pid's that didnt exist
<SpamapS> using ptrace the way it does is the only thing I don't like
<glenn> even restarting upstart didnt help
<SpamapS> glenn: the tracking pids that don't exist thing is a known bug
<SpamapS> glenn: happens whenever you use expect fork on something that doesn't fork
<SpamapS> glenn: or.. something like that, I forget. Anyway, there's a workaround that doesn't require a reboot.. but it does require you to exhaust pid space and roll-over
<SpamapS> glenn: anyway, the --no-daemonize option is still the simplest. But again, if you have other things that might depend on it running.. you need to have a post-start that verifies it is ready to serve their requests.
<SpamapS> also the --no-daemonize thing fails on programs that fork/exec/exit on SIGHUP .. which I just figured out python-paste does.
<glenn> spamaps: ah ok, i tried the expect option, that probably created the issue
<glenn> spamaps: spamaps: --no-daemonize is a flag specific for puppet
<SpamapS> glenn: right, its pretty common for daemons to have a "stay in the foreground" flag tho
<glenn> spamaps: still, the pid tracking seems a bit strange
<glenn> spamaps: i can imagine a lot of software does exec system programs before it starts
<glenn> + as daemon
<SpamapS> glenn: when daemons behave the way upstart expects them to, its quite nice. But I estimate thats only about 50% of daemons that I've tried to write jobs for
<glenn> spamaps: well if upstart wants to be ground breaking, either a pid file support should be available, or software developers need to code in sigstop 
<glenn> spamaps: i dont think there is a common practice for this when developing software 
<glenn> spamaps: the only thing i could think of is that there should be a pid file 
<glenn> spamaps: which there is, but upstart wont support it
<glenn> spamaps: also, software like puppet is supported on redhat and not on ubuntu
<SpamapS> glenn: thats just crazy talk. puppet is very well supported on Ubuntu
<SpamapS> glenn: upstart's pid tracking is not necessary to use services.
<SpamapS> glenn: you can have an upstart job with no pid, that just tracks whether or not the boot/shutdown thinks it should be started/stopped
<glenn> spamaps: the enterprise version is indeed supporting ubuntu now, sorry for that
<SpamapS> and puppet is in main
<SpamapS> so it is supported by Canonical
<glenn> spamaps: i had the newer puppet backported to lucid
<glenn> from onerice
<glenn> -e
<SpamapS> I think we (Ubuntu) should backport more stuff to LTS's
<glenn> spamaps: i had some great help from people at ubuntu getting this to work
<glenn> took about 1 month i guess
<glenn> now 2.7.1 is in lucid backports
<SpamapS> glenn: thank you for working on backports then!!
<glenn> lol np
<SpamapS> I hope to have some official Canonical resources working on backports going forward
<SpamapS> at least, for server
<glenn> that would be nice
<glenn> i did some cool stuff to debian preseed too :)
<glenn> but that was just on my side, not on the preseed package
<trondm> can an upstart job tell the difference between a restart and stop? i.e. can I make my job do something else than a simple stop/start during a restart?
<SpamapS> trondm: no
<SpamapS> trondm: restart simply changes the goal to stop, then back to start
<SpamapS> trondm: its a dangerously misunderstood command.. it does not re-load the upstart job.
<trondm> Ah. Too bad. 
<trondm> In my case, I have a parent job than spawns several instances. I'd like each instance to be restarted separately when the parent is restarted, instead of having them all be stopped, then started
<glenn> trondm: it sounds the same, restart them all, or stop them all and start them all
<trondm> It's not a huge problem, though (and this is the way it worked before I started using upstart)
<trondm> (I was just hoping it would be possible to improve on the current state)
<glenn> trondm: is there is difference when you restart your instance or stop/start your instance?
<trondm> glenn: there's a difference between stop/start 0; stop/start 1; stop/start 2; and stop 0 1 2; start 0 1 2. Basically I'm offline for a shorter period if everything stops, then starts. 
<glenn> as far as i knew restart == stop -> start
<glenn> oh ic
<glenn> maybe you can create several jobs?
<glenn> or would that do the same
<trondm> I think that would do the same. Part of the problem is that the parent is an instance itself, and it's not possible to use variables in the "stop on" stanza. So I have a "post-stop" script in the parent that stops all child-instances
<glenn> hey spamaps you know what would be nice
<glenn> the documentation regarding expect doesnt mention what to do if there is more then 2 pid forks
<glenn> i.e. you should change the software, or use sigstop
<glenn> jodh: spamaps: http://projects.puppetlabs.com/issues/12146
<glenn> i just made this issue
<glenn> hopefully it makes sense 
<glenn> thanks a bunch again for your support/help really appreciate it
<glenn> im off, gonna play starcraft 2
<glenn> yo
#upstart 2012-01-26
 * trapni waves
<trapni> hey. did anyone ever run into http://pastie.org/3255470 while trying to install upstart from source?
<jodh> trapni: I'm guessing you are attempting to build this on lucid?
<trapni> jodh: exactly! :)
<trapni> jodh: the thing is, I have to use lucid
<jodh> trapni: problem is that your libnih and also your libdbus are too old - no support for DBUS_TYPE_UNIX_FD.
<trapni> jodh: and unfortunately, the other thing is, I cannot use OpenVZ, so I am using linux-vserver (lucid is the guest, Gentoo is the hypervisor), and I am trying to get around the getpid() > 1 error
<trapni> aha!
<trapni> yeah, just installed libnih from source (1.0.2)
<trapni> so I got to install dbus from source, too?
<trapni> or can I just add another repo to the sources.list w/o conflicting too much against lucid?
<trapni> I am not *that* experienced with ubuntu yet :|
<jodh> jodh: I believe you'll need to rebuild dbus, yes.
<trapni> fine with me, just wanted to make sure there's something better in place :)
 * trapni just hopes these packages will not conflict with the remaining binaries in the system :)
<jodh> trapni: good luck!
<trapni> haha, thanks :)
<trapni> jodh: maybe you know, is it okay to just ./configure --prefix=/usr or how's dbus configured on ubuntu for the bin packages?
<trapni> ah, and --sysconfdir=/etc/dbus-1
<jodh> trapni: here's the current i386 lucid build log showing the configure line: https://launchpadlibrarian.net/76041392/buildlog_ubuntu-lucid-i386.dbus_1.2.16-2ubuntu4.3_BUILDING.txt.gz
<trapni> ah
<trapni> thanks :)
<trapni> jodh: hm, that's strange, the log says  --sysconfdir=/etc but on my system it seems to be /etc/dbus-1 ...
<jodh> trapni: maybe the 'dbus-1' gets tacked onto sysconfdir prefix?
<trapni> that would be unusual, but i'll see
<trapni> jodh: I start to get the feeling, that I have to compile more by hand on non-source distros as on source distros :-)
<trapni> jodh: you were right, --sysconfdir=/etc puts files into /etc/dbus-1.
<trapni> whatever...
<trapni> jodh: http://pastie.org/3255560 now I am running into this compile error :(
<trapni> do you know where this comes from?
<jodh> trapni: looks like the build isn't using the latest version of nih-dbus-tool
<jodh> trapni: check your path to ensure it's picking up the version from your 1.0.2 build.
<jodh> trapni: if it is, make sure you reconfigure.
<trapni> mhm...
<trapni> yep
<trapni> i'm getting crazy, make distclean && ./configure --the-recommended-things && make runs now into http://pastie.org/3255572 (nih-dbus-tool --version returns 1.0.2)
<trapni> should I try 1.0.3 instead? (AFAIR I could download that one, too on code.google.com)
<jodh> trapni: it stil looks like you're using the wrong nih-dbus-tool.
<trapni> hmm
<trapni> trying to reinstall nih then
<trapni> jodh: not that wrong, look at http://pastie.org/3255626 /usr/bin/nih-dbus-tool links against [no /usr]/lib/libnih.so.1
<trapni> it's because libnih1's lib is in /lib, but I passed --prefix=/usr to it
<trapni> jodh: I am really pretty sure to run against the right libnih/dbus version, please see http://pastie.org/3255731 - hope it helps :)
<jodh> trapni: you're using an old nih-dbus-tool - you need 1.0.3
<trapni> mom
<trapni> jodh: okay, I read about >= 1.0.2 in configure.ac. let me use 1.0.3 then :)
<jodh> trapni: why did you choose 1.0.2 out of interest?
<trapni> jodh: because that's been what I read in upstart's configure.ac file
<jodh> trapni: you're using an old upstart too though :)
<trapni> lucid comes with 1.0.1 by default, so upstart's ./configure script failed initially
<trapni> I first just hacked this line to 1.0.1 and assumed it's just containing "bug fixes" as diff between 1.0.1 and 1.0.2, however it appearantly didn't
<trapni> so I reset upstart's configure{,.ac} and installed libnih 1.0.2 from source, and then ran into the dbus issues
<trapni> feel all like a mess
<trapni> jodh: but FYI, with 1.0.3 the upstart now compiles fine :)
#upstart 2012-01-27
<bradleyayers> I'm a bit confused about what http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions means
<bradleyayers> I was under the impression that upstart tracked the state of jobs, and would start jobs when their conditions were met
<bradleyayers> would the situation (in that link) be any different if a 'stop on â¦' was defined?
<bradleyayers> would it be any different if 'respawn' was specified?
<SpamapS> bradleyayers: upstart tracks the state of jobs, but it only changes their goal-state on events, not conditions. Its a subtle difference.
<SpamapS> bradleyayers: that section is a bit ambiguous.. I'm going to propose a slight change.
<bradleyayers> so say i have a job X that "start on started A and started B", and "stop on stopping A or stopping B". A starts, then B starts, so 'started JOB=B' would be emitted, which would cause X to start right?
<bradleyayers> then B changes its goal to stopped, so 'stopping JOB=B' would be emitted, which would cause X to change its goal to stopped, right?
<bradleyayers> so then let's say X stops, then B stops
<bradleyayers> what happens when i do 'start B'
 * SpamapS draws it in his head
<SpamapS> bradleyayers: it blocks
<SpamapS> bradleyayers: until started A is emitted
<bradleyayers> you mean started X?
<SpamapS> no
<bradleyayers> :O
<SpamapS> because it is started A and started B ...
<SpamapS> the and blocks
<SpamapS> which is why and's require careful consideration
<bradleyayers> oh okay, so B starts fine
<SpamapS> bug #447654
<bradleyayers> but then A stays with its goal as stopped
<bradleyayers> aaa
<bradleyayers> awit
<bradleyayers> !!!
<bradleyayers> Z stays with its goal as stopped**
<bradleyayers> X
<SpamapS> we had no Z!
<bradleyayers> i know :(
<SpamapS> ok
<bradleyayers> I'll start again
<SpamapS> yes X stays with its goal as stopped
<bradleyayers> B starts properly
<bradleyayers> then X stays with its goal as stopped
<SpamapS> and perhaps more importantly, the started event for B is not "finished".. its blocking
<SpamapS> so while B is started, the 'start' command (or event) will be waiting
<SpamapS> There are times where this doesn't matter
<SpamapS> you can use 'and' freely when the events that you are 'and'ing are never waited for
<bradleyayers> but how can 'started' ever block, it's an event
<SpamapS> for instance, the 'filesystem' event or the 'net-device-up' events aren't waited on
<SpamapS> bradleyayers: ALL events can block
<SpamapS> it is critical to the proper sequencing of the boot
<bradleyayers> http://upstart.ubuntu.com/cookbook/#event-types says Signals don't block
<SpamapS> for instance, the starting event needs to block, so that whatever you're trying to start before, doesn't start until you yourself are started
<bradleyayers> which 'started' is
<SpamapS> bradleyayers: signals aren't waited on.. but they actuall do still block.. :-/
<bradleyayers> i should have said: "but how can 'started' ever block, it's a *signal*"
<SpamapS> actually I should say
<bradleyayers> ah okay, i didn't realise there was a difference between block and waited on :/
<bradleyayers> my misunderstanding
<SpamapS> started is not a signal
<SpamapS> well it might be actually
<SpamapS> I suppose it is since nothing is waiting for it.
<SpamapS> starting, however, is always waited on
<bradleyayers> that's my understanding too
<bradleyayers> starting is a 'method event'
<bradleyayers> or probably 'hook'
<bradleyayers> so back to my original scenario, 'starting B' would be emitted, i dont understand why that doesn't trigger X's condition to be re-evaluated
<bradleyayers> i'll read over bug #447654
<SpamapS> bradleyayers: the condition is evaluated, and B's event satisfies only one side of it.
<SpamapS> bradleyayers: since it is an and, you need to have A's started event *again*
<bradleyayers> i see
<SpamapS> bradleyayers: the disconnect that nearly everyone experiences is that they are events, not states, and so are inherently ephemeral.
<bradleyayers> yeah :(
<bradleyayers> i get it now
<bradleyayers> so this definitely hasn't been fixed yet?
<SpamapS> No, it effectively needs a rewrite of the event loop to add the ability to observe states.
<SpamapS> In practice, it can be worked around with the 'wait-for-state' job.
<SpamapS> bradleyayers: is this your bug btw: https://bugs.launchpad.net/upstart-cookbook/+bug/912348
<bradleyayers> yeah that sums up what my question was
<SpamapS> Cool, I just pushed up a merge proposal https://code.launchpad.net/~clint-fewbar/upstart-cookbook/clarify-complex-start-stop/+merge/90379
<bradleyayers> i'd probably bold "is not known to upstart"
<bradleyayers> but otherwise it looks good
<bradleyayers> but a bit hard to be objective now that I actually understand it
<SpamapS> bradleyayers: agreed on the bolding, pushed that up
<bradleyayers> cool
<bradleyayers> hey SpamapS thanks for the help before
#upstart 2013-01-21
<sveinse> Are there any activity here? Anyways. telinit can be used asynchronously to change runlevel. How can I use initctl to do it synchronously? With that I mean that it does not return until all events regarding the runlevel change has been started
<sveinse> Well I found it: initctl emit runlevel RUNLEVEL=... 
<xnox> =)
<jodh> xnox: have you spoken to the desktop folk about a fallback for XDG_RUNTIME_DIR?
<xnox> no.
<xnox> jodh: who was our desktop team contact / driver behind the spec?
 * xnox adds a note to my backlog.
<jodh> xnox: nobody nominated - I'd try pitti/seb128 for starters.
<jodh> xnox: we really need to try to get all outstanding branches merged this week. Added to which, I'm starting on list-sessions which will need the same code to find the session files.
<jodh> xnox: we'll go over all this in the meeting later.
<xnox> ack.
<jodh> xnox: you haven't started on the ':sys:' / ':user:' code yet have you? If not, I'm about to look at it.
<xnox> jodh: nope. Go ahead =)
<sveinse> Are there any ways to set a environment from a file in upstart. I have a service which needs the LANG environment var set. The value of this var can be read from /etc/locale. I'd like to avoid wrapping the exec with sh if possible
<sveinse> *reading 8.2 in cookbook....*
<xnox> sveinse: here is verbose example of sourcing settings: http://upstart.ubuntu.com/cookbook/#pre-start-example-ubuntu-specific
<sveinse> xnox: Yes, that is one half of it. What I'm wondering when reading the env var example in 8.2 is that does export var in pre-script make the var visible for the binary run by exec?
<xnox> sveinse: no.
<xnox> (as far as I currently tested locally)
<sveinse> hmm,ok . So I probably need to wrap the executable in a script section...
<xnox> sveinse: exec LANG=C.UTF-8 mydaemon
<xnox> should work as well, but that will also be executed via shell.
<sveinse> xnox: If it was so simple... exec LANG=$(cat /etc/locale) mydaemon  would be more correct
<xnox> $ cat /etc/locale
<xnox> cat: /etc/locale: No such file or directory
<sveinse> But it seems wrapping through sh seems inevitable 
<xnox> the correct way is to call $ locale and use that output (for me that defines en_GB.UTF-8 correctly)
<sveinse> on this system /etc/locale will always exist, but anyways, since I can't pass pre-script variables into the main exec, it seems I have to use the shell to start the daemon
<sveinse> baah. Of course. I can use script and call the daemon with exec. This way I can load the environment I need.
<xnox> yes. =)
<xnox> pre-start script - is only usually used for sanity checking if daemon can / cannot start & e.g. abort if not properly configured.
<jodh> xnox: you about for the meeting?
<xnox> yeap
<jY> i'm using ubuntu 10.04 and an upstart job is hanging for start/stop.. no expects in there
<jY> what can i do to debug it?
#upstart 2013-01-22
<stgraber> jodh: gosh, 15k long test file, there goes my plan to read through test_initctl.c ;)
<jodh> stgraber: I'd look at test_show_config() and test_reexec() in that file.
<stgraber> jodh: my plan for an easy test is to add code to test_upstart_open which tests that initctl connects to the bus set in UPSTART_SESSION if it's set and fails if UPSTART_SESSION is unset and user_mode is set
<stgraber> jodh: that'll essentially test the code I added to initctl.c, the rest is identical to standard upstart, so I'm not sure it makes sense to add a specific test to each of the test function
<jodh> stgraber: sounds good to me.
<stgraber> looks like it's going to be one of those rare branches where adding tests will take less time than writing the initial code ;) that's assuming I don't get into any weird nih bug when writing the tests ;)
<xnox> well.... how long have you already spent sieving through test_initctl.c?
<xnox> =))))
<stgraber> xnox: just long enough to notice vim telling me how long it was ;) then I decided to use grep to figure out where to add my tests ;)
<stgraber> anyway, half the tests are done now
<xnox> stgraber: i remember onces doing a grep -C 10 & using patch-mode to write a patch and path it in......
<xnox> good old days of not enough ram and patching 10MB file =)))))
 * xnox used to do crazy stuff, for little reason.
<stgraber> ;)
 * xnox doesn't like
<xnox> precise-desktop-base login: <4>init: setvtrgb main process (258) terminated with status 1
<xnox> upon starting lxc containers on raring.
<stgraber> xnox: I agree and I had an action to add some "and not-container" to those upstart jobs but slangasek felt we should just let them fail ;)
<xnox> stgraber: why does it complaint in my face and not somewhere else?
<xnox> =)
<stgraber> xnox: because it'd complain in your face on a real system, so we do that too in containers ;)
<stgraber> or more likely, it'd do that on a real system if /dev/console didn't support those ioctls and your machine was booting fast enough to cause a race between setvtrgb and tty1 :)
<stgraber> jodh: branch should be ready for another review. I added the two tests I mentioned earlier and they pass as expected.
#upstart 2013-01-23
<rdn> Any idea why a working job would turn into "start: Unknown job: " after system restart? I've tried reload-configuration and the job file does end in .conf
<rdn> Nevermind; there was an error introduced that check-config didn't mention
<xnox> jodh: so both me and stgraber were merging from trunk. hence now it's a big criss-cross merge.... *sigh* =)
<xnox> jodh: synced up now. should merge without conflicts now.
<jodh> xnox: thanks!
<xnox> stgraber: error is good, and the fact that it carries on running is also great.
<xnox> we are really in a non-standard situation if there is no HOME and no XDG_RUNTIME_DIR.
<stgraber> yep
<methods> can i use upstart to simply make sure a service keeps running that only uses /etc/init.d script ?
<methods> a package i install only uses /etc/init.d but i'd like upstart or something similar to make sure it's always running
#upstart 2013-01-24
<eloist> Hello
<eloist> I have trouble with an upstart script (on ubuntu 12.04lts) that I've been banging my head against and can't seem to figure out
<eloist> all I am trying to do is have a script export some env vars before running the actual process, for this i have the following in the script block: ". /root/env.sh"
<eloist> trying to start the service, I get the following in my log file: /proc/self/fd/9: 4: .: Can't open /root/env.sh
<eloist> file is definitely there though and the permission seem to be right :(
<eloist> i believe I found the reason and it's perforce changing the line feeds to windows line feeds
<munderwo-work> Hi all. I have a process that is being handled by upstart. I've got it handling SIGTERM signals, and I understand that this is what upstart emits when doing a stop <service>.the problem is that upstart doesnt seem to be waiting for my process to handle the signal and shutdown gracefully. Is there an extra timeout that I need to give upstart to make it wait longer?
<munderwo-work> AM I misunderstanding what SIGTERM is supposed to do?
<jodh> munderwo-work: upstart will indeed send SIGTERM by default (you can change that using the 'kill signal' stanza). It will then wait for up to 5 seconds by default for the job to end. If it doesn't end, upstart will send SIGKILL. If your job needs longer, specify 'kill timeout'. See init(5) for details of both kill options.
<SpamapS> jodh: well, good morning. Been watching the commits to upstart. Lots of weird new stuff .. still no fix for "my pid is stuck"
<SpamapS> doh
<mangoman> Hello, Upstart noob here. I created a new job but when I try to run it I get "Unknown job".  When I run `initctl list` it doesn't show up there, but it does show up in the /etc/init/ folder.
<mangoman> How can I get it to recognize it? Using this script: http://wiki.nginx.org/Upstart
<xnox> mangoman: try $ sudo initctl start nginx
<mangoman> xnox: still "unknown job"
<xnox> mangoman: $ initctl check-config nginx
<afournier> hi there !
<xnox> mangoman: $ initctl status nginx
<xnox> if that all fails, try $ initctl reload-configuration
<afournier> is it possible to start a task at the end, ie. the login prompt ? 
<afournier> i know the question is a bit stupid as upstart is based on events
<afournier> but it's not like the prompt login has too much depencies, at the same time when it spawns, upstart is still starting other task, and the prompt is hidden by the output
<mangoman> xnox: thank you
<afournier> maybe the best solution would be to turn upstart silent, so only the prompt appears, and other tasks can continue to be started, what do you think ?
<xnox> afournier: what do you want to achieve?
<xnox> afournier: during boot plymouth usually owns the consolse so one should talk to plymouth to display/ask user questions.
<afournier> i just want a clean terminal when the machine is starting :)
<afournier> plymouth ?
<afournier> i dont have plymouth
<xnox> =/ then i think your machine is broken horibbly.
<afournier> it's a headless device with a serial for interface
<xnox> i think you do have plymouth, and maybe not know about it.
<xnox> yeah, that's fine.
<afournier> is plymouth embedded in upstart ?
<xnox> no.
<xnox> no, that would be silly.
<afournier> then my distro is broken...
<xnox> afournier: i guess you should configure upstart to log to files only and not to the console / output.
<xnox> afournier: see cookbook linked from the topic.
<afournier> xnox: i'll do that, but i am not gonna add plymouth :)
<xnox> afournier: =) sure, do what you like ;-)
<afournier> until my distro is not horibbly broken :)
<xnox> I'm not entirely happy with upstart-udev-bridge =/
 * xnox hoped for some better way to encode matching variables
<xnox> hmm... i must "exit 0" from pre-start script?
<xnox> jodh: in the usb-creator branch, there is a scary upstart job for you to review =))))
<xnox> it's a poor-man's user session job.
<JanC> afournier: you don't need plymouth to use upstart, but it might still be interesting to look at Ubuntu's default upstart job configs to see how it handles that sort of things
<JanC> (oh, and plymouth can do text-mode boot, it's not necessarily graphical...)
#upstart 2013-01-25
<mangoman> Howdy again. So I changed the location of my pidfile in my jobfile, but whenever I try to run it , it's still trying to write to the old location, as though upstart hasn't recognized that the file has changed. What up with that?
<mangoman> nevermind, I'm an idiot
<xnox> mangoman: I don't think you are an idiot. We are glad to provide forum for you to think out loud and come up with a solution! =))))
<munderwo-work> Hi all. I have a process that is being handled by upstart. I've got it handling SIGTERM signals, and I understand that this is what upstart emits when doing a stop <service>.the problem is that upstart doesnt seem to be waiting for my process to handle the signal and shutdown gracefully. Is there an extra timeout that I need to give upstart to make it wait longer?
<munderwo-work> or am I misunderstanding what SIGTERM is supposed to do?
<mangoman> So now my job is hanging whenever I try to interact with it
<mangoman> when I start it, It doesn't say anything, jsut gives me a blank line and I have to ctrl+C it
<mangoman> but apparently it's not actually stopped, so I do `stop job` and it also hangs in the same way
<mangoman> if I use `initctl` on it before i stop it, that also hangs
<mangoman> and the script is fine because if I copy the exact script to a different name and run that, it works perfectly
<mangoman> is there a cache of some sort that I can clear out?
<mangoman> also when it does that hanging stuff it doesn't record anything to the upstart log
<xnox> stgraber: i think jodh is deep in coding =))))
<stgraber> jibel: :)
<stgraber> oops, just meant ":)"
<jodh> stgraber/xnox: indeed - apologies - only just finished.
#upstart 2014-01-21
<shadeslayer> hi, I'm on Kubuntu and I don't seem to have a com.ubuntu.Upstart interface on the session bus
<shadeslayer> it does sometimes appear, but currently doesn't seem to be there
<shadeslayer> any ideas?
<jodh> shadeslayer: yes - that is bug 1258098 - I've fixed the bug. Just needs to be reviewed by an Upstart developer such that we can get it into the next release (this/next week I'm hoping).
<shadeslayer> aha cool, I just wanted to be informed since I landed a patch in kde-workspace that allows suspending via the logind interfaces provided by com.ubuntu.Upstart a few weeks back
<shadeslayer> and I started noticing lately that my laptop did not suspend since there was no com.ubuntu.Upstart
<jodh> shadeslayer: oh - are you talking about the system bus?
<shadeslayer> jodh: no, session bus
<jodh> shadeslayer: right, that bug is the reason then :) fwiw until recently, the Session Init didn't connect to the Session Bus at all since it has a private socket anyway.
<shadeslayer> huh,weird, I did have a com.ubuntu.Upstart interface at some point and it did work :)
<shadeslayer> tested it quite a bit
<shadeslayer> ah well, /me will wait for fix to land
<jodh> shadeslayer: it works as expected until the Session Init is restarted. This happens automatically on Ubuntu if the upstart package gets upgraded (or any of its dependencies; libc, libnih, etc).
<shadeslayer> ahhh
<jodh> shadeslayer: there is a work-around: run "initctl notify-dbus-address $DBUS_SESSION_BUS_ADDRESS" as required and the Session Init will reconnect to the Session Bus.
<shadeslayer> thx, that does work
#upstart 2014-01-24
<cks_> Hi, I am facing some problem in starting a job automatically by upstart. However if I run "start myjob", it gets started without any errors. Any pointers to debug is appreciated 
<xnox> cks_: maybe your "start on" condition is not correct.
<xnox> cks_: you can use upstart-monitor to see which events are emitted.
<xnox> cks_: can you paste your job to e.g. paste.ubuntu.com ?
<cks_> xnox: I pasted my script here: http://paste.ubuntu.com/6808440/
<cks_> xnox: I am using upstart 0.3.11
<cks_> as shown in the script. pulseaudio depends on audiod.   audiod is up and running. I verified with   initctl status audiod
<xnox> cks_: your job appears to be correct, but I have no knoweledge / experience of upstart 0.3.11 however.
<xnox> maybe jodh can help you with this ^
<cks_> xnox: ok
<jodh> cks_: presumably you are running some sort of custom distro? I'd definitely recommend upgrading the upstart package if so as we've added lots of features to make debugging easier.
<jodh> cks_: golden rule job writing new jobs is to *not* specify respawn until you are sure it is doing what you want: http://upstart.ubuntu.com/cookbook/#respawn
<jodh> cks_: also, http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job, http://upstart.ubuntu.com/cookbook/#determining-why-your-service-fails-to-start.
<jodh> cks_: at a guess I wonder if when audiod starts, pulseaudio cannot start as /run is not mounted? Take a look at /etc/init/pulseaudio.conf on a modern ubuntu system to see how it works with current versions of pulse and upstart.
<cks_> jodh: but when I run manually "start pulseaudio" it starts without problem. thanks for the links. 
<jodh> cks_: then, there must be an error in the 'start on' - are you sure your other job is called /etc/init/audiod.conf and that that daemon is actually running with the expected pid?
<cks_> Actually audiod upstart script is present in /etc/event.d/
<cks_> even pulseaudio script lies at the same place
<jodh> cks_: wow, use of that directory is before my time :)
<xnox> jodh: i wonder if that upstart already was using "start on started $job" syntax =)
<xnox> cks_: what's the start on condition of the audiod? maybe copy that into pulseaudio or some such?
<jodh> yes, maybe back then it was "starte I sayeth forsooth ..."
<jodh> cks_: try booting with --debug and capturing syslog/dmesg which will show the event flows.
<xnox> jodh: =)))))))
<cks_> jodh: thanks for the input
<SpamapS> you know.. one unfortunate thing about console log is that programs think they're talking to a tty and thus print with cr's instead of just newlines
#upstart 2014-01-26
<mgorbach> I'm looking to set up upstart to automatically start up tmux sessions as my personal user, either on boot or on the first time my user logs in
<mgorbach> I'm on Ubuntu 12.04, can anyone point me to the best way to do that? Looks like I don't get Upstart session jobs because the version of Upstart in 12.04 is too old
#upstart 2015-01-19
<jollygood> In the cookbook I didn't see anything about analyzing boot with upstart (which I want to do)
<sveinse> Any activity here?
#upstart 2015-01-22
<pluesch0r> hi everybody. running ubuntu 14.04 and stuck with a process in start/killed state. how do i clean this up?
<pluesch0r> freeradius start/killed, process 2780
<pluesch0r> i found the workaroung_upstart_snafu script, but that seems to only work for stop/killed state. this is horrible.
<xjunior> Hi
<xjunior> I'm having an issue with upstart
<xjunior> https://gist.github.com/xjunior/765ff75ff8af4391498c
<xjunior> it starts and monitors a PID, but then the actual process is running a different PID!
#upstart 2015-01-23
<wedgwood> Hi. I'm having some trouble with a watchdog job
<wedgwood> http://pastebin.ubuntu.com/9840354/
<wedgwood> I'm expecting the watchdog to see RESULT=failed, but result is ok and none of the other variables are set
<wedgwood> I'm on 1.12.1, fwiw, but I didn't see anything in the release notes that made me think those variables were new
<wedgwood> Also tried without JOB= but no change
#upstart 2016-01-27
<davux> hi!
<davux> I'm trying to detect (and react) when a job respawns, so I'm following http://upstart.ubuntu.com/cookbook/#detect-if-a-job-stopped-before-reaching-its-respawn-limit
<davux> but it's not working. The action is executed when I remove the "respawn" stanza
<davux> I'm doing this in the "watchdog" job: start on stopped RESULT=failed, then echo "job '$JOB' just failed" >> /tmp/failures.log (inside a script block)
<davux> and that's litterally it. With no respawn in the target job, the watchdog works, however with a respawn I don't get anything in /tmp/failures.log
<davux> I don't understand. I can't find a way to detect that a job failed if it has a respawn stanza
<davux> is there a way to get upstart-monitor along with upstart 1.5?
<davux> I'm on Ubuntu 12.04 LTS and there's no upstart-monitor package :(
#upstart 2016-01-29
<JamEngulfer221> If I have an upstart script and I run exec, does that block the rest of the script from executing until said process is finished?
<JamEngulfer221> Likewise, if I call a script with exec in it from another script, will the parent script have execution blocked in the same way?
<supergonkas> hey anyone around?
#upstart 2016-01-31
<ikonia> long shot question, but using upstart on centos 6, upstart version 0.6.5 I'm trying to debug a failing job, however I'm struggling to get any error output on it, and I can't use initctl check-conf as it doens't appear to exist in 0.6.5
<ikonia> I've changed upstarts log-priority to debug, and can see that the job is starting, and stopping straight away
<ikonia> getting any output as to why is proving challanging
<ikonia> the cookbook refernces tools/options that are not available in the centos shipped 0.6.5 version, so I'd welcome any suggestions or input as how to work and debug that versions jobs
#upstart 2017-01-26
<FonzPonza> hi
<FonzPonza> anyone know how to set vm.max_map_count from upstart script ?
#upstart 2018-01-23
<via> is there any way to handle a service that can change its PID when it reloads? e.g. the master forks and kills the old master
