text: #upstart 2007-01-15
  <Stev2> Hello, I have a question about starting many daemons in parallel. On my system, i start httpd,smbd,nmbd,httpd,cupsd,avahid,distccd and some others all at once at boot time. Occasionaly one or more of them fail to start, and in the logs then there are errors saying could not bind to 127.0.0.1:631 permission denied, or setgid(99) failed, permission denied. Anyone experience this?
  <Md> a randomly failing setgid is a bad, bad thing
  <Md> and the other problem looks related
  <Md> you need to understand why these daemons are being started with the wrong UID when they expect to be started by root
  <Stev2> I don't know how they could not be started by root, they are spawned from upstart, unless i am missing something.
  #upstart 2007-01-17
  * Starting logfile irclogs/upstart.log
  <AlexExtreme> great
  <AlexExtreme> the linux.conf.au website has a video of Scott's upstart talk
  <_ion> Cool, thanks for pointing that out. And since you didn't feel like giving the URL, http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/102.ogg :-)
  <AlexExtreme> heh ;)
  <tiolpxe-> hi can someone please tell me how i can change my runlevel from 5 to 3 using upstream i cant see anything on it
  <AlexExtreme> upstream?
  <tiolpxe-> lol i dont know why i said that
  <tiolpxe-> lol
  <AlexExtreme> ;)
  <AlexExtreme> well
  <AlexExtreme> upstart doesn't use runlevels
  <tiolpxe-> so ive noticed
  <tiolpxe-> so am i correct in thinking a telinit 3 will allow me to boot to the cli
  <AlexExtreme> no
  <tiolpxe-> is it possible to boot to the cli then?
  <tiolpxe-> ive read the net with no diffinitive anwers
  <AlexExtreme> not sure, I don't use ubuntu
  <tiolpxe-> well ubuntu uses upstart and surely that determines whether it can
  <AlexExtreme> I don't know, I don't use ubuntu, as I just said
  <AlexExtreme> gonna disappear for a bit
  <tiolpxe-> surely this is ubuntu irrelevant
  <tiolpxe-> im asking an upstart question
  <_ion> I was just writing an answer.
  <AlexExtreme> heh
  <AlexExtreme> I hate it when people don't hang around for an answer... like, they expect an answer to be typed instantaneously :p
  <AlexExtreme> hah
  <AlexExtreme> I'm watching the upstart talk, there's a bit where scott's saying what computers were like in the past, starting from 30 years ago. the machine that's pictured for 10 years ago is the exact machine that's my router ;)
  <_ion> :-)
  #upstart 2007-01-18
  * ..[topic/#upstart:Keybuk] : Upstart 0.3.1 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | http://www.netsplit.com/blog/articles/2006/12/14/upstart-0-3 | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://lca2007.linux.org.au/talk/102
  <Keybuk> oops, battery went flat there :p
  <_ion> heh
  <Keybuk> video of my talk in the /topic now
  * Keybuk is reading the dbus test suite source
  <Keybuk> davidz was telling me about a neat malloc-fail checker they have
  <Keybuk> it detects which mallocs were run, and then re-runs the tests each time causing them to fail
  <Keybuk> though I'm trying to work out why it has a copy of gcov in it
  #upstart 2007-01-19
  <Keybuk> it's kinda nice to hear Fedora developers use phrases like "upstart should solve this"
  <_ion> Hehe
  <_ion> Promising
  <_ion> md: Your quit message is too long. The IRC server truncates it at a byte that isn't at a character boundary, so the message looks like "..." in clients that assume the line to be encoded in e.g. CP1252 if it's not valid UTF-8.
  <Md> interesting, it used to work...
  <Md> _ion: looks like vim corrupted my quotes file, I need to recover it from backups
  <_ion> md: Corrupted?
  #upstart 2007-01-20
  <mbiebl> AlexExtreme: how's your work with upstart on frugalware progressing?
  <mbiebl> Have you already started converting the legacy initscripts to upstart jobs?
  <AlexExtreme> Not yet, I'm waiting for scott to get some more of the planned features implemented
  <mbiebl> Do you already use upstart for frugalware (in compat mode)?
  <AlexExtreme> mbiebl, well, it's not in the official repos, but I have been using it with compat mode on my computer
  <AlexExtreme> brb, breakfast
  <AlexExtreme> back
  #upstart 2008-01-14
   * Keybuk tries to come up with a funny word for a roadmap update
  <Keybuk> oh, obviously -- "Upstart 0.5 Are We There Yet?"
  <kylem> "no"
  <kylem> :P
  <Keybuk> quest upstart% bzr diff -r tag:0.3.8.. | diffstat | tail -1
  <Keybuk>  63 files changed, 20985 insertions(+), 22843 deletions(-)
  <Keybuk> which amounts to 120% of the code changed
  <AlexExtreme> wow.
  <Keybuk> AlexExtreme, ion_: btw, could you both unsubscribe from https://code.edge.launchpad.net/~keybuk/libnih/old-main
  <Keybuk> and probably subscribe to https://code.launchpad.net/~keybuk/libnih/trunk instead
  <Keybuk> :)
  <kylem> Keybuk, oh, you should fix the urls in the README of both of those btw
  <Keybuk> kylem: good catch ;)
  #upstart 2008-01-15
  <ion_> keybuk: Allright. I was already following the new branches, but hadnât remembered to change the subscription at LP.
  <Keybuk> AlexExtreme: there?
  <AlexExtreme> I an
  <AlexExtreme> *am
  <Keybuk> could you unsubscribe from https://code.edge.launchpad.net/~keybuk/libnih/old-main
  <Keybuk> and probably subscribe to https://code.launchpad.net/~keybuk/libnih/trunk instead
  <AlexExtreme> ah, sure
  <Keybuk> (then I can delete it -- that branch is the old auto-mirror, trunk is hosted there natively)
  <AlexExtreme> done
  <Keybuk> init: Failed to spawn test (#0) main process: unable to execute: No such file or directory
  <Keybuk> \o/
  <Keybuk> http://rafb.net/p/rE7u6L89.html <- full output in context
  #upstart 2008-01-16
   * Keybuk contemplates job environment
  <Keybuk> musing:
  <Keybuk> - have environment as a list in Job
  <Keybuk> - have a list of blocking events in Job
  <Keybuk> - when started by events, copy into blocking list and append event environment into Job
  <Keybuk> - when stopped by events, copy into blocking list
  <Keybuk> - when started by hand, append start environment into Job
  <Keybuk> - drop start_on/stop_on in job
  <Keybuk> - clear entire blocking list when running or when waiting
  <Keybuk> - check we don't clear stop_on but leave start_on at any point?
  <Keybuk> ... can't copy stopped events into blocking list
  <Keybuk> and don't want to clear the list while job is runnin
  <Keybuk> random thought
  <Keybuk> if a job is started manually, should its stop events still apply? :)
  <ion_> Too tired to get synapses to fire.
  <Keybuk> heh
  #upstart 2008-01-19
  <msipos_> hello, anyone here to answer a few newbie upstart questions? :)
  <msipos_> well, ok, I just posted the question here: https://answers.launchpad.net/upstart/+question/22513
  <msipos_> so, would be nice if you looked at it :)
  #upstart 2008-01-20
  <MarcWeber> Is there some kind of short reference to look up the syntax?
  <MarcWeber> Is there an example samba upstart script somewhere?
  #upstart 2009-01-12
  <sadmac2_> Keybuk: interesting
  <Keybuk> sadmac2: when you're just doing WEXITED, it's fine
  <Keybuk> but as soon as you add in things like WSTOPPED | WCONTINUED, the wait queue can change under you
  <Keybuk> (something previously queued for WCONTINUED can change to WSTOPPED or WEXITED under you)
  <sadmac2> true story
  <Keybuk> (anything can change to WEXITED, etc.)
  <keesj> wouldn't upstart benefit from a second thread to qeue this stuff?
  <Keybuk> keesj: ?
  <keesj> sorry I must have misred. I was thinking there was a problem waiting for a child because of a broken system call
  <Keybuk> well
  <Keybuk> the syscall provides a flag that is about as helpful as a chocolate teapot
  <Keybuk> but it didn't break anything, because I was just using the flag to be clever
  <sadmac2> Keybuk: chocolate teapots are delicious
  <sadmac2> I fill mine with CRACK
  <TML> Where would I find upstart's equivalent of /etc/inittab?
  <TML> Or am I perhaps barking up the wrong tree? Trying to help a friend who is on Ibex, without understanding how it works. We want to add a tty listening on the serial port for connecting a laptop to, so the box can run entirely "headless".
  <sadmac2> TML: /etc/event.d
  <sadmac2> TML: but you'll probably need more than that
   * sadmac2 isn't sure what manpages ubuntu ships for the jobfiles
  <Keybuk> the default ones ;)
  <sadmac2> heh
  #upstart 2009-01-13
  <keesj> hmm I make some progress in the bug I am hunting. I an now reproduces it
  <keesj> I have 3 jobs files (2 service and one "state" ) http://www.paste-it.net/raw/public/g3fbeff/ called test_state_exportfs test_service_exportfs and test_service_userfs
  <keesj> the exportfs "service" gets stated before the stop of the userfs
  <keesj> when I run a start test_state_exportfs
  <keesj> this is because my userfs is defined to stop on test_state_exportfs AND stop on test_service_exportfs
  <keesj> when I issue a start test_state_exportfs the "userfs" is going in a stopping state and upstart does not wait for it to be stopped before it starts the exportfs service
  <keesj> http://www.paste-it.net/public/ve5305c/ shows that (ouput of initctl events) you see that topped test_service_userfs ok
  <keesj> is printed after started test_service_exportfs
  <Keybuk> keesj: I'll look presently
  <keesj> Do you understand what I am trying to explain?
  <keesj> it looks like because the "state" service already puts the userfs service in a "stopping mode" that a check upon start of the exportfs service it does not wait for the userfs service because that one is not "running"
  <Keybuk> I haven't read it yet
  <Keybuk> ok
  <Keybuk> reading now
  <Keybuk> test_service_exportfs - this will start before test_state_exportfs
  <Keybuk> test_service_userfs - this will stop before either test_state_exportfs or test_service_exportfs
  <Keybuk> you run
  <Keybuk> start test_state_exportfs
  <Keybuk> I would expect to see test_service_exportfs starting->running followed by test_state_exportfs starting->running
  <Keybuk> that appears to me to be what your events output shows?
  <Keybuk> http://rafb.net/p/HxXtYN53.html
  <Keybuk> WFM
  <Keybuk> I started test_service_userfs
  <Keybuk> then started test_state_exportfs
  <Keybuk> that stopped userfs, started service_exportfs, and then concluded starting state_exportfs
  <notting> sadmac2: built it for f9/f10. didn't add anything in bodhi for it
  <sadmac2> notting: ok
  <notting> sadmac2: there's a -21 because i didn't add a changelog the first time
  <sadmac2> notting: yeah, I forgot that bit :)
  <sadmac2> notting: If you want to test em a bit you can. Other than "does telinit u cause explosions" theres nothing to look for
  <Keybuk> keesj: I think you're just getting confused because you're looking at the order of resulting evefnts
  <Keybuk> keesj: upstart tends to focus on one service at a time, so it's not unusual to see events in what might appear to be out-of-order
  <Keybuk> keesj: use initctl jobs for debugging instead
  <plundra> I know there is inictl restart in 0.5, but is there a 'restart' aswell? Just as 'start' etc. that is.
  <plundra> In that case, can you 'restart job1 job2 job3' (just as you can start multiple ones)
  <plundra> If so, that's fucking awesome :-] Man I hate Ubuntu 8.04 uses 0.3.9
  <Keybuk> plundra: there is if you make a symlink to it
  <Keybuk> it was added sufficiently late that the symlink isn't there by default, but it probably should be
  <keesj> re
  <keesj> Keybuk it really happens that the userfs service is not stopped(still stopping) while the export service is started
  <keesj> in you paste line 12 the export service is starting and line 13 only hte userfs is stopped
  <keesj> and only in line 19 the service is stopped 
  <keesj> while at that point the service exportfs clearly looks like running
  <keesj> I will have more time tomotow , I will test on 0.5
  <Keybuk> keesj: I don't understand what you're trying to tell me
  <Keybuk> in my paste, I start test_state_exportfs
  <Keybuk> it *clearly* waits for test_service_userfs to stop *and* for test_service_exportfs to start
  <keesj> indeed but not for userfs to stop before is starts exportfs
  <Keybuk> yes, it clearly does
  <Keybuk> line 19, test_service_userfs (stop) waiting
  <Keybuk> userfs has fully stopped
  <Keybuk> line 20, test_state_exportfs (start) pre-start, process 10490
  <Keybuk> exportfs actually begins to start
  <Keybuk> this is working as intended
  <Keybuk> how are you expecting it to work?
  <keesj> I expect service_userfs to be fully stopped before service_exportfs starts
  <Keybuk> that's exactly what's happening
  <Keybuk> I don't understand your confusion
  <Keybuk> line 19, service_userfs is *fully* stopped
  <Keybuk> line 20, state_exportfs starts
  <Keybuk> there's nothing in your job to cause service_userfs to wait on service_exportfs?
  <Keybuk> the "stop on starting test_state_exportfs" is the key one
  <Keybuk> ah
  <Keybuk> do you think that having two "stop on" means "and" ?
  <Keybuk> (it doesn't - it means or)
  <Keybuk> you would need to use 0.5 for the behaviour you want
  <Keybuk> *and* your clause is wrong anyway if you want service_exportfs fully started
  <Keybuk> stop on starting test_state_exportfs and started test_service_exportfs
  <keesj> what I want is that when i start state_exportfs is  FIRST userfs gets fully stopped and after that only the service_exportfs get started starts. 
  <keesj> that is why i added the second stop on starting exportfs
  <Keybuk> then service_exportfs needs "stopped userfs"
  <keesj> right
  <Keybuk> start on starting test_state_exportfs and stopped test_service_userfs
  <Keybuk> 0.5 only
  <keesj> but 0.5 can only have one start line right?
  <Keybuk> right
  <sadmac2> Keybuk: I am about to head out, but have you looked at my crude little state machine lately?
  <sadmac2> is the implementation helping any?
  <Keybuk> sadmac2: no, haven't looked at all
  <sadmac2> (I'm going to write a manpage/user document after I get a little more into it)
  <sadmac2> ah
  <sadmac2> well there's enough there now to be worthwhile
  <Keybuk> keesj: only 0.5 has "and" behaviour
  <Keybuk> in 0.3 everything is "or"
  <Keybuk> and "or" doesn't give you what you want
  <keesj> well or is fine for me but apparently at the moment upstart starts the service_userfs it does not stop service_userfs. because (and I am guessing) the service_userfs is in "not started" mode.
  <keesj> off to bed now
  <Keybuk> no
  <Keybuk> nothing to do with that
  <Keybuk> it doesn't wait because nothing tells it to
  <Keybuk> you don't have any instruction for upstart to wait
  <Keybuk> it won't wait because you haven't told it to
  <Keybuk> it doesn't know what you're thinking ;)
  <plundra> Keybuk: Ok, sweet :-)
  <plundra> Too bad not even the upcoming Ubuntu 9.04 or Debian experimental has 0.5 yet (!)
  <Keybuk> plundra: I'm not particularly planning to put 0.5 into Ubuntu
  <plundra> Keybuk: Bleh, why not? :-)
  <plundra> restart would pretty nifty
  <plundra> And from what I read in the changes, loads of other stuff were redone etc.
  <Keybuk> the userspace was never really finished
  <Keybuk> and 0.5 has various other problems
  <Keybuk> none of its new features help Ubuntu
  <Keybuk> and I'd rather spend my effort working on 0.10
  <plundra> Ok, I see.
  <plundra> So what's planned for 0.10? :-D
  <Keybuk> lots
  <plundra> Mkay, rewrites again? (Lots of stuff was remade for 0.5, right?)
  <Keybuk> the main change is dropping "start on"/"stop on"
  <plundra> Oh, ok.
  #upstart 2009-01-14
  <sadmac2> Keybuk: "As mentioned in Chapter 3, every CPU of a multiprocessor system has its own /swapper/ process with PID equal to 0"
  <sadmac2> Understanding the Linux Kernel 3rd edition
  <sadmac2> so there /is/ a PID 0
  <Keybuk> I thought swapper went away long ago?
  <sadmac2> the book is current to 2.6.10, so it could be
  <sadmac2> Nov. 2005 publish date
  #upstart 2009-01-18
  <sergeykish> hello, is it a channel about http://upstart.ubuntu.com ?
  <sergeykish> see it :-)
  <sergeykish> I've created a python daemon and run it using upstart. It runs good - I can see it using `ps ax | grep name`, but `status name` shows (stop)
  <sergeykish> I run script using exec: $ cat /etc/event.d/tamagotchi 
  <sergeykish> exec /usr/local/sbin/tamagotchi.py
  <sadmac> sergeykish: does your python daemon fork?
  <sergeykish> sadmac, yes
  <sergeykish> it use standart daemonize method
  <sergeykish> sadmac, thanks - googled the `upstart daemon fork` and found decision https://bugs.launchpad.net/upstart/+bug/99962
  <sadmac> np
  #upstart 2010-01-19
  <tj___> hi.. a question about temporarily disabling services managed by upstart from starting.. let's say i'd like to disable some service for a reason or another but don't want to uninstall the package. in debian/ubuntu, with traditional init scripts, you could disable a service from starting on boot by running update-rc.d -f <service> remove
  <tj___> is there something similar for upstart or do i just need to remove the conf file under /etc/init ?
  <sadmac2> tj___: nothing similar as of yet
  <tj___> ok
  <tj___> i have an ltsp server setup with local apps. handy for trying out machines, testing motherboards etc. quickly without having local disks. by default it'll boot to desktop. but in the pxe menu i've setup an entry for a quick non-graphical boot with minimum services running. it passes a special command line option to kernel. then i have a custom boot script which is run very early in the boot process. it'll check for this boot argument and if exists, it'll remove g
  <tj___> this worked fine until karmic but now that more services are using upstart, i need to figure out another way to do that
  <tj___> i'd rather not just remove the conf file for the service as it would be handy if you could manually start any service after the boot if needed, only autostart on boot should be disabled
  <sadmac2> remove g?
  <tj___> g?
  <sadmac2> " it'll check for this boot argument and if exists, it'll remove g"
  <tj___> ah that was clipped
  <tj___> it'll remove gdm and other desktop related services using update-rc.d from the root fs which is unionfs-on-top-of-squashfs-mounted-over-nbd
  <sadmac2> tj___: you have some strange ways of operating
  <tj___> could be but it works^Hed :)
  <mbiebl> tj___: just comment out the "start on" in the upstart job files
  <keesj> HI
  <keesj> How or when does upstart connect to the dbus-daemon system bus?
  <keesj> is this something I can configure?
  <keesj> I am mainly interested in talking to upstart from a user accont and possibly using the dbus-daemon 's system configuration to configure who can access the upstart daemon
  <sadmac2> keesj: it used to connect when launched, which meant if you ran it before dbus (i.e. the way you'd always run it in a non-test environment) it would never connect. I think something was done about this but I'm not sure.
  <keesj> I would find it somewhat strange if upstart would not start the daemon itself and on my ubuntu machine. it starts dbus-daemon itself
  <keesj> but I think I found the trick..
  <keesj> post-start exec kill -USR1 1
  <sadmac2> keesj: exactly
  <keesj> in the dbus.conf will probably make upsart try again
  <sadmac2> sounds right
  <sadmac2> though I wonder why ubuntu doesn't have that already if it was put it.
  <sadmac2> *in
  <keesj> i ubuntu it is
  <keesj> http://paste-it.net/public/x881ffb/
  <keesj> it just lacks a comment why I did that :p
  <sadmac2> perfect then
  <keesj> thanks for helping
  <h_lfline_> notting: hey so i'm looking at your prefdm.conf / gdm.conf stuff
  <h_lfline_> woah i have underscores
  <sadmac2> h_lfline_: you're loosing vowels rapidly
  <h_lfline_> anyway, noticed a typo
  <h_lfline_> if [ -f /etc/init/$base.conf ]
  <h_lfline_> should probably be /etc/event.d/$base.conf
  <h_lfline_> but i wonder if that's the most "upstarty" way to do it
  <notting> /etc/init is the 0.6.x path
  <notting> /etc/event.d is the 0.3.x path
  <h_lfline_> ohhhhhh
  <h_lfline_> makes sense
  <sadmac2> h_lfline_: this should probably be in fedora-devel really. We've been coming down on the ubuntu questions pretty hard, so for fairness sake I should mention it.
  <notting> the problem is that if multiple DMs have installed jobs, you need to explicitly start one; you can't have them all start on a generic event
  <h_lfline_> but say you had a dm event
  <h_lfline_> with a DM variable
  <h_lfline_> then the only two competing would be the relevant dm and the fallback task
  <h_lfline_> sadmac2: oh i brought discussion here in case keybuk was around
  <h_lfline_> you guys probably know the internals of upstart  a lot better than i do though
  <sadmac2> h_lfline_: there is that. anyway its venturing into more generic upstart stuff anyway
  <h_lfline_> notting: so i wonder if we could have the fallback task sit back and wait
  <h_lfline_> and only chime in if the main event doesn't show up
  <notting> that sounds messy to code
  <h_lfline_> i'm looking at this state diagram that's in the upstart tree
  <h_lfline_> and it looks like things shoot to stopping if nothing is around 
  <h_lfline_> so maybe we could have a handler on stopping that checks if runlevel is still 5
  <h_lfline_> and if so starts fallback
  <h_lfline_> unless there's some upstart mechanism for "no one caught the event"
  <sadmac2> h_lfline_: Is this absolutely necessary?
  <h_lfline_> no absolutely not
  <h_lfline_> just trying to come up with the most upstart-y way of doing things
  <h_lfline_> if doing [ -f /etc/init/$base.conf ] && start $base is the right way to go
  <h_lfline_> then that's fine with me
  <notting> backing up, the idea we're trying to solve
  <notting> we pick a $foo to start
  <notting> we want to start a specific provided-by-$foo job if it exists; if not, start a generic job that starts $foo
  <notting> hence the logic abov
  <sadmac2> oh I see. hmm...
  <sadmac2> notting: the way I'd do it would be to have the fallback job check if the provided-by-$foo job has already started, and if so, terminate itself. Then the special foo job should start on starting generic-job
  <h_lfline_> so the question is, do we detect if a job doesn't exist by doing if [ ! -f /etc/init.d/$job.conf ] or is there some upstart hook to say "only call me if for this event if no one else takes it"
  <notting> sadmac2: that would mean the fallback would need to know all possible names of provided-by-$foo. sounds painful
  <h_lfline_> sadmac2: is there a way to ensure job ordering?
  <h_lfline_> ohhh start on starting is the way you keep order
  <sadmac2> notting: not really
  <notting> sadmac2: how do you know what to check for otherwise?
  <sadmac2> notting: what you would do is have all of the provided-by-$foo jobs start another job called dm-started DISPLAY=$whatever. That job would have no executable. Its a "state" if you will
  <sadmac2> notting: then you detect the presence of that (initctl list) to determine if the display manager is up
  <sadmac2> notting: thereby implementing a good chunk of upstart 1.0 in userspace in bash :)
  <h_lfline_> you mean "initctl status dm-started "
  <h_lfline_> ?
  <notting> sounds messy
  <sadmac2> notting: its one line in each of the generic jobs ( post-start start dm-started ) and really not much in the generic job
  <sadmac2> *one line in each of the specific jobs
  <notting> so you'd have specific job: 'start on start-dm DM=foo', and then 'post-start initctl emit started-dm'
  <notting> and the generic job has 'start on start-dm', 'stop on started-dm'. with a sleep thrown in?
  <h_lfline_> start on starting start-dm DM=foo
  <sadmac2> notting: the specific job would have start on starting generic-dm-job DM=foo
  <h_lfline_> i think sadmac was saying if you put the "starting" then you don't need a sleep
  <sadmac2> notting: the idea is we always just try to run the generic job, and then we just have the specific jobs jump in the way and say "wait!"
  <notting> 'bar: start on starting foo' implies bar must finish before foo starts?
  <sadmac2> notting: yes.
  <sadmac2> notting: when jobs emit events they wait for all the responders to finish responding before they continue. Its a very important part of how upstart works.
   * notting goes off to write the 'start on starting startup' job
  <sadmac2> notting: and actually you don't need the dm-started state. you could have the specific jobs just have "post-start stop generic-job"
  <sadmac2> notting: and then the generic job will never get past starting.
  <h_lfline_> oh that's a littler nicer
  <h_lfline_> so you have start on starting display-manager DM=gdm
  <sadmac2> notting: that has the advantage that the generic job can be written in a vacuum, with no knowledge that there is such a thing as a specific job or that it might run instead.
  <h_lfline_> psot-start stop display-manager
  <h_lfline_> hmm that doesn't sound right
  <h_lfline_> maybe it should be called display-manager-arbiter or something
  <sadmac2> h_lfline_: it doesn't but it is
  <sadmac2> h_lfline_: yeah, name it as you like
  <notting> sadmac2: although it does mean that the individual jobs need to know about the generic job
  <sadmac2> notting: indeed, but they'd have to know about some event or something that was going to kick them off anyway.
  <sadmac2> notting: so they don't need to know more than usual.
  <notting> sadmac2: not as written now, but as halfline says, it's a bit hackish
  <sadmac2> notting: I'm on my way home. I could stop by and look at what you have
  <notting> lemme bounce you the mail
  <sadmac2> by on my way home I mean about to grab my coat
  <notting> i have to head out in ~15 anyway
  <sadmac2> cool
  <h_lfline_> clearly it should be called "quest-to-find-a-display-manager"
  <h_lfline_> start on starting quest-to-find-a-display-manager
  <h_lfline_> post-start stop quest-to-find-a-display-manager
  <notting> h_lfline_: of course, this is ignoring the contortions where it figures out what it needs to start. ah, legacy installbases and config files
  <h_lfline_> yea i'm pretty sure there's not much we can do about those checks and heuristics
  <keesj> how about an all-display-manager-rise 
  #upstart 2010-01-20
   * ajb`` suspects what he's trying to do won't be possible with 0.3.9
  <sadmac2> ajb``: I don't entirely understand the question
  <ajb``> sadmac2: I want to use upstarts respawn directive to ensure the daemon is restarted if it crashes.
  <ajb``> sadmac2: However if I want the daemon to pick up defaults from /etc/defaults/daemonname I need to use a script to start it
  <ajb``> That doesn't seem to work, at least on 0.3.9 respawn can only deal with a direct exec as otherwise upstart looses track of the daemons pid
  <ion> script
  <ion>   . /etc/defaults/foo
  <ion>   exec program args
  <ion> end script
  <ion> Make sure program doesnât fork, thatâs all.
  <ajb``> I tried that, but it didn't seem to work
   * ajb`` tries again
  <ajb``> :-) it works now.. I must of had a subtly broken config before (probably experimenting with the daemon/fork directives)
  <ajb``> ion: thanks
  <ajb``> I'm guessing Hardy doesn't have any debhelper scripts for packaging things in /etc/event.d?
  <ion> It doesnât.
  <ajb``> Is there any support for spawning processes under another uid? Or is that behaviour expected to be handled by the daemons themselves?
  <sadmac2> ajb``: there isn't yet. Upstart is poised to grow some very elaborate permissions stuff, so Scott didn't want to offer you a "wrong way of doing things."
  <ajb``> Hmm, I shall have to solve the problem another way for now then....
  <ajb``> I'm guessing post-start scripts have no gaurentee the daemon has run? Can the wait?
  <ajb``> s/the/the post-start script/
  <sadmac2> ajb``: if the daemon fails then the post-start shouldn't run
  <mbiebl>  ajb``: I guess you just use su -c for now
  <ajb``> sadmac2: I want to be sure the daemon has created it's socket before tweaking it's permissions
  <sadmac2> ajb``: that makes no sense from a security standpoint
  <sadmac2> ajb``: you want to make sure the daemon has an opportunity to do things before you worry about it doing bad things?
  <ajb``> sadmac2: least bad option, I can't do su -c ${DAEMON} as that confuses upstart's process tracking
  <ajb``> as forks will have happened
  <ajb``> So option 2, allow the daemon to run as root but tweak it's comms socket to be group writable to the the things that need to talk to it
  <sadmac2> ajb``: su is not /supposed/ to fork I think. haven't figured out why it does
  <sadmac2> ion: where is scott these days?
  <ajb``> sadmac2: doesn't su always imply a shell getting invoked at some point?
  <ajb``> http://pastebin.com/m74d9c60e
  <ion> sadmac: He had a vacation last week, but heâs been active in Launchpad this week. Dunno why heâs not here.
  <ajb``> Short of patching the daemon (rrdcached btw) to be a suid binary I think a chgrp/chmod of the socket is the easiest way for now
  <ajb``> When we move our product to the next LTS (assuming upstart has the new permission stuff) I can look at making it neater
  <ajb``> Anyway thanks for the help, have to head off now
  <mbiebl> ion, sadmac2: I think Scott's at LCA
  <mbiebl> http://www.lca2010.org.nz/programme/schedule/monday
  <ion> Ah
  <sadmac2> mbiebl: that'd do it
  #upstart 2010-01-21
  <wt> Anyone here know how to run the tests in the upstart sources?
  <wt> make test didn't work
  <ion> make check IIRC
  <wt> indeed...thanks
  <wt> is there any way to disable dbus support?
  <ion> dbus-the-protocol or dbus-the-daemon?
  <ion> As for the former, *why*? As for the latter, just donât use dbus-the-daemon.
  #upstart 2010-01-22
  <mase_wk> hi ppl, is it possible to use upstart to run an application when a file has been modified ?
  <sadmac2> mase_wk: there's nothing built into upstart to do that
  <sadmac2> mase_wk: you could have somes sort of inotify daemon tell upstart to run things, but then you could also have it run them directly (depending on your application upstart man be the better choice)
  <SatanClaus> hey guys, once more I'm trying to update my old init-scripts. this time a script which automatically performs a backup. In the old system I started it in runlevel 0 via link: /etc/rc0.d/S15backup, so after all daemons stopped, but before the partitions are unmounted.
  <SatanClaus> is there some list of events, which are thrown during shutdown, so I know which event to bind my script to?
  <sadmac2> SatanClaus: that depends on your distro's setup. You should ask in #yourdistro
  <SatanClaus> ubuntu 9.10 again... is there some way to log all events cronologically into a file?
  <sadmac2> SatanClaus: you might make a job that just logs its triggering event to a file and make it "start on *"
  <sadmac2> ...I think that works
  <SatanClaus> yupp, thought about that, but 2 problems: 1: how do I assign the calling event (start on *) to a variable, which I could then log? 2: doesn't the start of my job then produce events itself (starting, etc.), which would cause an infinite loop?
  <sadmac2> SatanClaus: the infinite loop thing is... interesting
  <sadmac2> SatanClaus: the name of the event is put into the script environment for you
  <SatanClaus> can't find it in the docs again... how's that variable called then?
  <SatanClaus> $EVENT ??? ;)
  <sadmac2> I think its UPSTART_EVENTS
  <SatanClaus> events?
  <SatanClaus> so possibly even multiple?
  <sadmac2> SatanClaus: yes. thanks to the "and" operator your job can actually be triggered by two or more events
  <ion> Upstart doesnât really do shutdown in Ubuntu 9.10. The sysvrc scripts still handle it. My suggestion for the next-generation Upstart is that âsystem runningâ is a state, and anything that should happen just before shutting down should get triggered by the âsystem pre-stopâ event or equivalent, and the âsystem post-stopâ script would call reboot -f/halt -f.
  <SatanClaus> ah, true... cause I thought about that one as well... i first wanted to specify "ok, my backup shall be start on stopping mountall and stopping networking", but what if for any reason mountall needs to stop after networking is stopped. wouldn't that cause a lock?
  <sadmac2> SatanClaus: yes. The and operator is an ugly thing
  <sadmac2> SatanClaus: generally stay away from it.
  <SatanClaus> ion: yupp, such an event would be nice
  <SatanClaus> sadmac2: so upstart doesn't detect deadlocks?
  <sadmac2> SatanClaus: the theory behind upstart was that deadlocks would be impossible
  <SatanClaus> ok ;)
  <SatanClaus> thought i just presented a counter example
  <ion> The *implementation* is on its way to the goal. :-P
  <SatanClaus> ;)
  <SatanClaus> ok, cause an admin should be warned about such things...
  <sadmac2> SatanClaus: the and operator was... not implemented on one of Keybuk's good days.
  <SatanClaus> but for this you'd need a simulation run, etc.
  <ion> We can ditch the and operator in its current form as soon as we get real states into Upstart.
  <SatanClaus> ok, so as my backup currently runs I'll leave it like it is for now ;) nevertheless one thing: the output of the old sysinitv script is gone, can I get it back somehow?
  <SatanClaus> (i.e. the script writes output about its progress to stdout, which is gone since upstart)
  <sadmac2> SatanClaus: that's an Ubuntu issue
  <sadmac2> SatanClaus: and I think they may tell you NOTABUG when you ask
  <ion> exec >log 2>&1
  <SatanClaus> ion: uhm, where should I put that... currently i only have the old sysinitv link in /etc/rc0.d
  <SatanClaus> so there's no upstart .conf file
  <SatanClaus> at least not for the backup
  <sadmac2> SatanClaus: that goes in the top of your sysvrc, and "log" is the name of a logfile
  <sadmac2> SatanClaus: so he's telling you to go log the output
  <SatanClaus> uhm, but I want to see it...
  <SatanClaus> while shutting down
  <sadmac2> SatanClaus: I believe Ubuntu policy forbids making that easy
  <SatanClaus> anyhow, I know that tomcat is shown somehow, I'll investigate that ;)
  <SatanClaus> hmm, i think it's bad style not to tell the user what's going on... so if all old sysinitv scripts are muted by default... ugh
  <SatanClaus> hmm, i don't understand why other sysinitv scripts can show their output with echo on screen, while my script can't.
  <SatanClaus> there's no "console output" stanza in /etc/init/rc.conf
  <SatanClaus> and when I track back the log-calls in /etc/rc0.d/K08tomcat6 then I can find that it uses echo as well
  <SatanClaus> ok, via a function in /lib/lsb/init-functions, but I don't know how this could matter.
  <sadmac2> SatanClaus: maybe its piping to somewhere
  <SatanClaus> thought about that, but couldn't find anything
  <sadmac2> SatanClaus: use whatever tomcat's using
  <SatanClaus> i can't, i don't only want to see echo output but also rsync
  <sadmac2> hm
  #upstart 2010-01-23
  <SatanClaus> sadmac2: found the problem, have to write to /dev/console instead of stdout
  <SatanClaus> so a line of "exec > /dev/console 2>&1" would've been enough ;)
  #upstart 2011-01-17
  <djszapi> how about Keybuk ? :)
  <djszapi> where does upstart not print the process ID in few cases ?
  <djszapi> s/where/why/
  <djszapi> process id with exec lines and no process id with script lines ?
  <ion> It always tells the pid itâs tracking.
  <djszapi> what do you mean ion ?
  <djszapi> sysconfig-middle start/running
  <djszapi> gconfd start/running, process 438
  <djszapi> I have got lines like this, one of them with no PID.
  <ion> sysconfig-middle probably has no main process.
  <djszapi> how can that be ?
  <djszapi> some main process should be in any case, at least I thought that way :o
  <ion> Nope, itâs optional.
  <djszapi> I thought a tool is run from script section or with exec.
  <djszapi> and there is a main process in both cases.
  <ion> yes
  <djszapi> I am confused then :-S
  <djszapi> What other way is there ?
  <ion> script/exec is optional.
  <djszapi> is, but both have main process.
  <djszapi> My another issue is that when I try to enable the "--verbose" boot command-line option then I do not get this kind of messages (we discussed on Friday): Jan 14 14:52:49 deathspank init: tty6 main process (8557).
  <ion> sysconfig-middle doesnât seem to have a main process, judging from the fact that what you pasted from initctl status/list says so.
  <ion> Try initctl log-priority [PRIORITY]
  <djszapi> well, it should do the same like verbose.
  <djszapi> "initctl log-priority warn"
  <djszapi> but tried it out, did not help.
  <djszapi> I definitely think what was run from a script section that does not have PID as said in the beginning.
  <djszapi> but that is why they should have in warn, verbose mode a 'Jan 14 14:52:49 deathspank init: tty6 main process (8557)'-like entry which I do not have...
  <djszapi> so it should show the PID of the shell, ttyS6 oslt.
  <djszapi> for example: sysconfig-middle has a parent process and I would like to know that's PID.
  <djszapi> * obviously has
  <djszapi> any idea anybody, please ?
  <robs_> hi
  <robs_> I have a problem with upstart "stop" and "start" commands inside a 10.04 Vserver Guest
  <robs_> it seems it's the same problem outlined here
  <robs_>  http://www.freak-search.com/de/thread/2643371/vserver_problems_installing_ubuntu_10.10_as_a_guest_of_a_debian_host
  <robs_> I have the same problem (ie stop "service" or start "service" hangs), this is the debug I get from "stop dbus" inside a ubuntu 10.04 guest: http://pastebin.com/AjA2sAKG
  <JanC> robs_: issues with upstart inside a vserver are a known problem
  <robs_> JanC: following http://linux-vserver.org/Upstart_issues the machine boots and halts just fine
  <robs_> JanC: only "start" and "stop" hang
  <djszapi> I cannot believe I need to use audit or other kernellevel stuff directly to get the PID of the parent for a command that was run from the script field of upstart.
  <djszapi> it just seems a bit khm.. :)
  <djszapi> * upstart configuration file.
  <djszapi> no idea why it cannot be the part of upstart :(
  <JanC> djszapi: are you sure the main script is still running?
  <djszapi> how does that matter ?
  <djszapi> syslog entry should be done when it runs ?
  <JanC> and upstart is not 1.0 yet, some features are still on the TODO list  ;)
  <djszapi> I know but I have been told on Friday it is possible with verbose cli boot parameter
  <djszapi> and it seems that statement 1) was not true 2) I do somehing wrong
  <djszapi> JanC: do you have any idea ?
  <djszapi> Keybuk mentioned me on Friday: with verbose I should get like: Jan 14 14:52:49 deathspank init: tty6 main process (8557)  in syslog
  <djszapi> where tty6 is the 'sh' where the command was run from.
  <djszapi> from the upstart config file's script entry.
  <djszapi> btw, where is it the best to ask questions if this channel is not OK for that ?
  <JanC> djszapi: all the jobs I see with start/running and no PID are jobs that have no main exec/script, but only pre/post-start/stop
  <JanC> and this channel is fine for asking questions, alternatively you can try the mailing list
  <djszapi> well I did not still get any answer.
  <djszapi> from this morning.
  <djszapi> the question is still the same, how can I get the process id of the parent ?
  <djszapi> wherever it was run from, let it be pre/post-start/stop
  <JanC> are you sure it is still running?
  <djszapi> I need the pid when it was running.
  <djszapi> aegis-loader:191,sh:188,init:1 -> that is the call tree
  <djszapi> and I would like to get 188 back.
  <djszapi> aegis start/running
  <djszapi> aegis.conf run the aegis-loader in a post-start like way
  <djszapi> but I need to know the PID of the parent ('sh')
  <djszapi> do you understand ?
  <JanC> yes  âº
  <djszapi> define "yes  ?" :)
  <djszapi> otherwise I would say 'yes'.
  <JanC> what you apparently see as a "?" was a smiley
  <djszapi> pardon ?
  <JanC> yes, I understand what you want now
  <djszapi> do you know the answer how to do it ?
  <djszapi> verbose is supposed to do that.
  <djszapi> also initctl log-priority warn
  <djszapi> but none of them works :(
  <djszapi> JanC: feel free to help me, if you can :P
  <JanC> djszapi: I did some test, and for me it lists pre-start shell PIDs ?
  <JanC> djszapi: maybe you don't need 'warn' but 'info'?
  <JanC> warn should only show warnings & errors?
  <djszapi> JanC: verbose should work anyway.
  <djszapi> but I am trying with info
  <JanC> 'debug' will show even more, but 'info' should be enough
  <djszapi> does it work with 'warn' by you ?
  <djszapi> no pid with info either.
  <djszapi> JanC: http://pastebin.com/HVGiQHqz
  <djszapi> which is supposed to be the PID of the 'sh' line ?
  <djszapi> captrace lines are internal stuff, you can skip them, not that important tho.
  <JanC> http://pastebin.com/4CSGKYhm --> you can see the PID (13885) of the shell that executes the post-stop script (which only runs "sleep 10", hence it takes exactly 10 seconds to run)
  <JanC> that's with log-priority info
  <JanC> didn't test 'warn', but from the docs 'warn' shouldn't show this  ;)
  <JanC> "`warn' (ordinary messages are suppressed whilst still logging warnings and errors);"
  <JanC> does your dbus job have any pre/post-stop scripts?
  <djszapi> re
  <djszapi> JanC: I do not really understand why you keep repeating this pre/post-start/stop thingy
  <djszapi> it should return the PID of the parent in *any* case
  <JanC> djszapi: it seems like it currently doesn't log the PID of the shell indeed
  <JanC> in that case
  <djszapi> you mean in my pastebin, right ?
  <JanC> not only in your pastebin, also on my system
  <djszapi> that is a BUG
  <djszapi> Scott mentioned it should.
  <djszapi> JanC: what to do then ?
  #upstart 2011-01-18
  <hackeron> quick upstart question - when using exec, how do I execute a process as a different user?
  <ion> A future release of Upstart will have native support for that, but for now, e.g. something like exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parametersâ¦]
  <hackeron> ion: I see, I take it if I do that, then using chdir is kind of pointless in the service config file, right?
  <hackeron> and I created a new file /etc/init/xanview_backend.conf - how do I make it available as a service?
  <hackeron> ah, service --status-all didn't show it, but initctl list did :) - service won't start though, where does upstart log errors?
  <hackeron> I'm trying to do: 
  <hackeron> exec su -s /bin/bash -c 'cd /opt/xanview; exec "$0" "$@"' xanview -- python run_core.py >/tmp/logfile.txt 2>/tmp/logfile.txt
  <hackeron> when I run it just says initctl: Job failed to start
  <hackeron> same in syslog
  <hackeron> no log file is created :/
  <hackeron> any ideas?
  <hackeron> anyone here?
  <ion> Please pastebin the job definition. Also, using /bin/bash there is not the best idea, as it most likely loads much more slowly than whatever /bin/sh you have.
  <hackeron> I got it working, there was a command that failed to run on pre-start script -- now trying to make it start after postgresql
  <hackeron> if I manually do start xanview_backend - it starts
  <hackeron> if I restart postgresql it stops and starts
  <hackeron> but it won't start on boot :/
  <hackeron> I'm using this line: start on started postgresql until stopping postgresql
  <hackeron> and switching to sh, thanks
  <ion> init(5) doesnât say âuntilâ is a special word. That line means it starts on the âstarted postgresql until stopping postgresqlâ event which probably never comes.
  <ion> start on started postgresql
  <ion> stop on stopping postgresql
  <hackeron> thanks trying
  <hackeron> ion: no go :( - any ideas? < http://pastie.org/1472215
  <hackeron> ion: it all works fine and stops/starts with postgres if I do start xanview_frontend - but it won't start on boot :(
  <ion> postgres starts properly?
  <hackeron> hmm, actually status postgresql says unknown but  service --status-all shows  [ + ]  postgresql
  <ion> service concerns sysvinit scripts, not Upstart jobs. You donât seem to have a postgres job in your system.
  <hackeron> service shows my xanview_frontend running - so seems to have upstart jobs as well as sysvinit?
  <hackeron> but I'm guessing there is no such event as postgresql started
  <hackeron> any recommendations for an equivalent?
  <ion> A quick workaround would be adding âinitctl emit starting-postgresqlâ in /etc/init.d/postgresql-â¦ just before the service is started and âinitctl emit started-postgresqlâ just after, as well as âinitctl emit stopping-postgresqlâ and âinitctl emit stopped-postgresqlâ around where the service is being stopped. Then use âstart on starting-postgresqlâ and âstop on stopped-postgresqlâ in your job.
  <hackeron> ion: oooh, very nice, thanks for that
  <ion> Sorry, i mean âstart on started-postgresqlâ and âstop on stopping-postgresqlâ of course.
  <ion> You might want to do 'set -e; cd /opt/xanview; exec â¦' so that failure to change directory stops it from going forward. Or 'cd /opt/xanview && exec â¦', whichever you find nicer.
  <hackeron> added :)
  <hackeron> wow, that is really beautiful
  <hackeron> thanks for your help :)
  <ion> A future version of Upstart will transparently handle legacy sysvinit scripts, but thatâs still some time away.
  <hackeron> very nice, now I see just how much better it is compared to sysvinit :)
  <djszapi> ion: why is upstart used in so many projects if it is in childhood ?
  <djszapi> oops, not for ion only ovb.
  <djszapi> * obv
  <djszapi> How can I see pre-start exec $CSD pre-start like lines in upstart config jobs ?
  <djszapi> I was reading on the official website exec, processing should not occur in pre/post stuff, just preparetion + cleaning
  <ion> djszapi: Millions of Ubuntu users have been running it for years with success.
  <JanC> upstart has all the features it needs to emulate sysvinit, so it can replace that in projects without problems
  <JanC> then implementing more and more services as upstart jobs makes it clearer what is really needed
  <JanC> djszapi: what you try to do seems to be something new & unpredicted, and is exactly the reason why it's a good idea to use it before it's "finished"  ;)
  <djszapi> JanC: do idea what you mean
  <djszapi> upstart misses basic features
  <JanC> "basic features" that aren't in most other init systems anyway?
  <djszapi> your mean ?
  <JanC> considering tens of millions of people have been using upstart for 3 or 4 years now, and you are the first to complain about this particular feature, it can't be "basic"?
  <djszapi> to print out a pid is not a basic thing ?
  <djszapi> come on :)
  <JanC> which doesn't mean the complaint is invalid, just not "basic usage"
  <JanC> it prints a PID
  <JanC> just not the one you want  ;)
  <djszapi> rotfl :D
  <hackeron> djszapi: it also misses being able to start a process as a different user :) - it misses loads of vital basic little things, but it's still the best we've got :)
  <djszapi> not for me
  <djszapi> audit is bette for me right now
  <hackeron> link?
  <djszapi> sorry, but I am at home and I would like to focus for the KDE project :)
  <djszapi> let us speak about it during the daytime when I spend my time in the main job :P
  <hackeron> ok, for now, link please?
  <djszapi> http://google.com
  <hackeron> I tried, nothing
  <JanC> hackeron: he needs teh PID of the shell that starts the daemon instead of the PID of the daemon
  <djszapi> not true
  <djszapi> not instead of the daemon
  <JanC> well, in addition
  <djszapi> I just need that and that is all
  <djszapi> not a biggie.
  <hackeron> JanC: well, he said audit does it - I can't find this audit he's talking about :/
  <JanC> hackeron: AFAIK he means http://people.redhat.com/sgrubb/audit/ 
  #upstart 2011-01-19
  <djszapi> hackeron: did you figure it out ?
  <djszapi> Which job is runfirst by upstart ?
  <djszapi> * run first, I would like to start an audit daemon asap.
  <djszapi> so basically the question is like that: "What is the job execution order by upstart ?".
  <djszapi> JanC ^ any idea ? :o
  <djszapi> grep -rni "start on startup" .
  <djszapi> ./sysconfig-early.conf:4:start on startup
  <djszapi> mmh this process k then ^
  <djszapi> The primary event emitted by upstart is startup which is when the machine is first started (without writable filesystems or networking) -> But what is the last when poweroff, core_shutdown ?
  <djszapi> Where can I communicate with an upstart developer ? I did not get any answer on the mailing list for more than 3 days ?
  <djszapi> JanC: do you have any idea how to implement this PID printing for those missing parts ?
  <djszapi> I would like to investigate more time in the patch if I can get any starting hint.
  <JanC> djszapi: Scott is changing between jobs currently, so he might be a bit more busy than usual
  <JanC> jhunt should also be able to help you with the code
  <djszapi> jhunt: please do
  <djszapi> I would like to implement a feature, to print out the shell PID of the pre/post-start/stop commands that were run from those sections.
  <djszapi> JanC: is upstart fully leisure time project for Scott ?
  <JanC> I think he could work on it during working hours too, but not all the time as he had other work to do too
  <djszapi> I meant whether some company pays him for developing upstart.
  <djszapi> seems a quite essential tool in order to get paid by a company.
  <JanC> he was paid by Canonical, probably will get paid by Google in the future
  <JanC> as Google uses upstart in Chrome OS
  <JanC> and they are his new employer
  <JanC> http://netsplit.com/2011/01/11/leaving-canonical/ 
  <jhunt> djszapi: does this relate to your "--verbose" issue?
  <djszapi> y
  <djszapi> jhunt: any idea where to start ?
  <jhunt> djszapi: sorry - meetings :) so from the list mail you are unable to see pids for pre-start scripts for example? I don't fully understand - do you never see pids logged in /var/log/daemon.log?
  <djszapi> what do you mean jhunt ?
  <jhunt> keybuk answered your first query. Your second related to "--verbose" where you are not seeing pids being logged for pre-start scripts for example?
  <jhunt> So, after either specifying "--verbose" or running, "initctl log-priority debug" when you start a job, all script section pids will get logged to (by default) /var/log/daemon.log
  <jhunt> are you saying you get no output in daemon.log?
  <djszapi> jhunt ping
  <jhunt> hello
  <djszapi> sorry I was travelling.
  <djszapi> from Nokia to home.
  <djszapi> 'Your second related to "--verbose" where you are not seeing pids being logged for pre-start scripts for example?' -> Yup.
  <djszapi> never tried /var/log/daemon.log, keybuk said it should be in syslog, he has never mentioned this daemon.log.
  <djszapi> and a mount command is not a daemon for instance.
  <jhunt> well, keybuk is correct in that syslog handles the logging, but on a stock Ubuntu system, it should appear in daemon.log.
  <djszapi> it is not Ubuntu, but Maemo.
  <jhunt> you'll have to see how syslog is configured then. a quick grep in the log directory should show you. If that doesn't work, feel free to post further info to the mailing list.
  <djszapi> did not, posted.
  <djszapi> nothing related and FYI: same by JanC.
  <djszapi> but it is a bit suspicious because keybuk has been quite strong minded about its working situation.
  <djszapi> I could not just speak with him since then.
  <djszapi> I did not even see him on IRC this week or mailing list.
  <djszapi> so 1) To make sure it is not implemented 2) If not I can help and I would like.
  <djszapi> because the situation got worse, auditsyscall kernel option is not supported on ARM :(
  <djszapi> and not a trivial solution to fix it and if it should anyway be in upstart as a feature it is better to deal with that for me.
  #upstart 2011-01-20
  <djszapi> moin' jhunt ;)
  <djszapi> can we continue the discussion ?
  <djszapi> seems upstart is abandoned enough :)
  <djszapi> ping jhunt
  <benc> how can I wait for a server to cleanly stop in a pre-stop event?
  <mbiebl> benc: how do you check if the server is cleanly shut down?
  <benc> mbiebl: I have a script /usr/bin/myserver status
  <mbiebl> if you have such a check, just add  small while loop
  <mbiebl> ideally with a timeout
  <benc> why a timeout?
  <benc> to force stop?
  <mbiebl> yeah
  <benc> thanks
  <mbiebl> say your service dead locks
  <mbiebl> you don't want a shutdown to block because of this
  <benc> I need to read how to write a while loop and a timeout in a script
  <mbiebl> its simple shell 
  <benc> ok
  <mbiebl> benc: add  
  <mbiebl> pre-stop script
  <mbiebl> <your shell script goes here>
  <mbiebl> end script
  <mbiebl> to your upstart job
  <benc> ok
  <SpamapS> jhunt: 'morning
  <jhunt> SpamapS: evenin' :)
  <SpamapS> jhunt: did you have a chance to look at the telinit stuff?
  <jhunt> SpamapS: yeah - I'm wondering if we can take a simpler approach though - maybe watch something in /proc/1/* ?
  <SpamapS> jhunt: thats what I was wondering too. when one re-execs, does its start time re-set in /proc/#/stat ?
  <SpamapS> jhunt: tho again, is /proc still mounted at umountroot time?
  <jhunt> I think we could watch /proc/1/stat. I too was wondering about start time, but ps doesn't appear to report this as I'd expect.
  <jhunt> Certainly, "watch -d -n1 cat /proc/#/stat" works for a script that re-execs itself.
  <SpamapS> hmmmm
  <jhunt> testing now...
  <SpamapS> Good.. my init without the semaphore on first exec just stalls after init: Handling startup event :(
   * SpamapS curses himself for forgetting to clone his pristine lucid VM again
  <jhunt> dang - my vm wasn't exactly pristine either :(
   * SpamapS waits patiently while his new VM installs. :-P
  <jhunt> SpamapS: just mailed you a script to try.
  <SpamapS> jhunt: I'll give it a go shortly. Enjoy the evening. :)
  <SpamapS> I do like solving this in script rather than hacking in more C
  <SpamapS> given that it is a truly temporary solution
  <jhunt> SpamapS: totally agree :)
  <SpamapS> sometimes I just get so excited to write new C.. :-D
  <lasermike026> Clint, thanks for the help on the call.
  #upstart 2011-01-21
  <robs_> someone can take a look at this bug I submitted  ? https://bugs.launchpad.net/upstart/+bug/703993
  <ronny> hi
  <ronny> im a bit at loss, i cant seem to find docs on how to prevent the automated starting of some services
  <JanC> ronny: what version of upstart are you using?
  <JanC> ronny: in 0.6.7 you can use the "manual" stanza, in older versions you can comment out the "start on" line(s)
  <ronny> atm 0.6.6
  <dacresni> how can you which running process depend on an upstart job 
  <dacresni> like what's using mysql now
  <JanC> considering that those processes might be running on a computer at the other side of the world, how do you think that would work?
  <dacresni> other side of the world? im just talking about programs that only start after mysql is running 
  <dacresni> thats the point of upstart right? to only launch programs after the programs they depend on are runnning? 
  <dacresni> in the case of mysql if there are are open sockets i guess i should ask the mysql people about that right?
  <dacresni> or am I confusing this with launchd 
  <jhunt> dacresni: it's not that easy currently - you need to look at the "start on" and "stop on" entries for all jobs.
  <JanC> upstart is based on events, not on dependencies
  <jhunt> quite.
  <JanC> maybe it's possible to document dependencies in job metadata in the future, just like you can document "emits" ?
  <JanC> dacresni: programs/jobs that need mysql might not always have a connection/socket open permanently...
  <dacresni> ok, thanks
  <dacresni> the events vs dependencies tells me that i did confuse it with launchd 
  <dacresni> I forget how systemd does it
  <JanC> you can implement dependencies using upstart's events, but not the other way around
  <dacresni> well, thanks all 
  <kreign> hi, I'm trying to understand the mountall.conf file. I need to have it wait for a custom filesystem module, which is getting modprobed via module-init-tools.conf; however, both these conf files appear to have the same prereq of 'start on startup' 
  <kreign> is there any way to make one a prereq of the other? 
  <kreign> from looking at the files it looks like I can do an "emits fs_module" and then have mountall.conf with "start on (startup and started fs_module)" - is this correct?
  <JanC> "emits" is documentation
  <JanC> so it does nothing on its own
  <kreign> JanC, ok; how can I specify that basic chain of events?
  <kreign> JanC, start on (startup and started init-module-tools) ?
  <kreign> er module-init-tools
  <JanC> sounds like that might work
  <kreign> JanC, or am I going about this the wrong way?
  <kreign> i'm assuming it's not whitespace sensitive...
  <JanC> I guess the "startup" part can be left out too
  <kreign> hmm probably.
  <JanC> and maybe you can make the modprobe for that specific module its own task, so that mountall can start earlier?
  <kreign> JanC, hmm I don't think mountall will be able to start earlier - module-init-tools is the direct prerequisite. 
  <JanC> also depends on whether boot time is important  ;)
  <kreign> not so much.
   * kreign misses the old way of doing things, somewhat.
  <kreign> JanC, I'd think that any filesystem modules should be loaded before filesystems try to mount, anyway.
  <JanC> normally they will be loaded automatically?
  <kreign> JanC, that does not seem to be the case, in this regard.
  <kreign> JanC, the modules aren't strictly "linux compliant" per se
  <kreign> (ok, not going to lie - it's zfs, and I"ve also got to import the zpool in the module-init-tools.conf)
  <JanC> kreign: I think for most filesystems, their mount utility loads the modules, or something like that
  <JanC> I guess 'mount.zfs' (or whatever it's called) doesn't?
  <kreign> JanC, running mountall manually once in does the trick (with 'auto' as an fstab option)
  <kreign> JanC, it just looks like mountall is running prior to zfs module getting loaded (defined in /etc/modules) and not knowing what -t zfs is. :)
  <kreign> so, it dies.
  <JanC> right
  <JanC> like I said, you can use an extra job only to load the ZFS modules and make mountall.conf depend on that task
  <kreign> I don't recall classic init hanging on exception like this... iirc it'd continue despite problems.
  <JanC> classic init did a lot of things serially
  <kreign> JanC, right - but the zfs modules would need to be loaded beforehand, which are defined in /etc/fstab, so it makes sense to have the module-init-tools.conf do that.
  <JanC> if you don't mind waiting until all those modules are loaded
  <JanC> in most cases not an issue, I think
  <kreign> JanC, yeah. it's on server hardware, so...
  <kreign> slow bios
  <kreign> that's like 3-4 times as long as boot even though it's booting from sloooooow flash media
  <JanC> âº
  <kreign> well let's hope i didn't biff it
  <JanC> my desktop doesn't boot fast either  ;)
  <kreign> i don't want to walk across the building again
  <kreign>  15:38:28 up 123 days, 23:34,  9 users,  load average: 0.66, 0.57, 0.49
  <kreign> ^ not much a problem for me.
  <kreign> tho i should probably do something like that. I've had two new kernels installed since then...
  <JanC> right
  <JanC> I was going to say: I install security updates  :P
  <kreign> JanC, oh I do too.
  <kreign> just don't usually have the time for a reboot... will probably do that tonight and watch monday be unproductive fixing things.
  #upstart 2011-01-23
  <tanepiper> hi, can someone help me with this: https://gist.github.com/2d1703cede3597abd595
  <tanepiper> if i try start on startup, i get an error that /var isn't mounted
  <tanepiper> however if I manually call start quartermaster, the app starts fine
  <tanepiper> oh looks like i solved it :)  start on mounted; env MOUNTPOINT=/var
  <ion> Ubuntu? âstart on filesystemâ
  <ion> Such an âenvâ stanza doesnât really do anything except set the value of MOUNTPOINT for your scripts.
  <ion> HOME is something you could use env for.
  <tanepiper> well that's working as well, thanks :)
  <ion> âstart on mountedâ probably never really worked. If it happened to get started at the right time based on it, you were just lucky. :-)
  <ion> Also, 2>&1 before 1>â¦ makes stderr go to stdout and stdout go to the logfile. You probably want to make 2 a copy of 1 after 1 has been redirected to a file.
  <tanepiper> yea, i started with a copy & paste job for running nodejs but that just wasn't working.  I'll definetly read up more on the upstart blog
  <tanepiper> so 1> /var/log/foo > &2  ?
  <ion> >>/var/log/foo 2>&1
  <tanepiper> gotch
  #upstart 2012-01-17
  <lactose>  so i am trying to set up rails with unicorn. i have my unicorn 
  <lactose>                  config.rb file set up, and if i run unicorn_rails -c 
  <lactose>                  /path/to/config.rb as my user everything starts up fine and i 
  <lactose> woops
  <lactose> so i am trying to set up rails with unicorn.  i have my unicorn config.rb file set up, and if i run unciorn_rails -c /path/to/config.rb as my user everything starts up fine and i can view the website. however ifi run the Upstart script, I get no error message, (and the script basically exec sudo -u myuser -i `unicorn_rails -c 'path/to/config'` but i cant view the website. im redirected to my 500 error page (in the logs it says 111 con
  <SpamapS> lactose: probably something in your environment that is needed. Maybe try adding > /var/log/myjob.log 2>&1 to see if there are helpful errors.
   * SpamapS disappears
  <lactose> SpamapS: I have done so, and the file is empty
  <lactose> SpamapS: do yo uthink that the unicorn_rails command cannot be accessed -- my ruby install is through rvm and I personally cannot run this command unless I am in the working directory. But if this were the case, why is the error log file blank?
  <lactose> SpamapS: this was the problem. I chowned the .conf file in /etc/init to myuser and transferred the command to .sh in the directory of the rails app, then the conf simply exec the .sh. Do you see any security or other problem with this approach? 
  <lactose> anybody else can answer that as well
  <SpamapS> lactose: you shouldn't need to chown the upstart job to your user.. that should not change who the job runs as.
  #upstart 2012-01-18
  <declanmg> Hi all
  <declanmg> Is there anyway to set the PATH within an /etc/somejob.conf upstart file?
  <declanmg> Or is there any other systemwide config file that it is appropriate to set the PATH in so that it is picked up by upstart jobs?
  <ion> The env stanza should probably work in somejob.conf.
  <declanmg> ion: Thanks a mill for the that. I will try it now. Have been exhaustively trying to track down docs on this online.
  <ion> init(5)
  <ion> And the cookbook
  <declanmg> ion: mmm... will research the cookbook
  <declanmg> Cheers
  <ion> Be sure to look at init(5) as well.
  <declanmg> ion: Will do, thanks again.
  <declanmg> Very useful resources, ion
  <declanmg> Though if I set the PATH env variable in job1 and export it, it is still not available in job2 (which I have set to start on job1).
  <declanmg> Section 7.2 of the cookbook seems to suggest that the exported var should carry through (in the cookbook example's case it is $foo)
  <declanmg> Alternatively, I could stick the env PATH stanza into /etc/init/env.conf but I need the upstart job to be able to pick up /etc/init/env.conf changes between server restarts.
  <declanmg> Which I don't think is possible :(
  <SpamapS> We should watch serverfault.com for good upstart questions and potential cookbook additions
  <SpamapS> http://serverfault.com/questions/307704/how-can-i-ensure-a-script-gets-executed-after-a-service-is-stopped-but-before-an/351115#351115
  <SpamapS> Have seen a number of them the last few days
  <SpamapS> oops meant to paste http://serverfault.com/questions/tagged/upstart .. though that is a good link to an answer I just gave that could use a few +1's ;)
  <jodh> SpamapS: good find, yes agreed. Also, we really must get apache2 et al upstartified (or atleast "initctl emit starting" et al added to SysV compat side of the world).
  <SpamapS> I think we should upstartify it the way I suggest.. we can't possibly handle the SIGUSR1 stuff properly with expect daemon/fork, so better that we just let apache2's pid file tracking do its thing, and just use upstart to insert the job into the event tree.
  <SpamapS> jodh: I have wondered about having rc emit events for all scripts it runs.
  <jodh> jodh: ditto. rhel6 do this I believe.
  <JanC> SpamapS: might be usefull to add a link to the cookbook to such questions too?
  <SpamapS> JanC: yeah that would probably be good
  <ahammond> I'm running ubuntu 10.10 and want to get latest upstart on it. Is there a PPA / what's the right way to do that?
  <JanC> you can't upgrade to Ubuntu 11.10 instead?
  <ahammond> JanC: that gets me 1.3 (which is good, butâ¦ no setuid / setgid) and it's a much harder sell.
  <ahammond> the answer might be to wait for 12.4 which we are planning to upgrade to anyway.
  <JanC> ah, you really mean latest-latest  âº
  <ahammond> JanC: setuid/setgid lets me write upstart scripts that don't need sudo or start-stop-daemon: win
  <ahammond> and that logging stuffâ¦ also a big win.
  <JanC> logging stuff is cool, setuid stuff sounds more like "sugar"?  âº
  <JanC> anyway, I don't know about a PPA, but there might be an unofficial one somewhere
  <ahammond> JanC: we have some in house apps where setuid is more like "absolute requirement" :)
  <JanC> well, sudo should work
  <ahammond> I've been using start-stop-daemon since it also gets me chdir and chroot jails if I want them.
  <JanC> or that
  <ahammond> we'll probably just put the project off until we've moved to 12.4.
  <ahammond> Hmmm...
  <JanC> it might be possible to make a backport of upstart, but that also might require some changes to existing jobs maybe...?
  <ahammond> yeah, probably too much change for production boxes. We've already scheduled the upgrade to 12.4, so...
  <JanC> ahammond: I'm sure the Ubuntu & Upstart developers would appreciate if you test this on precise *before* it gets released as 12.04 BTW  âº
  <JanC> (and also useful for you if they fix issues before you need to depend on it)
  <ahammond> I'd love to help out. What exactly would be needed?
  <JanC> ahammond: install a system (maybe a virtual machine) with the current development version of precise, and try to write the upstart job you need; if anything fails, report bugs so that (hopefully) they get fixed before the release  âº
  <JanC> (assuming precise already has the latest upstart, of course)
  <ahammond> JanC: looks like it's got 1.4
  <JanC> so, try to set up something similar to your production system on it, make the cahnges you want, and pester the developers until they fix all issues  ;)
  <SpamapS> upstart from precise should in theory backport just fine .. though the /run transition may require delicate handling if you try to go back to say, 10.04
  <ahammond> SpamapS: I think we'll wait until we have 12.4.
  <SpamapS> ahammond: its really just syntactic sugar.. start-stop-daemon does in fact do the same thing.
  <ahammond> SpamapS: yeah, I've been writing them using start-stop-daemon. Makes for some ugly stuff. Want pretty instead. :)
  #upstart 2012-01-19
  <SpamapS> ahammond: indeed.. tweaks here and there just make them simpler
  <SpamapS> expect exit should also eliminate some unsightly post-start's
  <bradleyayers> i'm using ubuntu 10.04 lts, but i want to use upstart 1.4, is this possible?
  <SpamapS> bradleyayers: in theory it would work fine
  <bradleyayers> i'm cherry picking the dependencies from 11.10 
  <SpamapS> bradleyayers: the package might not work without some mods, but the upstream bits would probably be fine.
  <bradleyayers> Plesk is installed on the server, so i'm concerned it might break that, since it does all sorts of stupid shit
  <SpamapS> hah yeah .. plesk + anything different == immolation of your entire business
  <bradleyayers> it's horrible D:
  <bradleyayers> uhh how do i get dpkg to install two things that depend on each other: http://dpaste.com/690059/ :(
  <bradleyayers> oops, i should really ask in ubuntu
  <brodock> can someone please take a look at this question: http://serverfault.com/questions/337198/upstart-output-pre-start-script-content/351124 ? Is there a better way to do it?
  <SpamapS> jodh: Hey, I'm working on an upstart cookbook fix and I noticed this language ...
  <SpamapS> The advantage of using `start-stop-daemon(8)`_ is that is simply changes the
  <SpamapS> user and group the command is run as. However, there is a problem with
  <SpamapS> using ``start-stop-daemon`` in that Upstart cannot track the PID for jobs
  <SpamapS> which use it
  <SpamapS> I don't see why that would be the case
  <SpamapS> running that way drops user privs, then execs the requested command.. so upstart should be able to handle it just fine
  <tmike> Hello.  I'm trying to build upstart for an LFS environment and having some issues with failing the tests.
  <SpamapS> tmike: pastebin your failure maybe?
  <tmike> http://pastebin.com/rZmbnhDa
  <tmike> Sorry got distracted setting up pastebincl on the vm
  <tmike> test_job_process sees the wrong output for the /this/command/does/not/exist bits
  <tmike> that's the first error
  <tmike> That 'wrong content' part, with the test_job_process is not the first error of that variety.  I went and changed the test to look for "No such file or directory" and then started to wonder if there's a reason it wants 1: /this/blah: not found instead of the "No such"
  <tmike> Actually, if I don't run the tests as superuser, those are the only errors I get.
  <tmike> Should I just ignore the failures, or is there a reason to expect the "not found" errors vs the "No such" errors
  <tmike> ?
  #upstart 2012-01-20
  <SpamapS> tmike: the test suite is not meant to be run as root, in fact I believe it is meant to fail as root
  <SpamapS> tmike: there's one fail that is no big deal, just a different error message. The one where len is expected to be 13 and is 0 looks more serious.
  <pmjdebruijn> hi
  <pmjdebruijn> are there known issues with upstart and lots of file descriptors?
  <pmjdebruijn> I'm running dansguardian -N (=foreground) from an upstart job
  <pmjdebruijn> with 4000 file descriptors
  <pmjdebruijn> seems to work fine from the init script
  <pmjdebruijn> though I'm wondering if upstart ignores the ulimit I have in there... and/or the security/limits.conf
  <jodh> pmjdebruijn: upstart doesn't have pam support so limits.conf is not used.
  <pmjdebruijn> ah ok
  <pmjdebruijn> but settings ulimit -n in the pre-start script doesn't seem to help either
  <jodh> pmjdebruijn: that's because the pre-start is run as a process so any other process spawned from that job won't be affected by what you do in pre-start.
  <jodh> pmjdebruijn: You need the limit stanza - http://upstart.ubuntu.com/cookbook/#limit
  <jodh> pmjdebruijn: init(5) for full details.
  <pmjdebruijn> jodh: that makes sense, but the squid package in maverick has ulimit set in pre-start
  <jodh> pmjdebruijn: sounds like you found a bug then ;-)
  <pmjdebruijn> heh
  <jodh> pmjdebruijn: still seems to be a problem in precise: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/squid/precise/view/head:/debian/squid.upstart Could you raise a bug on this? (so you get the kudos :) - https://bugs.launchpad.net/ubuntu/precise/+source/squid/+filebug
  <pmjdebruijn> jodh: I haven't verified this is a problem in squid
  <pmjdebruijn> I just used it as a (bad) example
  <pmjdebruijn> well let me file the issue
  <jodh> pmjdebruijn: thanks. either that "ulimit -n" needs to be moved to the script section, or "limit nofile $var $var" syntax needs to be used.
  <pmjdebruijn> https://bugs.launchpad.net/ubuntu/+source/squid/+bug/580590
  <pmjdebruijn> though that contains a verification
  <pmjdebruijn> odd
  <tmike> Would anyone happen to know if this error in the build logs is a serious issue?: http://pastebin.com/9UCnd4gg
  <tmike> check log*
  <jodh> tmike: what shell are you using for /bin/sh?
  <tmike> bash
  <jodh> tmike: oh.
  <jodh> tmike: that explains it. /bin/sh is not supposed to be bash. However, please raise a bug on upstart so we can tweak the test case for this: https://bugs.launchpad.net/upstart/+filebug
  <tmike> What is /bin/sh supposed to be, then?
  <pmjdebruijn> dash probably
  <jodh> tmike: correct.
  <jodh> pmjdebruijn: correct even :)
  <tmike> I could see that.  All right.  Building dash it is then.
  <tmike> This is on a linux from scratch build.
  <tmike> Well, before I do that, is it a problem that I use bash instead of dash?
  <jodh> tmike: interesting!
  <tmike> Lots of fun.  It boots with sysv init right now, but I'm experimenting with upstart.
  <jodh> tmike: the recommendation is not to use bash for /bin/sh for performance but primarily security reasons. bash syntax is too expressive and dash is "just a posix shell"
  <jodh> tmike: since upstart is going to be using /bin/sh to run most of your jobs, it really is best to use a very basic shell.
  <tmike> very interesting
  <tmike> thank you for your advice
  <jodh> tmike: See also http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
  <tmike> That's a very useful bit of information.  As it is, I'm having trouble even using the provide sulogin
  <jodh> tmike: to be clear, I'm not implying bash is actually insecure, but it's overkill for upstarts needs.
  <pmjdebruijn> check-bashims is quite handy :D
  <pmjdebruijn> check-bashisms even
  <tmike> linux /vmlinuz-3.1.blah root=(hd0,3) init=/opt/sbin/sulogin behaves just like a regular init.  Starts up my daemons and dumps me at a login prompt
  <jodh> tmike: I'd be very interested to hear on your progress with linux from scratch. It might even merit a section in the cookbook.
  <tmike> the upstart init itself gets to the point where it tries to mount my drives; I'm not sure whether it succeeds.  Then it prints some USB information and just stops
  <tmike> Which may very well be related to the link you posted above, hodh
  <tmike> jodh*
  <tmike> It's using the default init scripts at the moment as I haven't written any real upstart jobs for it, and I'm almost certain something in there needs to be modified to point back to a correct executable for upstart.
  <tmike> By default, I mean it's going through my sysv init scripts and running those
  <tmike> I thought it would be worth a shot, because LFS is about as untainted an OS as you can get.  Most distros have a great deal of customization done where LFS is almost entirely vanilla source for all its packages.
  <jodh> tmike: well, you'll need to ensure the system boots with init=/sbin/init where that is the upstart binary. You'll also need to "SysV compat" jobs (rc.conf and rc-sysinit.conf) - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/upstart/precise/files/head:/conf/
  <jodh> tmike: I'd suggest reading the cookbook. In particular http://upstart.ubuntu.com/cookbook/#startup
  <jodh> tmike: udevd, upstart-udev-bridge and mountall are also going to be important. Maybe you could post to the upstart-devel ML with progress?
  <tmike> Correct, I've been in that cookbook for a while.  It seems I'll be handling a lot of that stuff manually; mountall looks a lot like it wants *ubuntu specific setups
  <jodh> tmike: Ubuntu does use mountall for mounting yes. It's "ubuntu-specific" in the sense that only Ubuntu uses it. Note that rhel 6 / centos 6 don't use mountall. They only use upstart minimally at this stage so it might be worth seeing what they've done to get you going.
  <tmike> I may very well.  Mountall also doesn't seem like it wants to build without plymouth.  No offense to plymouth, but NO THANK YOU.
  <tmike> ;)
  <tmike> Too much effort to start building initramfs's and trying to configure all that garbage
  <tmike> A shame actually.  Plymouth seems pretty nice, and if I had luks on this VM, I'd love to have a lovely interface for my password entries.
  <tmike> The 'start on' and 'stop on' directives, do they actually call the executables {start,stop} or are they interpreted?
  <jodh> tmike: they tell upstart when to start the overall job. See http://upstart.ubuntu.com/cookbook/#really-understanding-start-on-and-stop-on
  <tmike> Okay.  Just wanted to make sure I didn't need to do anything ridiculous like change all "start on" to "/opt/sbin/start on"
  <JanC> an upstart job description isn't a script  ;)
  <tmike> That's exactly what I figured, but I thought it easier to ask rather than go down that road later when debugging, only to have to walk all the way back ;)
  <tmike> Maybe this afternoon I'll set about building *.in files for these .confs for the make job, such as to prepend the $PREFIX/bindir to the commands.
  <tmike> for the exec commands and such
  <tmike> My oh my these errors are colorful ;D
  <tmike> http://imgur.com/2HQI5
  <tmike> That's all script-funkiness though.  Will need to discover why that stuff's not getting mounted.
  <tmike> Awesome, got one step further.
  <tmike> rc-sysinit.conf tries to execute /etc/init.d/rcS, which my system doesn't have
  <tmike> However, /etc/init.d/rc S (note that S is a parameter) replaces that functionality.
  <tmike> As dictated by my inittab.
  <tmike> Now it crashes mounting my virtual filesystems
  <tmike> And actually it only sort of dies.  I can let it continue past that point, where it runs up to just before giving me a login prompt, where it just stops
  <tmike> Fortunately, it starts SSH for me, so I can still SSH into it :D
  <tmike> Once I solve that problem, it will have worked virtually out of the box.
  <tmike> Well, I guess not really.  Still a mess of errors in the logs.
  <tmike> It seems to repeat the whole process, which means I'm probably calling rc S twice, or further rc steps call rc S
  <tmike> initctl list lists all the tasks in /etc/init as in 'stop/waiting' though
  <tmike> Is that correct?
  <jodh> tmike: you'd expect rc jobs to be stopped once the system has booted, yes. might be worth grabbing an Ubuntu image so you can compare your results with a normal upstart system.
  <tmike> That's what I thought.
  <tmike> I expect that's the reason why the system manages to get to the end of the rc stuff, but never places me at a login.  There's either something that's missing or it's in a race condition.
  <tmike> And it never releases from the rc jobs
  <tmike> My host is ubuntu, so it'll be easy to dig in there to see
  <jodh> tmike: look at this for some hints: http://upstart.ubuntu.com/cookbook/#debugging. have to afk...
  <tmike> Thanks for your help
  <tmike> So, when you get back, or to anyone else who's around, does 'stop/waiting' mean it's not yet started, that it's stuck waiting TO stop, or that it has stopped?
  <jodh> tmike: that's the "rest" state - it has either never started, or has now stopped. See http://upstart.ubuntu.com/cookbook/#initctl-status
  <tmike> Okay, that's good then
  <jodh> tmike: Try booting with --debug/--verbose to see what events are being emitted and which jobs are starting, etc: http://upstart.ubuntu.com/cookbook/#add-verbose-or-debug-to-the-kernel-command-line
  <tmike> Seems everything is groovy there
  <jdiggy> Hi! I'd like to check for the existence of Upstart in a script. The best idea that I've had so far has been to check the output of `init --version`.
  <jdiggy> any way to reimport my configuration without restarting? like if I screw it up and just want to reload it.
  <jdiggy> My bad. wrong channel.
  <jdiggy> Here, I want to ask if anybody knows how to check whether Upstart is installed in, say, a Bash script? My current best idea is `init --version`.
  <ion> Some implementations of init might do something unexpected with --version, though.
  <jdiggy> Agreed. That's why I'm looking for something more reliable. The existence of some file or other. 
  <jdiggy> Upstart's configuration directory is called /etc/init. The bins are called init, start, stop, restart. 
  #upstart 2013-01-14
  <royal121> Hello Everyone! Where can I read about migrating to upstart from other init systems?
  <stgraber> xnox, jodh: I may be a couple of minutes late for the meeting
  <xnox> jodh: the fix is to write cookbook answer "if you need to depend on the sysv init starting, just add emit that event in the init script"
  <xnox> stgraber: ^
  <xnox> =))))
  <xnox> jodh: stgraber: i can hear you.
   * xnox 's ISP is rated as the worst in the UK for latency (virgin media)
  <emacsen> I have a (hopefully) simple question. I want to write a daemon that detects when the network is active and only attempts to operate then. Is upstart the way to do that, and if so, what should I be looking for?
  <stgraber> we don't have any internet-is-ready even at this point (assuming you're using upstart on ubuntu), mostly because the definition of "internet" and "is-ready" depends quite a lot on what you're planning to do with it :)
  <stgraber> so you can your job depend on an interface being configured but can't reliably have it depend on the system having internet connectivity
  <stgraber> *can make
  <stgraber> if you just want to start it when the system is done configuring all defined network interfaces, you can have it start on "static-network-up"
  <emacsen> stgraber, okay. Thinking about what I want to do, I guess it doesn't matter much
  <emacsen> (I'm just thinking about an improved msmtpQ
  <emacsen> I can just do it with cron
  <stgraber> xnox: got initctl to work with UPSTART_SESSION, still have to debug why I'm seeing all entries twice (same thing when using --session), will do that tomorrow
  <stgraber> my current guess is that for some reason initctl queries both the session and system bus for the state, which is obviously quite wrong
  <stgraber> oh, and initctl apparently gets into an infinite loop when you try to start/stop a job that has a name matching that of a system job ;)
  <stgraber> (same bug, just worse symptom that what I first noticed)
  #upstart 2013-01-15
  <toabctl> xnox, thanks for the d-feet sync
  <xnox> toabctl: no problem. Why this channel?
  <xnox> =))))
  <toabctl> xnox, because I know you are here:=
  <toabctl> ;)
  <ztane> got firefox zombie clinging to pid 1, which is a bit annoying because now for some reason firefox does not want to start using a same profile until I reboot my computer... (maybe it is using a pidfile to guard the profile dir).
  <ztane> up-to-date freshish install of 1210
  <jodh> ztane: can't you kill the firefox pid?
  <ztane> jodh: ofc not, that is what a zombie process is
  <ztane> a pid
  <ztane> + an entry in a process table
  <jodh> ztane: I didn't notice the word 'zombie' there :) is Upstart still responding? Can you start a new job for example?
  <ztane> jodh: let me check
  <ztane> jodh: works
  <ztane> jodh: xnox said that there is no support for general zombie reap in upstart init?
  <xnox> well, for jobs that were not started by upstart.
  <xnox> (but I may be wrong ztane, maybe jodh can give a more full answer)
  <ztane> pstree says init-+-firefox---43*[{firefox}], hanging there tight
  <ztane> hmmm
  <ztane> ah :D
  <ztane> my bad :P
  <ztane> there was 1 parent process running, which is apparent from that pstree
  <ztane> dunno why it was not killed by killall
  <xnox> =)
  <jodh> xnox/ztane: upstart calls wait repeatedly so it will handle zombies and orphans.
  <xnox> ack.
  <stgraber> jodh: hey, any idea why upstart would return user jobs twice?
  <stgraber> jodh: initctl --user or --session lists all the jobs twice. I initially thought it was a bug in my code (connecting to both buses) but it's not.
  <stgraber> method return sender=:1.119 -> dest=:1.128 reply_serial=4
  <stgraber>    array [
  <stgraber>       object path "/com/ubuntu/Upstart/jobs/dbus"
  <stgraber>       object path "/com/ubuntu/Upstart/jobs/201105/dbus"
  <stgraber>       object path "/com/ubuntu/Upstart/jobs/debug"
  <stgraber>       object path "/com/ubuntu/Upstart/jobs/201105/debug"
  <stgraber>       object path "/com/ubuntu/Upstart/jobs/upstart_2devent_2dbridge"
  <stgraber>       object path "/com/ubuntu/Upstart/jobs/201105/upstart_2devent_2dbridge"
  <stgraber>    ]
  <stgraber> that's what initctl is getting back from upstart. Obviously that's confusing it slightly ;)
  <jodh> stgraber: probably because we haven't removed the existing user job handling code.
   * xnox ponders what 201105 in above means
  <stgraber> jodh: that's my uid
  <jodh> stgraber: try disabling Upstart.conf and seeing if behavious is the same: http://upstart.ubuntu.com/cookbook/#enabling
  <xnox> stgraber: a bit high =)
   * xnox is 1000 everywhere =)
  <stgraber> xnox: RID-based UID in a samba4 domain gets you pretty big UIDs
  <stgraber> jodh: yeah, I think that's it. So hopefully that'll get fixed once we get rid of the current user job code.
  <jodh> stgraber: do you want to volunteer? ;)
  <stgraber> jodh: one thing that's "interesting" is if you have a job defined as both system and user, then you try to start the user one with "initctl start dbus" (for example). That'll get initctl in some kind of infinite loop and will almost freeze upstart in the process (the user upstart, not the system one)
  <stgraber> but my guess is that this will be fixed once we no longer have duplicate entries
  <stgraber> jodh: hehe, I've got a reasonably long todo list before I can et to that, but I can take a look once I'm done with my higher priority items :)
  <jodh> stgraber: agreed. ok, ta.
  <stgraber> xnox: I think I found what's broken in the upstart dailies
  <stgraber> basically, the ubuntu branch contains some ubuntu-specific patches that we don't have in the dailies
  <stgraber> the most important one being a change to the rc-sysvinit.conf start condition
  <stgraber> which perfectly explains the breakage on my machine
  <stgraber> so we can't simply use debian/ from the ubuntu branch for the dailies... we need to also get those changes out and into debian/patches, make a second branch with that and use it as the packaging branch
  <stgraber> (or just finally make ubuntu:upstart non-native and use debian/patches for those ubuntu-specific deltas, making the packaging branch re-usable for the dailies)
   * xnox +1 for ubuntu:upstart to be 3.0 quilt. But I'm sure it's not slangasek's preferred upstart workflow.... =)
  <xnox> stgraber: what about basing recipe on lp:ubuntu/upstart & merging in lp:upstart and hoping it all just works?=)
  <stgraber> I'd have to check if the recipe format allows merging and I guess we'd need a fair amount of hoping considering the number of changes we've made lately ;)
  <slangasek> 3.0 quilt + bzr is my preferred workflow in the alternate universe where I am the Marquis de Sade
  <stgraber> xnox: 5 conflicts, so not terribly bad, but can't be done automatically, so won't quite work for the daily builds
  <slangasek> xnox: find a solution to 3.0 (quilt) that won't require us to do stupid merges for anything other than the upstream source tree, and propose it?
  <xnox> stgraber: the way i deal with conflicts is created a third branch which resolves the conflicts and then you get a common base you merge up lp:ubuntu/upstart + common-conflict-resolve-branch + lp:upstart
  <xnox> recipes can handle that.
  <xnox> slangasek: I did make a proposal as summer of code project. Store the tree unpatched and offer looms api to view the patches and diff/switch up & down. But looms are never committed only flat patches are. (v2) same but generate bundles out of patches such that you can create patched branch to rebase it -> and export a new patch series.
  <xnox> slangasek: the project was not picked up =)
  <slangasek> heh
  <xnox> mercurial-queues is the best for debian/patches. They are quilt compatible but each patch has hg metadata in them. And there is nifty commands to rebase/add/remove/merge patches in that quilt series.
  <xnox> unfortunately nobody stepped up to write a good hg-buildpackage.
  <slangasek> xnox: why do you propose using the patches as the stored representation, rather than using the looms as the stored representation and serializing debian/patches from there?
  <xnox> slangasek: because of 3.0 (quilt) package format, which inherintely from quilt doesn't have $ quilt merge-series command nor $ quilt rebase-series command.
  <xnox> slangasek: if we get 3.0 ($vcs) format, there is no need for patches. But that opens a different kind of warms (no way to easily get the diff upstream vs packaged-changes)
  <slangasek> why would I ever need/want to do such a merge-series or rebase-series?  Shouldn't loom primitives be sufficient?
  <xnox> slangasek: if everyone switches and there are no exceptions, we can policy enforce looms and use that and live will be wonderful.
  <xnox> s/live/life/
  <slangasek> we don't need to switch "everyone" in order to make a policy change on UDD
  <xnox> slangasek: i somehow believe that unless everyone switches, there will always be packages that fail to import or do something funny which will break UDD.
  <slangasek> who is "everyone"?
  <slangasek> I don't understand who you're saying would be switching, here
  <slangasek> UDD itself imports from the archive, the archive wouldn't know anything about looms
  <xnox> "everyone" - any package that is ever manually generated & uploaded into ubuntu.
  <slangasek> unless you mean a 3.0 (bzr) format would be a prereq?
  <xnox> yes. prereq.
  <slangasek> ah
  <slangasek> yeah, that's not a great solution
  <xnox> exactly.
  <slangasek> why don't you think looms could be used to output 3.0 (quilt) reliably?
  <xnox> slangasek: packages that have both /debian/patches/series and /debian/patches/series.ubuntu fail spectacularly in the current UDD workflow.
  <xnox> guess which series the importer imported for the whole history?! =)
  <xnox> is one practical point I can think of.
  <slangasek> hmm
  #upstart 2013-01-16
  <slangasek> I'm trying to think through why that's not simply a bug in the current importer, fixable by having richer annotations in the loom data
  <xnox> bug 911496
  <xnox> http://pad.lv/911496
  <xnox> because given one source package in can now have one or many states (the debian one or the ubuntu one) for each version =/ and it all gets hairy.
  <slangasek> ah right, because then you're trying to do a merge from the Debian branch into the Ubuntu branch, and use the looms for it, but the Debian branch's loom doesn't actually represent what you'd be merging
  <xnox> =) yeap.
  <xnox> i think it was a bad idea to introduce series.vendor
  <xnox> anyway =) i want tea and need to send in patch pilot report.
  <slangasek> :)
  <jodh> xnox/stgraber: comments please - https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Shutdown_Details
  <stgraber> jodh: looking
  <stgraber> jodh: wow, we end up with a pretty complex logout sequence but I guess it makes sense ;) We'll need to restrict the shutdown command to --user for now to avoid people trying to use it against PID 1.
  <jodh> stgraber: It might need some tweaks, but it's as fair as I could make it whilst also having reasonable performance.
  <jodh> stgraber: agreed - this is for Session Inits only for this cycle :)
  <jodh> stgraber: an alternative could be that we handle the entire shutdown from a job, but I'm not particularly in favour of that as we don't have sufficient control over the other jobs.
  <jodh> stgraber: do you know the desktop suspend path? That's the only scenario not covered in that section.
  <stgraber> jodh: I think the desktop suspend path is pretty much a direct call to pm-suspend, I'm not sure gnome-session is really involved there
  <jodh> stgraber: ack. I wonder if adding a pm-suspend hook that emits a 'resumed' event would be useful?
  <stgraber> jodh: yeah, I guess having suspend/resume events would be nice and will be easy enough to do
  <xnox> jodh: do we not have those system wide? or we just come back and assume the laptop is still in the same country connected to the same Heathrow airport wifi hot spot?
  <xnox> is this point were I am being pressed for :: events?! =)
  <jodh> xnox: we don't have such events atm, but yeah, it should be at the :sys: level.
  <stgraber> jodh: just saw your e-mail, looks like that branch isn't based on the right upstream branch, let me fix that :)
  <stgraber> (I didn't modify any .conf in my branch, so I must have messed up its base yesterday when debugging upstart)
  <jodh> stgraber: ok, np.
  <addisonj> looking at this post: http://serverfault.com/questions/128605/have-upstart-read-environment-from-etc-environment-for-a-service, is this still the best way to properly source an environment?
  <xnox> addisonj: yes, but tbh it's best to only source the only environemt variable you want / need like guested in the second answer.
  <addisonj> xnox: so setuid/setgid doesn't do anything PAM? just runs the daemon with that uid/gid set?
  <xnox> yes.
  <addisonj> xnox: yeah, problem is, we inject config into our application servers through env vars and don't want to maintain that list elsewhere...
  <xnox> I believe, you can check the source code should be easily done.
  <xnox> addisonj: but you do have that list somewhere right?!
  <addisonj> chef writes it out to /etc/environment
  <xnox> addisonj: on debian/ubuntu systems it is typical to have /etc/defaults/mydaemon which is user editable file for configs.
  <xnox> addisonj: chef can also write out /etc/init/mydaemon.overrides which includes partially the stanzas you need with environmental variables you need.
  <xnox> s/overrides/override/
  <xnox> which upstart will apply on top of the .conf file.
  <xnox> (patch-style replacing individual stanzas)
  <addisonj> oh, cool, didn't know that
  <xnox> see cookbook
  <xnox> http://upstart.ubuntu.com/cookbook/
  <addisonj> right now, we just use su and run it as our non-privileged user with env sourced, which has worked
  <addisonj> but now I am trying to do a reload but the SIGHUP isn't getting through to me process
   * xnox wonders if upstart is tracking su pid, instead of daemon pid.
  <addisonj> i believe it is
  <xnox> does $ status mydaemon matches the pid of the daemon queried via ps?
  <addisonj> oh, lemme check, never thought of doing that
  <xnox> cuase if it doesn't upstart is sending SIGHUP to something else =))))
  <xnox> (also see cookbook on establishing fork count)
  <addisonj> yeah, the pid is the su process
   * xnox recommends to avoid su / sudo in upstart jobs
  <addisonj> so I just need to do expect fork 2 or something and it should work I imagine?
  <xnox> http://upstart.ubuntu.com/cookbook/#expect-daemon
  <xnox> expect daemon
  <addisonj> yeah... thats why I was asking about proper PAM support so I could avoid that, maybe I shall hack something up to properly source env as part of the job
  <addisonj> on another note however, upstart is quite awesome :) I much prefer it to init.d
  <xnox> addisonj: http://paste.ubuntu.com/1538257/
  <xnox> example of script stanza that sources config file with envrionment variables and then executes fork.
  <xnox> you can have setuid/setguid stanzas up there if you need to change user.
  <xnox> this way you track "expect fork" & don't need su
  <addisonj> hrm, interesting, I think the only problem with that is that /etc/environment vars don't do an export :\ but I think ican make it work with someting like that
  <xnox> . /etc/environment
  <xnox> export $PATH
  <xnox> export $socks_proxy
  <xnox> or whichever you need.
  <xnox> or make chef write out sourcable / exportable /etc/environment
  <addisonj> yeah, I shall figure something out, but you have been quiet helpful, many thanks
  <xnox> np.
  <stgraber> jodh: ping
  <stgraber> jodh: ping?
  <depesz> hi. first of all - i never had to write init scripts for upstart. but today is the day. So, I have a program, pgbouncer, that I can start, or stop, and it works fine.
  <depesz> but. this program has also full online restart mode. where I run it using special parameters, and it takes over job of previously running copy. but the new copy has different pid, and upstart doesn't knwo it's still running
  <depesz> do you know of any way to let upstart know that pid of a service has changed ?
  <JanC> depesz: I suppose you mean it does a handover between 2 instances of the program so that there is no "gap" during the restart?
  <JanC> no availability gap
  <depesz> i am not sure about how it works internally, but as far as I understand - there is no gap as in "moment in time when there is no pgbouncer"
  <depesz> there is always some pgboucner running, but it can online restart/upgrade
  <JanC> maybe you could do some trickery by only using pre- & post- scripts but no main exec/script
  <JanC> but it's certainly something where upstart could improve
  <xnox> depesz: JanC: in this case you should use instances and restarting actually should stop one instance and start another.
  <xnox> this way you can achieve & monitor the overlap as well.
  <depesz> xnox: but i don't want to use restart.
  <depesz> as restart does stop+ start.
  <depesz> the built-in (in pgbouncer) is much better
  <xnox> depesz: you can override in pre-stop script what actually happens during stop+start combo.
  <xnox> depesz: detect that restart was requested and perform the pgbouncer handover.
  <xnox> I am giving you a method how to use the built-in pbuilder restart & let upstart track the new pid.
  <depesz> hmm .. ok
  <JanC> xnox: that's more or less what I suggested, but there should probably be a more user friendly way to express that in upstart
  <xnox> 90% things are trivial 10% are easy enough to achieve ;-) pre-stop scripts are unusual but it's not the end of the world.
  <JanC> xnox: still, having syntax for it makes it easier to understand what the config does
  <JanC> that's why sysvinit scripts have a semantic difference between restart & reload, for example
  <xnox> JanC: so does upstart. it has both reload and restart
  <JanC> except reload & restart are still (mostly) hardcoded
  <JanC> and reload breaks if it causes the daemon to "switch" to another PID
  #upstart 2013-01-17
  <thec4ke> so do all upstart script sections run with set -e?
  <SpamapS> thec4ke: yes, turn it off with set +e
  <thec4ke> thx
  <SpamapS> thec4ke: or use || : for the 1 or 2 things that you don't care about failure on
  <UukGoblin> hi
  #upstart 2013-01-18
  <jodh> xnox: how are the updates to user-log-dir coming along?
  <xnox> yes, should do those. fixes as agreed + docs.
  <jodh> xnox: ta :)
  <xnox> jodh: what if HOME="../lolcats/"
  <jodh> xnox: is that even legitimate?
  <xnox> jodh: i'm just pondering that XDG_CONFIG_HOME might end up ralative, after the fallback is used which expands $HOME. Hence I am pondering to move the check that path is absolute to a match later point.
  <xnox> such that returned conf-sources array is always legitimate. 
  <xnox> jodh: I can totally see puppet/chef/whatnot misconfigure passwd 
  <jodh> xnox: yeah - that sounds like the safest option.
  <xnox> jodh: does upstart handle alright if logdir is non-existant or NULL.
   * xnox adds a note to check that.
   * xnox ponders how far one can get a desktop session going with relative $HOME
  <xnox> right, needs more tests. I need to check on a few more urgent installer things now.
  <JanC> what would a relative path in $HOME be relative to?  âº
  <stgraber> your current working dir, whatever it's :)
  <JanC> how do you go "up" from '/' ?
  <JanC> well, I suppose it just stays there
  <stgraber> hehe, I didn't say relative $HOME would make sense, just said how it'd work ;) but yeah HOME="../../home/test" will be equal to HOME="/home/test" in upstart's case ;)
  <stgraber> right, .. on / points to . so you can't go any further but it won't fail either
  <JanC> I wonder if there is a rule about what applications should do with a relative $HOME...
  <stgraber> applications usually just append stuff to $HOME and let the libc do any kind of expansion
  #upstart 2013-01-19
  <xnox> JanC: yeah, I was pondering that if $PWD is null or '/' then all paths are absolute.
  <xnox> and the contrary case possible to launch additional user session init with whacky HOME env by hand.
  <JanC> well, with upstart running as a user, things would certainly start to get weird
  <xnox> yeah, previously we didn't use any of XDG_* nor HOME env variables =/ and now it's quickly becoming interesting.
   * xnox thinks that plymouth would be so much better off written using libnih
  #upstart 2014-01-13
  <SpamapS> slangasek: any idea on how to get upstart to print stuff on the console in sid?
  <gabrbedd> Hello! When upstart emits an event... is there a way to get that event broadcast over something like dbus?
  <gabrbedd> E.g. I have a system daemon that needs to be notified of upstart events as they happen.
  <gabrbedd> nevermind... I was using upstart 1.5.  I see that this "just works" in 1.10.
  <SpamapS> gabrbedd: :)
  <SpamapS> slangasek: uugggh.. startpar.c has mixed tabs and spaces
  <slangasek> SpamapS: which stuff are you looking for upstart to print on the console?
  <slangasek> if this is about upstart's log messages, I don't know; but somewhere along the line there was a behavior change, I think on the kernel side, that caused upstart's use of kmsg to not work the way it had previously
  <SpamapS> slangasek: init: starting foo.. 
  <SpamapS> slangasek: ahh yeah if kmsg is not working the same way that might do it
  <SpamapS> slangasek: I _do_ see some init: stuff in dmesg
  <SpamapS> slangasek: hey I'm reading startpar's upstart integration and wondering if there is a huge race condition
  <SpamapS> slangasek: Help me understand.. startpar is going to wait for started events from stuff in /etc/rc2.d ..
  <SpamapS> slangasek: but what if started already happened before startpar was listening
  <slangasek> SpamapS: startpar checks on startup for any already-running jobs; so as long as the job it's looking for ends in 'started' state, it's fine
  <SpamapS> slangasek: ok, so cloud-init won't work then
  <SpamapS> slangasek: it has tasks
  <SpamapS> slangasek: that scheme wont' work for tasks
  <slangasek> heh
  <SpamapS> slangasek: they're stop/waiting already
  <slangasek> yes, so the cloud-init upstart job needs to be changed to end in state 'started' with no running job
  <SpamapS> I believe that is what is going on in my VM
  <slangasek> s/job/process/
  <SpamapS> wha?
  <SpamapS> thats like.. breaking the basic way tasks work.
  <slangasek> why does it need to be a task?
  <slangasek> as opposed to being a non-task with no main process and a pre-start script?
  <SpamapS> because it blocks startup while udev-y things are happening.
  <SpamapS> basically cloud-init wants to stop everything until the network is up
  <slangasek> and why do you think a pre-start script doesn't do this just as well as a script?  AFAIK, the two models are interconvertible, unless you need to run the job multiple times
  <SpamapS> ok so this will work for cloud-init, I see that. However.. it seems like we could fix this some other way.
  <SpamapS> slangasek: is this documented already and I just skipped it?
  <slangasek> which part?
  <SpamapS> slangasek: the "startup tasks must be converted to jobs" part?
  <slangasek> yeah, that's not documented
  <slangasek> because the set of affected packages is rather small, and doesn't really include anything outside of the base system... except for cloud-init :P
  <SpamapS> slangasek: :)
  <SpamapS> slangasek: and can I assume that you're using the symlinks in /etc/rc#.d to allow enable/disable?
  <slangasek> SpamapS: update-rc.d in sid supports managing upstart .override files for enable/disable, in parallel with the rc?.d symlink changes
  <slangasek> (upstart is certainly not going to look at the symlinks when deciding whether to start or stop a job)
  <SpamapS> oh ok, so would another possibility be to remove the symlinks for special packages like cloud-init ?
  <slangasek> you could do that locally, yeah
  <SpamapS> ok, I did that and cloud-init didn't start
  <slangasek> doing it in the distro doesn't help, since it breaks compatibility with sysvinit, which someone decided was worthwhile when porting to Debian :P
  <slangasek> hmm
  <SpamapS> so I was thinking startpar was stopping it or something
  <slangasek> nope
  <SpamapS> that observation is only about 4 minutes old though, so do ignore for now
  <SpamapS> slangasek: I'm also wondering why I'm not hitting some kind of timeout ...
  <slangasek> possibly because cloud-init sticks itself in places that block the timeout handling?
   * slangasek doesn't really know
  <SpamapS> slangasek: so the timeouts apply to waiting for the upstart jobs, right?
  <slangasek> which timeouts?
  <SpamapS> oh hm.. startpar's timeouts are about flushing buffers
  <SpamapS> n/m
  <SpamapS> slangasek: I saw -t ## and thought it was "stop waiting for it after ## seconds"
  <SpamapS> hm just changing all the tasks to pre-starts hangs boot for me :(
  <SpamapS> ah and anything that uses the stopped events of these tasks now has to use the started event... thats why ti hangs. :-P
  <SpamapS> doh, and have to add stop on's
  <SpamapS> slangasek: ok sorry to gab your ear off. If a job fails to start.. it will be stop/waiting .. but startpar will wait for it forever.... ideas?
  <slangasek> hmm
  <slangasek> isn't that the same thing startpar does with an init script that fails?
  <SpamapS> I dont know
  <slangasek> I'm pretty sure it is
  <SpamapS> I thought it would mark it as FAIL
  <slangasek> oh
  <SpamapS> and still finish the boot
  <slangasek> yeah, you could be right
  <slangasek> in which case, we would need to extend the startpar bridge to handle this case
  <slangasek> I'm not too enthusiastic about this; the startpar bridge was always intended to be a short-term transitional solution
  <SpamapS> You should get the stopped RESULT=# event.. but you might have missed it. :-P
  <SpamapS> slangasek: Understood. I'm happy to help. This is a side project of mine at the moment. :)
  <slangasek> we probably are getting the stopped RESULT=# event, but we aren't doing anything meaningful with the $RESULT
  <SpamapS> slangasek: so this particular job is start on (filesystem and started rsyslog) ..
  <SpamapS> slangasek: and it fails in < 1s
  <SpamapS> slangasek: so I'm guessing startpar is nearly always going to miss that
  <SpamapS> unless they're queued up or something
  <slangasek> which they aren't, I'm afraid
  <slangasek> (why is it 'start on filesystem and started rsyslog' instead of 'start on started rsyslog', given that rsyslog starts on filesystem?)
  <SpamapS> slangasek: cribbed from ubuntu I'm sure
  <SpamapS> it should probably just be start on started rsyslog
  <SpamapS> but even then.. :-P
  <slangasek> yep
  <SpamapS> this is cloud-config
  <SpamapS> it could probably just be 'start on stopped rc RUNLEVEL=[2345]' in Ubuntu..
  <SpamapS> but with the current scheme, nothing can be 'start on stopped rc RUNLEVEL=[2345]' because rc is waiting for it to start. :-P
  <SpamapS> anyway I think I'm in the weeds..
  <SpamapS> slangasek: what is your longer term plan?
  <slangasek> SpamapS: longer term plan is to not need a startpar bridge because everything is natively upstart
  <SpamapS> slangasek: part of what I'm doing is keeping a project that wants to use Debian from using systemd or generating a ton of new sysvinit scripts.. so just help me get out in front of them.. it doesn't have to be perfect today. :)
  <slangasek> or because Debian adopts systemd instead, one of the two :P
  <SpamapS> ok
  <SpamapS> so this resolves when the war is over. wonderful. ;)
  <SpamapS> doh
  <SpamapS> rsyslog isn't installed on my vm
  <SpamapS> wait no it is..
  <SpamapS> but it has no upstart job
  <SpamapS> which explains a lot ;)
  <SpamapS> slangasek: ok so for my purposes, just removing the symlinks in /etc/rc2.d is the simplest solution
  <SpamapS> slangasek: cloud-init is also pretty borken and will basically never work as-is but I'll submit patches. Thanks for the feedback.
  <slangasek> ah yes, rsyslog isn't upstartified yet, is it... I've not gotten around to submitting the patches since the Debian maintainer is one of the systemd maintainers, heh
  <SpamapS> slangasek: doh
  <SpamapS> slangasek: in a perfect world that wouldn't be problematic. :(
  <slangasek> SpamapS: so, we could extend this to let init scripts signal back to upstart as well by synthesizing 'start' events; this has been buried on my TODO list for a while
  <slangasek> SpamapS: but that can be done as a hook into lsb init functions
  <SpamapS> slangasek: yeah I always thought that would have been nice even in Ubuntu.
  <slangasek> SpamapS: it's < 20 lines of shell code, if you want to JFDI :)
  <SpamapS> slangasek: no, I don't think cloud-config actually needs rsyslog for one thing.
  <SpamapS> slangasek: also I've always discouraged that kind of boot ordering as crackful. Services that aren't _boot_ related should just all boot at runlevel 2.
  <SpamapS> cloud-config really can just start at runlevel 2.
  <SpamapS> slangasek: I'm reporting this bug against cloud-init and it is unfortunate.. I'm basically going to force an Ubuntu delta because of startpar. Are you sure there's no way for cloud-init to just say "don't put my symlinks in /etc/rc#.d as long as upstart is the intended init" ?
  <slangasek> SpamapS: there definitely isn't, because the init system can be changed at runtime, post-install
  <SpamapS> I fail to see how that doesn't result in a bootable system.
  <slangasek> ?
  <SpamapS> Triggers would be needed actually.
  <SpamapS> You'd need a trigger that removes the symlinks if upstart is the init, and adds them back in if sysvinit is in place.
  <SpamapS> ah delta management
  <SpamapS> slangasek: is there some kind of CTTE action coming soon on this?
  <slangasek> right... and those triggers don't exist, the current model is that the filesystem should have everything in place to boot under any init
  <slangasek> SpamapS: probably going to vote this month, if all the members have a chance to finish their investigation
  <SpamapS> slangasek: I get that model. Another option is to have a latch job keeps track of tasks that have started.
  <slangasek> anyway, I think making init scripts emit start/stop events is a good thing in and of itself
  <SpamapS> yeah I do too
  <slangasek> so if I can't goad you into JFDI, maybe I should ;)
  <SpamapS> just don't have much more time to put into my little side project :)
  <SpamapS> slangasek: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735204 reported against cloud-init, FYI
  <slangasek> cheers
  <SpamapS> slangasek: note that I am pondering a single "start on started" job that keeps track of what has started in /run
  <SpamapS> slangasek: startpar could check that after setting up the event listening.. 
  <slangasek> I'd suggest making it part of the existing startpar bridge job... trying to have two separate jobs that 'start on started' is a great way to get an infinite loop, jodh found this out once :)
  <SpamapS> Oh I didn't look at that
  <SpamapS> but... right.. I never thoguht of that!
  <SpamapS> you almost have to have a special type of start on for htat
  <SpamapS> for that
  #upstart 2014-01-14
  <kaie> hello. Could you please help to clarify a comment on this page? http://upstart.ubuntu.com/wiki/Debugging -- nearly 7 years ago someone had asked for clarification -- and I'm also not understanding it today :)
  <kaie> question is: How do you request dumping of upstart events to a file on boot?
  <kaie> That page says:     echo "Debug Message" >> /tmp/upstart
  <kaie> That seems confusing. How does one trigger upstart to write to that file (or a different file) on boot?
  <kaie> I want to see which events are generated and processed on boot, and in which order
  <kaie> I already enabled it with --verbose but that's not sufficient, because it's goes away once startup finishes. I want that output written to a file.
  <kaie> ok. I don't know which of both fixed it. But I've added both "--verbose --debug" to the kernel command line and I was able to find the events in "dmesg" output
  <kaimast> hey all. are there any tests for extras? I try to add ipv6 support to the socket bridge but I cannot find any tests for it...
  <kaimast> would be nice if somebody could point me to the tests for any of the bridges so I don't have to start from scratch
  #upstart 2014-01-15
  <Madkinder> Hi. Is there any way I can reliably tell that a service is started with upstart?
  <Madkinder> from what I see upstart reports that it managed to start the service regardless of success
  <kaimast> Madkinder: afaik the service tells upstart that is has started successfully
  <kaimast> there are different ways to do this. see the "expect" flag in the cookbook
  <Madkinder> take a look: http://pastebin.com/ZNhwKTVs
  <Madkinder> this starts like a charm
  <kaimast> maybe because of the respawn flag?
  <jodh> Madkinder: Upstart will report that it successfully started the job when you "start" it, but "status <job>" will show you it is not (no longer) running.
  <Madkinder> jodh: that's the problem I'd like to fix
  <jodh> Madkinder: look at 'post-start' in init(5). I hope your service isn't as flaky as /bin/false though :)
  <Madkinder> jodh: you mean I should check whether my process started manually and emit a failure event or something like that, right?
  <jodh> Madkinder: no, I mean that if your job is really likely to fail at startup, you should use pre-start or post-start to handle that scenario. Generally, pre-start would setup the required environment. If you make the pre-start fail, the job will fail to start and "start <job>" will indicate that clearly.
  <Madkinder> unfortunately not all the services have a way to check the environment
  <Madkinder> for example, nginx and apache to with their -t flag, but they are rather an exception then a rule :(
  <Madkinder> I'm trying to configure my servers with configuration management tools (salt/ansible). The problem is that they both report that a service is started and running successfully while it might not be true.
  <Madkinder> most of the services with ancient sysvinit scripts work like a charm and report start failures, most upstart ones do not :(
  <methods> anyone know what the proper `start on` target is for networking ?
  <methods> I've tried just `networking` but doesn't seem to startup
  #upstart 2014-01-16
  <jbalonso1> Anyone here know how to increase the available filehandles for upstart itself?
  <jbalonso1> (I'm running on Ubuntu Raring)
  <jbalonso1> I have a great number of jobs I'm trying to manage with upstart, and I've found that upstart is losing file handles to (rather useful) log files. When init runs out, /sbin/init spins at 100% and is unresponsive.
  <jackhill> Hi, I have a service that I am trying to write a configuration for.
  <jackhill> However, it doesn't behave correctly if I use expect fork or expect daemon. The PID reported by upstart is different than what I observer the service to be running as in ps.
  <jackhill> Also, a symptom of this is that I can't get upstart to stop the service.
  <jackhill> It works "correctly" if I tell the service to run in the foreground and omit the expect directive.
  <jackhill> My question is: is there a tool see if a service forks or double forks or does something else weird?
  <jackhill> Oh, it seems that, occording to the cookbook, there is no ill effect to just running the service in the foreground, so I'll just do that. :)
  <dylukes> Hey guys, I'm in a bit of a pickle.
  <dylukes> I have an upstart conf running `exec gunicorn...` inside a script stanza
  <dylukes> and a bunch of env variables declared outside
  <dylukes> I want those variables to be visible inside the exec. Is there any way to do this? Alternatively I can have the same variables in a .env file, but I can't figure out how to exec that file and have those visible to the exec'd gunicorn task
  <dylukes> hm, now they seem to work
  <dylukes> ah, no they aren't :p
  <jbalonso1> dylukes: Did you export your env variables prior to the exec?
  #upstart 2014-01-17
  <Woosta> I have an upstart script with an 'exec' in it. Should I be expecting "ap_monitor start" to daemonise or background the exec'd command? 
  <Woosta> Script here if anyone wakes up: http://paste.linuxassist.net/view/1ab2fefc
  <ritz|m7> Hi, system hangs on boot with upstart on trusty after installing SELinux
  <ritz|m7> how do I debug this
  <ritz|m7> Using --verbose option doors not yield any valuable detail
  <ritz|m7> Recovery option works fine
  <ritz|m7> Last message seen is "stopping mount network filesystem"
  <ritz|m7> Nevermind, fixed this
  <ritz|m7> My update was screwed up, upstart was crashing on restart
  #upstart 2014-01-18
  <gabrbedd> Is it possible to do something like `start on running foo' ?
  <gabrbedd> Specifically... the normal logic would be something like `start on started A and started B'
  <gabrbedd> But to handle restart I would also like to support `start on started A and running B' as well
  #upstart 2015-01-13
  <renan_> Would `start on started beanstalkd` work for a upstart script, given that beanstalkd is using SysV?
  #upstart 2015-01-14
  <pilva> hey, how can I run 2 gunicorn projects with upstart?
  <pilva> hey, how can I run 2 gunicorn projects with upstart?
  #upstart 2015-01-16
  <hydrajump> hi why can't I get upstart to work with `start on net-device-up IFACE=eth0` ubuntu 14.04?   
  <hydrajump> I've tried with INTERFACE=eth0 but I can't get even a simple `echo "test" > /tmp/test` 
  <hydrajump> I want to do something when eth0 is up and another upstart job when eth0 is down, but if I can't get echo to work with those events there's little point in trying to do anything else :(
  <hydrajump> On the contrary I have other upstart jobs using `start on net-device-removed INTERFACE=tun0
  <hydrajump> which work fine
  <hydrajump> must be some bug with upstart. if I do `start on net-device-up IFACE!=lo` it works fine everytime
  #upstart 2015-01-17
  <steven__> exit
  #upstart 2016-01-19
  <xevious> Is there a way to either ask upstart if it's done booting or receive a notification when it's done booting? By "done booting", I mean when all the services that are configured to start when the system is booted have been launched.
  #upstart 2016-01-20
  <xevious> Is there a way to either ask upstart if it's done booting or receive a notification when it's done booting? By "done booting", I mean when all the services that are configured to start when the system is booted have been launched.
  <topi`> if I have set up a .conf to start only after job X has been started ("start on started X") then it actually gets triggered when job X has launched the main task - NOT e.g. after post-script has been done
  <topi`> this is a problem, since the task X seems to take 1-2 sec to do its stuff (mount a filesystem, actually) and anything that depends on this mount, fails
  <topi`> I tried to put a "sleep 2" into a post-script, but it changed nothing
  <topi`> is there a way to specify "start on finished-post-running X" for the job that needs that filesystem mount? (there is a chdir directive to that mount)
  <JanC> topi`: "start on stopped X" ?
  #upstart 2019-01-15
  <emilsp> I know that I can depend on a service parent_serv with "start on started parent_serv" - but is it possible to make this dependency optional? i.e. only depend on parent_serv if it exists?
  #upstart 2019-01-17
  <hallyn> emilsp: well, i guess define 'exists'?  you could have a job check for it existing and ifre off "no_parent_serv" event if not, and then start on started parent_serv or started no_parent_serv" ?
  <emilsp> hallyn: that's a solution :) I'll contemplate that. Thank you very much!
  <hallyn> cool, np
  