#upstart 2007-07-11
<shirish> guys how do I know if I'm running upstart or running sysvinit (on ubuntu 7.10) and are there GUI-based tools for it?
<shirish> like bum
#upstart 2007-07-12
<ion_> http://heh.fi/tmp/kaukajarvi (panorama)
<sadleder> hi Keybuk, is there any expected release for upstart and related jobs for Ubuntu gutsy?
#upstart 2007-07-13
<asdaf> hi all, it there a way to change the kill timeout for a specific job?
<Keybuk> asdaf: "kill timeout SECONDS"
<wasabi> i shall be in portland
<asdaf> Keybuk, thanks
<wasabi> yay for me
#upstart 2007-07-14
<ion_> http://lolcode-dot-net.googlecode.com/svn/trunk/lolc/fulltest.lol
#upstart 2009-07-06
<hoban> hello
<sadmac2> hello
<mbiebl> Keybuk: how can I tag a bug as wishlist in launchpad?
<Keybuk> set the Importance to Wishlist
<Keybuk> I think you can only do it once filed
<hoban> Is there official documentation for Upstart anywhere? I'm looking for something that explains the similarities and differences between SysV init and Upstart, but all articles I find link to this unofficial page: http://www.linux.com/archive/feature/125977
<mbiebl> Keybuk: I can't change the importance myself
<mbiebl> "Changeable only by a project maintainer..."
<Keybuk> ah
<Keybuk> silly launchpad
<Keybuk> maintainer? not driver or release manager?
<Keybuk> *puzzled*
<sadmac2> Keybuk: letting just anyone make wishes only leads to disappointment
<mbiebl> The complete message is: "Changeable only by a project maintainer or bug supervisor"
<Keybuk> yeah, was thinking I could create a team for clueful people
<sadmac2> sigclueful?
<Keybuk> "bug supervisor" ?
 * Keybuk doesn't see that
<Keybuk> I see "Maintainer", "Driver" and "Release manager"
<mbiebl> It's in a tooltip
<mbiebl> anyway, I've seen that you already changed it ;-)
<Keybuk> mbiebl: if you go to https://bugs.launchpad.net/upstart/+filebug-advanced
<Keybuk> do you see an "Extra options" below the big box
<Keybuk> and if you expose them, do you see Status/Importance now?
<mbiebl> Keybuk: yeah, now I'm able to change Status/Importance
<mbiebl> thanks
<Keybuk> ok, cool
<Keybuk> you should be able to target bugs and stuff too
<Keybuk> makes sense since you're the Debian maintainer
<Keybuk> sadmac2, plautrba: you should be able to as well
<sadmac2> Keybuk: not in launchpad atm, but just got an email saying I was added to upstart-devel
#upstart 2009-07-08
<Keybuk> mbiebl: of course, I keep forgetting when talking to Debian, that they're not actually programmers
<mbiebl> w.r.t to startpar, you say?
<mbiebl> maybe I'm just missing the context :-)
<sadmac2> Keybuk: this weekend once I finish the tests for the state transfer patch, I'm going to try making 0.6 queue start/stop calls along with events
<Keybuk> sadmac2: shiny
<sadmac2> Keybuk: I try
<sadmac2> Md: what is Ø­ÙÙÙØ§ÙØªÙ ÙÙÙÙØªÙÙØ¦Ø© Ø¨ÙØ£ÙÙÙÙÙÙÙÙÙØ³ÙÙ
<Keybuk> wow
<Keybuk> "make all" works in trunk for the first time in ages ;)
<sadmac2> whee
<PovAddict> you think that's rare? maybe you need to set up a buildbot
<Keybuk> PovAddict: I'm not sure how that would help, other than flagging that it doesn't actually build
<mbiebl> \o/
<sadmac2>  |
<sadmac2> / \
<mbiebl> nice
<sadmac2> mbiebl: why are we celebrating?
<mbiebl> [21:05:27] <Keybuk> "make all" works in trunk for the first time in ages ;)
<sadmac2> mbiebl: oh
<mbiebl> Keybuk: does it only compile or actually boot ;-)
<Keybuk> mbiebl: I haven't tested _that_ :)
<Keybuk> I was being distracted by vim syntax highlight
<mbiebl> oh
<Keybuk> which doesn't work for me *cry*
<mbiebl> are you using /etc/init/*.conf ?
<Keybuk> I changed that bit
<Keybuk> if I have a file loaded, how do I force vim to use upstart syntax for it
<sadmac2> Keybuk: :source /path/to/upstart.vim methinks
<mbiebl> set filetype=upstart
<sadmac2> Keybuk: you're an emacs'er typically, aren't you?
<Keybuk> yeah
<sadmac2> Keybuk: ^^mbiebl has it right
<Keybuk> mbiebl: I did that, and it turned off all the syntax highlighting ;)
<mbiebl> Where did you install the upstart.syntax file into?
<Keybuk> oh, I see
<Keybuk> I'm an idiot
<Keybuk> you called the file syntax_upstart.vim ;)
<Keybuk> it needs to be upstart.vim in the syntax sub-directory
<mbiebl> oh, yes
<Keybuk> neat
<mbiebl> I thought I had added that to the bug report
<Keybuk> I probably didn't read it properly ;)
<mbiebl> It needs a lot of polishing, but I wanted to wait with that, until the syntax format for 0.6 is finished.
<mbiebl> It's actually a nice way to document all the keywords etc ;-)
<mbiebl> time to run make: real	0m45.070s
<mbiebl> time to run make check: real	10m35.532s
<mbiebl> on my crappy laptop, i.e.
<Keybuk> that's not bad
<Keybuk> it passed then? :)
<mbiebl> It did, yes
 * sadmac2 wonders if make check is -j safe
<Keybuk> sadmac2: don't think so
<sadmac2> Keybuk: I'd imagine the dbus stuff would get hairy
<Keybuk> though automake may not even allow that
<Keybuk> it might build them in parallel but run them in series
<Keybuk> indeed, that's exactly what it does ;)
<Keybuk> so it's "safe" in the sense that it's ignored
<sadmac2> Keybuk: I think in the future we shouldn't have dates in the code names. It confuses me.
<sadmac2> I keep thinking its some other sort of information
<Keybuk> heh
<Keybuk> but it was the release date! :)
<sadmac2> Keybuk: why were you John Masters?
<sadmac2> (for who the Sega Master System is named btw. Fun fact)
<Keybuk> do you not listen to the lkml summary podcast?
<sadmac2> Keybuk: no. I subscribe to the list... I'm a little behind :P
<Keybuk> pick one at random and listen for a few seconds
<Keybuk> then you'll understand
<sadmac2> cool
<sadmac2> and now I go home
<Keybuk> well, holy crap, it booted
<mbiebl> Keybuk: can confirm
<mbiebl> running it too ;-)
<Keybuk> trunk?
<mbiebl> yep
<Keybuk> are you using the shiny new default jobs? :)
<mbiebl> I do
<mbiebl> runlevel handling is a bit broken
<Keybuk> oh, what did you find?
<mbiebl> when booted, runlevel should be "N 2"
<mbiebl> not "S 2"
<Keybuk> I think it should be S 2, no?
<Keybuk> you've come from single-user mode into runlevel 2
<mbiebl> no, don't think so
<Keybuk> I know 0.3 said N 2
<Keybuk> but I always thought that was a bug ;)
<PovAddict> personally I wish Ubuntu packages used upstart events instead of init.d scripts :)
<mbiebl> it's not like you stopped after rcS and then switched runlevel manually to 2
<Keybuk> hmm maybe
<mbiebl> otherwise, you have the problem that when you enter runlevel 2
<Keybuk> just change the env RUNLEVEL= in rc-sysinit.conf
<mbiebl> all stop links are executed
<Keybuk> should be just
<Keybuk> env RUNLEVEL=
<Keybuk> ohhh
<Keybuk> maybe it wasn't a bug then
<mbiebl> e.g. I have apache and mysql installed, but disabled
<mbiebl> and when entering runlevel two, those two are stopped first
<mbiebl> before the actual boot continues
<Keybuk> ok
<Keybuk> I changed that
<Keybuk> now when I boot into single-user mode first, it's
<Keybuk> N S
<Keybuk> (it was S S before, which I agree is a weeeee bit odd)
<ion> ke230434  * sadmac2 wonders if make check is -j safe
<mbiebl> N S for single user mode is correct I think
<ion> .NOTPARALLEL: or something equivalent should be used if itâs not.
<mbiebl> But I think, the rcS stage during boot shouldn't be considered "single user mode"
<ion> (Now that i read further, âsomething equivalentâ is done. :-P)
<Keybuk> yeah, I mean with "single"
<Keybuk> then when I go from single to multi-user (^D) I get S 2
<mbiebl> that looks about right too
<Keybuk> let's try booting straight into multi-user
<Keybuk> now it's N 2
<Keybuk> and the system boot record was still written \o/
<mbiebl> cool
<mbiebl> what I also find a bit weird, is that the jobs are actually named job.conf
<Keybuk> sure
<mbiebl> e.g. in status etc
<mbiebl> hm
<Keybuk> they are?
<Keybuk> are you sure you installed the 0.6 util directory?
<mbiebl> rc.conf stop/waiting
<Keybuk> actually, that shouldn't make a difference
<Keybuk> I see
<mbiebl> etc
<Keybuk> rc stop/waiting
<Keybuk> which revno are you at? (upstart & libnih)
<Keybuk> 1160 / 966 here
<mbiebl> 1155/963
<mbiebl> I guess it's time for an update then ;-)
<Keybuk> oh, yeah
<Keybuk> you're missing the revs that dealt with the .conf issue
<Keybuk> 1161 has the rc-sysinit fix
<mbiebl> compiling ...
<ion> keybuk: How are you planning to handle mounting with 0.6 in karmic?
<ion> I wish i had managed to write the mount daemon, but i havenât.
<Keybuk> by using a mount daemon :)
<ion> :-)
<ion> Any code yet?
<Keybuk> no, that's my next thing to do really
<mbiebl> Keybuk: noticed one more minor issue
<mbiebl> when I use startpar, switching to runlevel 6/0 will also stop the service
<mbiebl> which were already disabled in 2
<mbiebl> for debugging, I added a pre-start script echo $(runlevel) end script to rc.conf
<mbiebl> then this problem magically goes away
<Keybuk> odd, why does it do that?
<Keybuk> isn't echo $(runlevel) a little superfluous? :p
<Keybuk> runlevel would be enough there <g
<mbiebl> I actually have a simple runlevel call ;-)
<mbiebl> just wanted to make it clear, that it's debugging output
<mbiebl> /etc/init.d/rc uses the $runlevel and $prevlevel env variables
<mbiebl> and passes that to startpar
<Keybuk> it sets those from $RUNLEVEL and $PREVLEVEL though right?
<mbiebl> checking...
<mbiebl> runlevel=$RUNLEVEL
<Keybuk> that should be set
<mbiebl> previous=$PREVLEVEL
<mbiebl> [ "$previous" = "" ] && previous=N
<Keybuk> weird
<Keybuk> set -x that script? :p
<mbiebl> weird is, that simply calling runlevel magically "fixes" it
<Keybuk> that is weird
<Keybuk> runlevel doesn't do anything ;)
<mbiebl> I added a runlevel to /etc/init.d/rc
<mbiebl> (when runlevel and previous are set)
<mbiebl> and on reboot it shows N 6 with startpar
<mbiebl> but of course it should show 2 6
<Keybuk> what does it show without startpar?
<mbiebl> fwiw I also get an assertion error from this runlevel call, when it's called during rcS
<mbiebl> without startpar it shows 2 6
<mbiebl> weird thing is, startpar is called much later in /etc/init.d/rc
<Keybuk> do you have a core for that?
<Keybuk> or at least the assertion message?
<mbiebl> Keybuk: I'll need to reboot for that and, wait a sec
<mbiebl> runlevel:error.c:319 Assertion failed in nih_error_get: context_stack != NULL
<mbiebl> Aborted
<Keybuk> got a core for that?
#upstart 2009-07-09
<Keybuk> how are you reproducing?
<mbiebl> unfortunately, I don't have a core file
<mbiebl> reproducing is easy
<mbiebl> open /etc/init.d/rc
<mbiebl> and add "runlevel" after line 72
<mbiebl> it also seems, I was on the wrong track with startpar
<Keybuk> Debian or Ubuntu ?
<mbiebl> Ubuntu
<Keybuk> after "export runlevel previous"?
<mbiebl> yeah
<mbiebl> who is responsible for setting the env variables PREVLEVEL and RUNLEVEL in rc.conf?
<Keybuk> nobody
<Keybuk> telinit sets them in the runlevel event
<mbiebl> does telinit read /var/run/utmp to get that information?
<Keybuk> yes
<Keybuk> and its environment
<mbiebl> I changed rc.conf a little
<mbiebl> script
<mbiebl> 	echo "RUNLEVEL: $RUNLEVEL"
<mbiebl> 	echo "PREVLEVEL: $PREVLEVEL"
<mbiebl> 	exec /etc/init.d/rc $RUNLEVEL
<mbiebl> end script
<Keybuk> hmm, runlevel just works for me there
<mbiebl> sometimes PREVLEVEL is just empty on reboot
<Keybuk> can't you do
<Keybuk> ulimit -c unlimited
<mbiebl> sometimes it's 2
<Keybuk> runlevel
<Keybuk> ?
<mbiebl> looks like a race somewhere
<mbiebl> ulimit -c unlimited in /etc/init.d/rc ?
<Keybuk> before calling runlevel
<Keybuk> to get a coredump
<Keybuk> oh, I know
<Keybuk> it's that env RUNLEVEL=
<Keybuk> should probably be =N ? :)
<mbiebl> the core files should be in /?
<Keybuk> aye
<mbiebl> hm, there isn't any
<mbiebl> even with ulimit
<Keybuk> bah
<Keybuk> if you change it to =N does it work?
<mbiebl> rc-sysinit.conf?
<Keybuk> yeah
<Keybuk> or try 1165
<Keybuk> more in 1166
<mbiebl> Ok, if I set RUNLEVEL=N
<mbiebl> I no longer get any asserts
<mbiebl> runlevel then reports: N N
<Keybuk> after boot?
<mbiebl> immediately after the startup event
<Keybuk> or for rcS?
<Keybuk> ok
<mbiebl> Not sure, if the legacy runlevel reported just "N" in that case
<mbiebl> anyway, I guess runlevel should be more fault tolerant, when RUNLEVEL is not set
<mbiebl> regarding the reboot problem
<mbiebl> What I figured out so far is this:
<Keybuk> I think I fixed that now
<mbiebl> If I just hit strg+alt+del, I get 2 6
<mbiebl> When I login and type reboot, I get N 6
<Keybuk> that implies your /var/run/utmp is mucked up?
<mbiebl> reboot seems to break it,
<Keybuk> hah
<Keybuk> by writing a shutdown line
<Keybuk> and now I get the assert \o/
<Keybuk> try 1168
<mbiebl> so this should only happen if you *don't* use tmpfs for /var/run?
<Keybuk> no, this was just a bug
<Keybuk> reboot writes the shutdown time, which is a special runlevel record
<Keybuk> that overwrites the runlevel record in utmp
<mbiebl> I mean the assert in runlevel on boot?
<Keybuk> but it did that before calling /sbin/shutdown, which meant it couldn't get the runlevel ;)
<Keybuk> that was just bad sanity checking
<mbiebl> Keybuk: looks good now
<mbiebl> no more asserts, no more problems on reboot \o/
<mbiebl> btw., I asked on #vim if there is a standard way of installing vim addons
<mbiebl> apparently there isn't a straighforward procedure
<Keybuk> include it in the vim source ;)
<mbiebl> So best is probably, to just ship a README how to install it manually
<mbiebl> oh yeah, when the upstart syntax is frozen
<mbiebl> then this is probably the best idea
<Keybuk> I mean in Debian/Ubuntu
* Keybuk changed the topic of #upstart to: PLEASE TEST TRUNK! | Upstart 0.5.3 "Britain's Flag Carrier" | Upstart 0.3.11 "For Friday, June 19th 2009, I'm Jon Masters" | http://upstart.ubuntu.com/
<Keybuk> anyway bed
<sadmac> Keybuk: ah
<Keybuk> I shall release in the morning if there's no show-stoppers
<sadmac> Keybuk: caught you
<sadmac> :)
<sadmac> Keybuk: just filed the state transfer patch
<Keybuk> sadmac: yup, quickly!
<sadmac> Keybuk: look at it in the morning if you like :)
<Keybuk> cool
<Keybuk> will do
<mbiebl> Keybuk: make check no longer passes :-/
<mbiebl> fyi, I started packaging trunk: http://debs.michaelbiebl.de/upstart/
<mbiebl> in case you are interested
<Keybuk> mbiebl: which revno did make check fail on?
<ion> keybuk: Does trunk handle the Ubuntu jobs as-is â that is, can i just install to /sbin/init.temp and test with init=/sbin/init.temp?
<Keybuk> ion: no, they're in different paths and slightly different format
<Keybuk> I decided it was better to make it easy for 0.10 to be backwards compatible with 0.6
<ion> Good :-)
<ion> % autoreconf -i
<ion> autopoint: *** cvs program not found
<ion> le sigh
<plautrba> sadmac: fyi, i've just finished rpm from todays trunk - http://plautrba.fedorapeople.org/upstart/
<ion> An Upstart build non-benchmark on a dualcore laptop: http://pastebin.com/mbb57e6b
<ion> keybuk: How about tagging the job files with a format version number? Enforce the file to begin with âupstart 0.6\nâ and parse the rest as usual perhaps. It would also make file(1)âs job easier, as well as editor syntax highlighter defintionsâ.
<Keybuk> I thought about it
<Keybuk> but I don't really like those kinds of things
<ion> http://heh.fi/tmp/vim-highlight-upstart-rcS.conf http://github.com/ion1/vim-highlight
<Keybuk> ion: is that using mbiebl's stuff?
<ion> I just copied contrib/vim/* to ~/.vim and ran vim-highlight -t upstart conf/rcS.conf foo.html.
<ion> Yeah, contrib/vim seems to be written by him. :-)
<ion> -t upstart wouldnât have been needed, had it been able to automatically recognize the file type. ;-)
<ion> virtualbox-ose-source doesnât seem to work with 2.6.31-2-generic-pae. Letâs not test Upstart in a VirtualBox VM then. Letâs see how ubuntu-vm-builder works.
<Keybuk> wow
<Keybuk> the test suite is much faster when compiled -O2 ;)
<Keybuk> make check  55.36s user 4.29s system 63% cpu 1:34.17 total
<mbiebl> ion: wanna help with polishing the vim syntax file?
<mbiebl> Keybuk: is the message_iter_abandon_... patch for dbus already in Ubuntu/karmic?
<Keybuk> yes
<mbiebl> was it accepted upstream?
<Keybuk> not yet
<Keybuk> I need to write a test case for it
<mbiebl> Keybuk: what about a small configure check and a ifdef?
<Keybuk> mbiebl: #if YES_I_WANT_TO_ASSERT_ON_ENOMEM ? :)
<mbiebl> something like that, yes :-)
<mbiebl> only as long as the patch is not in the official dbus upstream
<mbiebl> In which can you can bump the pkg-config check
<Keybuk> I think it's better to subversively force everyone to apply that patch
<mbiebl> then ./configure should simply abort
<mbiebl> which would be trivial to do
<mbiebl> together with a helpful error message, pointing to the fd.o bug report
<mbiebl> want a patch :-)
<Keybuk> actually, that is a good point
<Keybuk> configure should check for that function and abort
<Keybuk> yes please
<mbiebl> ok, will do
<mbiebl> <Keybuk> mbiebl: which revno did make check fail on?
<mbiebl> 1172
<mbiebl> http://paste.debian.net/41435/
<Keybuk> hhe
<Keybuk> isn't that because upstart is already running?
<plautrba> Keybuk: my "make check" fail - http://pastebin.dqd.cz/939
<plautrba> but i have to leave now, bb at monday
<Keybuk> plautrba: do yoiu not have -lrt in ../nih/libnih.la ?
<plautrba> no
<Keybuk> that's weird
<Keybuk> don't support you mind tarring up your build directory for me so I can examine it?
<mbiebl> Keybuk: could be
<mbiebl> when make distcheck passed yesterday
<mbiebl> I was still running 0.3.11
<plautrba> Keybuk: http://plautrba.fedorapeople.org/upstart/upstart-0.6.0-1172-build.tar.bz2
<plautrba> Keybuk: it's build from http://plautrba.fedorapeople.org/upstart/upstart-0.6.0-0.1172.fc11.src.rpm
<Keybuk> ok
<Keybuk> plautrba: what revno of libnih?
<Keybuk> ah, 963
<Keybuk> -r968 fixed that
<Keybuk> make check  61.55s user 4.41s system 65% cpu 1:40.97 total
<Keybuk> (with -Os)
<Keybuk> that means -O2 was slightly quicker than -Os
<ion> mbiebl: If i ever get anything done, iâll post a patch. :-)
<mbiebl> argh, manpage-de ships init.8
<mbiebl> so I alway have to run LANG=C to get the correct man page
<Keybuk> mbiebl: did you have that configure.ac patch to hand?
<mbiebl> yeah, could you quickly point me to the fd.o bug again?
<mbiebl> bugzilla so sucks
<mbiebl> found (via google) ;-)
<mbiebl> http://paste.debian.net/41446/
<mbiebl> wait a sec
<mbiebl> We don't want -ldbus-1 added to LIBS
<mbiebl> this one's better http://paste.debian.net/41447/
<Keybuk> I came up with a better way ;)
<Keybuk> I bumped the D-Bus GIT version to 1.2.15 and just dep on that
<Keybuk> which gives us the timeout patches too
<mbiebl> Keybuk: but that makes it harder for distros which ship dbus+the patch
<Keybuk> mbiebl: D-Bus 1.2.16 will be out in NOW+$SOMETIME
<mbiebl> Is Collin on it?
<Keybuk> yup
<mbiebl> cool
<Keybuk> <walters> ok, i'll try to do one by tomorrow
<mbiebl> even better ;-)
<Keybuk> build test, check
<Keybuk> distcheck, check
<Keybuk> package built, check
 * Keybuk reboots
<ion> I wouldnât mind testing the package.
<ion> ...as long as your system doesnât fail to boot with it. :-P
<Keybuk> I'm just about to upload it :D
<ion> Ah, cool.
<Keybuk> sweet
<Keybuk> it booted
<ion> Thatâs always a nice bonus.
<mbiebl> Keybuk: so what is the make-check-fails-when-upstart-already-running about?
<Keybuk> mbiebl: not sure, it doesn't do it for me
<Keybuk> I figured I'll fix that in trunk quickly after the release when I figure it out :)
* Keybuk changed the topic of #upstart to: Upstart 0.6.0 "How appropriate, you fight like a cow" | Upstart 0.5.3 "Britain's Flag Carrier" | Upstart 0.3.11 "For Friday, June 19th 2009, I'm Jon Masters" | http://upstart.ubuntu.com/
<Keybuk> mbiebl: hmm
<Keybuk> you had a previously failing test case right?
<Keybuk> try pkill -f test_
<Keybuk> the test suite doesn't clean up in case of failure (since I want to be able to debug it usually)
<mbiebl> I don't think I have any running test_ processes
<Keybuk> kooky
<Keybuk> I shall investigate and fix
<sadmac2> Keybuk: I applaude your release codename
<ion> Indeed
<ion> keybuk: How much did you say the test suite takes to run? I built the Ubuntu package for 0.6.0 locally, and it didnât take very long. It did seem to run the test suite. Unfortunately, the build log doesnât seem to contain any timestamps.
<ion> Wait. What am i talking about? Iâve had the runtime of the previous command in zsh prompt for a while now. debuild -b -j3 of 0.6.0-1 took 491.5 seconds.
<sadmac2> ion: where's your underscore?
<ion> A bit more than 8 minutes, including the time it took to type my PGP password when debuild signed the package. :-P
<ion> sadmac2: Huh?
<sadmac2> ion: you've been ion_ forever
<ion> Ah. #elsewhere: 2009-06-24 00:25:50 < ion> Woot! I got the nick back. I registered it back in the 1800s and someone immediately complained, claiming he had been using the nick in Freenode before me. I was teh benevolent and gave it to him (i guess i got some good karma, since someone kindly gave the nick back to me in IRCnet, since i had been using it there long before him). It seems he hasnât been at Freenode for six months and the registration expired.
<sadmac2> pimp!
<ion> ii  upstart          0.6.0-1          event-based init daemon
<ion> Letâs reboot and see whether i come back.
<ion> Itâs alive!
<ion> keybuk: So, is something wrong with my system or your system (re: test suite runtime)? :-P
<mbiebl> Keybuk: when will the new daemon monitoring code land in trunk?
<sadmac2> notting: how do we feel about 0.6.0 in RHEL? are we going to try to swing it?
<sadmac2> plautrba: ^^
<notting> gah.
<sadmac2> gah?
<notting> "i would prefer not to deal with the headaches of a rushed migration at this particular exact point in time"
<sadmac2> notting: never heard that acronym...
<notting> not acronym. approximation of an unintelligible verbal noise
<sadmac2> notting: its very meaning-dense
<notting> (see also: 'meh', 'bleah', etc.)
 * sadmac2 should probably port rawhide this weekend
<sadmac2> I'll be at the beach, so nothing better to do :)
<mbiebl> Keybuk: is there an equivalent to the old "initctl events" in 0.6.0?
<sadmac2> mbiebl: last we discussed it it was removed by design choice
<mbiebl> Keybuk: so you merged the debian packages again?
#upstart 2009-07-10
<Keybuk> mbiebl: which debian packages?
<Keybuk> the speed difference between "initctl list" and "sudo initctl list" is kinda interesting
<mbiebl> Keybuk: the packages you uploaded to karmic
<Keybuk> mbiebl: of upstart?
<mbiebl> yeah
<Keybuk> I didn't look in the Debian package
<Keybuk> was there something I missed?
<mbiebl> Keybuk: for one, there was upstart-job already in their
<mbiebl> and you merged the debs into one
<mbiebl> (and some smaller stuff)
<Keybuk> oh, I didn't know you'd done the upstart-job thing yet
<Keybuk> I just stuck a quick-and-dirty shell script in there for now, until you did :)
<mbiebl> maybe we should communicate better then ;-)
<mbiebl> why the merge of the packages?
<mbiebl> imho keeping e.g. the tty job files and the core upstart package separat made sense
<Keybuk> the separation we had didn't make much sense
<Keybuk> it was kinda arbitrary
<Keybuk> ok, I'm confused ;)
<Keybuk> you were saying I merged the Debian packages
<Keybuk> did you mean that I merged the binary debs together
<Keybuk> or merged with the Debian package (compared to the Ubuntu one)
<mbiebl> I meant, merged the debs
<Keybuk> ahh
<Keybuk> right, yeah
<Keybuk> we talked about doing that in Ubuntu a while back
<Keybuk> since most things will ship their own upstart jobs, and we'll try and push them upstream
<Keybuk> even util-linux will ship the jobs for the gettys
<Keybuk> nothing would end up in those two packages
<mbiebl> so it would be much easier to just drop system-services when util-linux does that
<Keybuk> and with merging upstart-compat-sysv back into upstart (since shutdown, etc. are "native" now), they kinda all went away
<Keybuk> really?  doesn't make much difference surely?
<Keybuk> util-linux will ship /etc/init/getty.conf
<Keybuk> you don't have to follow that in Debian of course ;)
<Keybuk> that's up to you
<Keybuk> what did you mean about upstart-job btw?
<mbiebl> Keybuk: my point is not so much about the merge itself but having known beforehand what you are planning
<Keybuk> you were in the room at UDS when we talked about it ;)
<mbiebl> sorry, then I completely missed that part
<mbiebl> when was this discussed, the the binary packages will be merged?
<Keybuk> in the packaging policy session I think
<Keybuk> the room with the glass wall
<Keybuk> the getty bit specifically was in the karmic kms console one though
<mbiebl> I honestly can't remember that
<Keybuk> rationale:
<Keybuk> system-services, currently only contains getty
<Keybuk> we want to merge those into one instance job
<Keybuk> now we've discovered that we probably need to dynamically create ttys anyway
<Keybuk> so it all makes sense to move to util-linux
<Keybuk> (leaving that package empty)
<Keybuk> startup-tasks is already empty
<mbiebl> there is no point arguing about that ;-)
<Keybuk> things like running udev belong in udev, setting hostname belongs in util-linux, etc.
<Keybuk> upstart-compat-sysv, we discussed here ages ago that it didn't make sense to hang those tools out to dry
<mbiebl> arguing about startup-tasks, I mean 
<Keybuk> they got moved from compat/sysv to util in the main source package (pre 0.5 iirc)
<Keybuk> and now the default recommended jobs are shipped in the source package as well
<Keybuk> especially when upstart gains native lsb jobs, it becomes increasingly blurry
<Keybuk> having everything in one binary package makes the migration easier too
<Keybuk> the missing piece is something to migrate custom changes from /etc/event.d to /etc/init
<Keybuk> and clean up after
<Keybuk> if all the resulting files are in one package, that's easier :p
<sadmac2> Keybuk: slightly off topic: you said 0.10/1.0 will continue to support 0.6 job definitions, right?
<Keybuk> right
<sadmac2> ah. that'll make life easier.
<sadmac2> much as I'd love to delete all that code :)
<mbiebl> my preliminary packages on http://debs.michaelbiebl.de/upstart/
<Keybuk> the idea being that people should feel safe about updating to 0.6 now
<Keybuk> and using it as a stable release
<Keybuk> while 0.10 is a development release that they can experiment with without worrying
<mbiebl> had the maintainer scripts updated to support the conffile migration
<Keybuk> mbiebl: ah, I deliberately didn't do that because 0.3 and 0.6 job files aren't directly compatible
<mbiebl> Keybuk: hehe, I only migrated the ttyS
<Keybuk> you need to do more than just copy them
<mbiebl> for the same reason I on rm the old if unmodified
<Keybuk> what do you if modified?
<mbiebl> keep a copy
<Keybuk> in /etc/event.d ?
<mbiebl> yeah
<sadmac2> Keybuk: did we ever increase the strictness of the 0.6 job format? does having two start stanzas still just silently take the second one?
<Keybuk> sadmac2: yes
<sadmac2> Keybuk: yes to which question :P
<Keybuk> sadmac2: what you said is true; the last of all dup stanzas is used
<sadmac2> Keybuk: unfortunate, but not much to be done about it.
<mbiebl> Keybuk: regarding the merge: I guess you should also add Conflicts
<Keybuk> why unfortunate?
<Keybuk> mbiebl: already did that ;)
<mbiebl> oh, not in -1
<mbiebl> which I looked at
<sadmac2> Keybuk: it should at least give a warning. That behavior is almost certainly not reflecting what the user intended when they wrote the job definition.
<mbiebl> And why the Provides?
<Keybuk> sadmac2: it followed what most other configs do
<Keybuk> e.g.
<Keybuk>   SomeOption on
<Keybuk>   SomeOption off
<Keybuk>   SomeOption on
<sadmac2> Keybuk: if most other configs jumped off a bridge... :P
<Keybuk> sadmac2: I'd push you off ;)
<sadmac2> Keybuk: touche
<Keybuk> I'd give you a portal gun first
<sadmac2> Keybuk: potential release name: "Thank you for helping us help you help us all."
 * sadmac2 <3 GlaDoS
<mbiebl> Keybuk: about upstart-job
<mbiebl> imho it makes sense to map force-reload to restart
<mbiebl> I also strip away any leading SK?? from the basename
<mbiebl> so it can be started e.g. by /etc/rc2.d/S50cups
<mbiebl> Keybuk: Idea is, that packages can potentially start now to ship upstart job files
<mbiebl> without strictly having to got from bottom up
<mbiebl> e.g. cups could ship a job file today
<mbiebl> which then is not started by events
<mbiebl> but by sysv
<mbiebl> which imho is pretty neat, as we don't to strictly synchronize when to convert which packages
<sadmac2> Keybuk: did you look at the state transfer patch?
<mbiebl> Keybuk: I think you can drop the Provides from the Ubuntu package
<mbiebl> and I also think it doesn't make sense to ship the nih-dbus-binding tool man page
<Keybuk> mbiebl: we need those in Ubuntu the way that ubuntu-meta works
<mbiebl> how's that?
<Keybuk> ubuntu is installed by packages that depend on others
<Keybuk> ubuntu-minimal depends on those packages provided
<mbiebl> hm, doesn't the latest ubuntu-minimal not only depend on upstart?
<Keybuk> latest yes, but not when upgrading from jaunty to karmic when released
<Keybuk> the installed one will still depend on upstart-compat-sysv
<Keybuk> providing it makes upgrade ordering easier :)
<mbiebl> so update-manager will fall over if those provides are not there?
<Keybuk> no
<Keybuk> it'll just get pessimal ordering
<mbiebl> what's pessimal?
<mbiebl> ok, seems to be the opposite of optimal ;-)
<ion> keybuk: Iâm thinking of fixing some typos etc. in the 0.6.0 manpages. How are the lines wrapped? I donât seem to find a consistent maximum line width or equivalent.
#upstart 2009-07-11
<Keybuk> sadmac2: I was thinking "We do what we must because we can" :-)
<Keybuk> mbiebl: yeah, the script was literally just a hack - if you've got a better version please do open an LP bug and I'll replace it
<Keybuk> mbiebl: obviously the LP bug should be against the Ubuntu package ;)
<ion> keybuk: So...? :-)
<Keybuk> sadmac2: I haven't received the state transfer patch from you, I don't think - let me check
<Keybuk> ion: please do fix any errors you see in the manpages, or even rewrite bits if you like ;)  I literally just wrote them all in a morning after getting carried away editing RH's events(5) page
<Keybuk> ion: they're just wrapped in emacs at 80 columns I think - but obviously the wrapping goes awry when you edit the pages afterwards
<ion> Well, iâd use vimâs gq command to rewrap after any changes.
<Keybuk> that gets manpages wrong though, right?
<Keybuk> it tries to move the .B bits back onto the same line
<ion> some text, blah blah (cursor here)
<ion> more text, foobar
<ion> .B baz
<ion> 2gqgq rewraps the two lines, not touching the .B line. When there are so many lines itâs not easy to count them with a single skim, V switches to visual mode (âpaint linesâ mode), j extends the selected area downwards and gq finally rewraps it.
 * Keybuk remembers why he uses emacs ;)
<ion> 2gqq even
<ion> Emacs has built-in functionality to rewrap man pages properly?
<Keybuk> C-A-\
<ion> Neat
<Keybuk> well, rewrap anything really
<Keybuk> I'd still rather use anjuta though
<ion> But it didnât seem to wrap the Upstart manpages consistently.
<Keybuk> that's because I didn't use it :)
<Keybuk> I just typed stuff
<Keybuk> it wrapped as I went
<Keybuk> then I went back and editing things I typed
<Keybuk> but I didn't rewrap after
<Keybuk> I probably sometimes pressed enter manually to wrap too ;)
<ion> vim seems to support letting an external program or a vimscript function handle gq for certain filetypes. I wonder if one of the text formatters available from apt support manpages?
<Keybuk> no idea
<Keybuk> sadmac2: ah, I do - you added an "also affects 0.3" which sent it to the other mailbox
 * Keybuk fixes his mailer confi
<ion> Ha! One can tell par 'P=.' and it âprotectsâ lines starting with a dot. Iâll see if par handles manpages nicely otherwise.
<Keybuk> ion: the trick though is keeping them formatted ;)
<Keybuk> mbiebl: I fixed the test_control failure ;)
<Keybuk> it was a brain failure
<Keybuk> now I have a strange test case failure
<Keybuk> that only seems to affect my laptop
 * Keybuk wonders whether Upstart's test suite has uncovered a bug in the new fanotify() kernel stuff
<Keybuk> well, the kernel update solves the other inotify bug I'd noticed
<Keybuk> but not this one
<Keybuk> ok iz confirmed
<Keybuk> the test_conf failure is a kernel bug ;)
<ion> Does 0.6 already use the magic to follow forks?
<Keybuk> no, it just uses ptrace
<ion> Ok
<Keybuk> though since I binned the session leader crap, that actually appears to work
<Keybuk> well
<Keybuk> kinda
<ion> Have you already started working on the mount daemon? I wonder if iâd manage to contribute anything some day... An often-updated repository with a TODO list would be nice. :-)
<Keybuk> no, not yet
<Keybuk> I'll try and do that ;)
<Keybuk> hmm, processes get kinda stuck in ptrace
#upstart 2009-07-12
<Keybuk> oh, I see
<Keybuk> it looks like we get the STOP of the child before the FORK of the parent
<Keybuk> actually, that can't happen, we'd hit an assert
<Keybuk> oh, no, we wouldn't
<Keybuk> bah
<ion> -	DEFAULT_RUNLEVEL="$(sed -n -e "/^id:[0-9]*:initdefault:/{s/^id://;s/:.*//;p}" /etc/inittab || true)"
<ion> +	eval "$(sed -nre 's/^id:([0-9sS])[0-9sS]*:initdefault:.*/DEFAULT_RUNLEVEL="\1";/p' /etc/inittab || true)"
<ion> Didnât test that on a live system yet, though.
<Keybuk> what's the difference?
<ion> Originally, it would do DEFAULT_RUNLEVEL="" if inittab exists but id:... wasnât set. Also, if thereâs a broken inittab with multiple initdefault lines, or even multiple runlevels on a single line, DEFAULT_RUNLEVEL would get them all.
<Keybuk> oh
<Keybuk> well, sysvinit would have failed to boot then ;)
<Keybuk> yours would fail if inittab had a " in it ;)
<ion> Heh, true
<ion> Oh, wait. It wouldnât.
<Keybuk> and fail at "eval"
<Keybuk> rather than in the || true
<Keybuk> oh
<ion> The expression would print nothing if there was a line id:":initdefault:
<Keybuk> ok true
<ion> Oh, btw, set -e; eval "$(false)"; echo foo prints foo at least with dash, zsh and bash. Didnât bother to read what POSIX says. The getopt(1) documentation explicitly tells you to do temp="$(getopt ...)"; eval "$temp" so that getopt interacts with set -e as expected.
<ion> eval set -- "$temp" even
<rjbell4> Sorry to join and pounce, but I just had a question I was wondering about: is there any support in upstart for monitoring multiple child processes?  I've found "expect fork" and "expect daemon", which seem to monitor a single child or grandchild, but what if there are several child processes, and if any of them fail then I want to take action?
<ion> Whatâs wrong with joining and pouncing?
<ion> 0.10 should have better support for following child processes, but thatâs about as much as i know, Keybuk should be able to elaborate.
#upstart 2010-07-12
<k0sh> hi peeps, can somone explain to me how boot proces in ubuntu looks like, some sort of overview on which is started when?
<k0sh> i want to run a script before *all* other boot scripts will take place, but just after initrd, where should i plug it into ubuntu?
<mbiebl> k0sh: why would you want to do that?
<dude__> Hey, I am running upstart inside a VServer and want to debug it (It doesn't start any of Lucids upstart-scripts), and I think I've manage to start it with /sbin/init --debug as /Debugging says I should do. Will it only print to console now? And also, I tried using cp -a to copy a console-devices to the VServer but a cp -a /dev/console ~/ && echo ehlo > ~/console doesn't work =(
#upstart 2010-07-13
<matt1s> I have a PHP script which forks into the background and daemonizes itself. Is it possible to control such a script through upstart?
<ion> Upstart 0.6 is able to follow two specific cases of forking programs: âexpect forkâ for a main program that forks precisely once and âexpect daemonâ for one that forks precisely twice. Any other behavior, and youâll confuse Upstart 0.6 and have to wait for 0.10.
<matt1s> ion: I see, thanks. I think this script forks an arbitrary amount of times actually
<ion> Sorry, i was unclear. If the main program does a fork-and-exit precisely once or twice, âexpect forkâ and âexpect daemonâ can be used. The program is then free to fork arbitrarily as long as the main process is still running.
<matt1s> ion: I see, thanks for the insights
<peeps[work]> hello, i've restarted my ubuntu box today, and at least a couple services(apache2 and boinc-client) have not started.  I'm trying to figure out why.  these were automatically starting fine before today
<peeps[work]> i fonud this bug, but i'm not sure if it's related.  they say there is a problem with 0.6.3.11, and that downgrading fixes it.  https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/500520
<peeps[work]> though, i am on version 0.6.5-6
<peeps[work]> is it possible this same bug still exists in 0.6.5-6.  i don't understand this bug report because it looks like the workaround is to downgrade upstart, but was the source of the bug ever resolved?
<peeps[work]> cups was not started either.  i'm tearing my hair out here, can anyone help?
<peeps[work]> i will gladly post logs or whatever, but I don't know even know where to look or what information is useful in troubleshooting this issue.
#upstart 2010-07-14
<luke-jr> how can I get upstart to log all output to a file?
<dude__> I'm searching for a way to disable upstart jobs via a command, is this possible?
<frederickjh> Anyone know a method to run a upstart job as another user and still have it run with an exec command in the .conf file?
<frederickjh> When ever I try to pass the username to run it as it then gets interpreted by the shell and then running  status <jobname> tells me it is not running, but ps -C <jobname> shows it is running.
<JanC> frederickjh: what do you use to run it as a certain user?
<JanC> and the difference between status & ps is probably because you need another 'expect' stanza in the job file
<frederickjh> JanC I am using sudo -u username command to run the job.
<frederickjh> What is a 'expect' stanza?  Where do I find more info about it, JanC?
<frederickjh> I have not come across that command in any of the upstart docs/info I have found.
<JanC> it's in the manual page
<JanC> init(5) manpage
<frederickjh> ok
<frederickjh> I will check it out.
<JanC> so, run 'man 5 init'
<frederickjh> why the 5?
<frederickjh> why not man init ?
<JanC> because there are manpages for init in more than 1 category
<frederickjh> I see it brings up a different man page.
<JanC> see 'man man' for more info about these categories
<frederickjh> ok
<frederickjh> thansk
<frederickjh> thanks!
<JanC> e.g. 5 is for file format description 
<frederickjh> ok
<frederickjh> ok I am using expect fork now that I reread my job maybe in need expect daemon as that is what the processes are.
<JanC> frederickjh: if you look at the default 'man init', you'll see init(8) at the top right, meaning that one is in section 8, and at the bottom it lists init(5) in the SEE ALSO list
<frederickjh> ok
<JanC> might be useful for other programs in the future  âº
<frederickjh> yes
<frederickjh> one other question.  Right now I am specifying the username in the command but I would like to some how pass it to the command without a variable.
<frederickjh> As, when I use a variable it get interpreted by the shell and the status never shows it running, but maybe the expect daemon will fix that.
<Kasuko> what does "stop on runlevel" mean in a job? My upstart isn't running rc-sysinit properly and as such anything depending on runlevel or any old style sysvinit scripts aren't executed.
<Kasuko> runing Ubuntu 10.04
<JanC> "stop on runlevel 5" will stop a job when the "runlevel 5" event is emitted (by telinit, normally)
<Kasuko> I know but what is "stop on runlevel" with no number
<JanC> I don't think that's supposed to make sense
<Kasuko> "stop on runlevel" is in my rc-sysinit.conf job
<JanC> right
<Kasuko> so thats not the problem?
<JanC> no
<Kasuko> Dang!
<Kasuko> Thought I was close
<Kasuko> anyway to debug what upstart has done? initctl list doesnt return anything
<ion> It stops the job on any runlevel event.
<Kasuko> so basically when it's done it's job stop. Makes sense. But I am never getting the telinit 2 that should be running (or if I am it's not being registered)
<ion> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/543506 perhaps
<Kasuko> sorta Looks similar but they are all getting output from initctl list where I get nothing
<ion> Huh. Thatâs strange.
<ion> What does, say, âstatus rcâ output?
<Kasuko> mediapc-desktop.root ~: initctl list
<Kasuko> mediapc-desktop.root ~: status rc
<Kasuko> mediapc-desktop.root ~: return 1
<Kasuko> mediapc-desktop.root ~:                                                       1
<Kasuko> if you see there is a 1 to the right of the last line, thats the error code. I am getting no output AND no error codes
<ion> echo foo; >&2 echo bar
<Kasuko> mediapc-desktop.root ~: echo foo; >&2 echo bar                                1
<Kasuko> foo
<Kasuko> bar
<Kasuko> Should I be posting a bug report?
<ion> Please run âstrace -o strace.initctl status rcâ first and share strace.initctl via a pastebin or equivalent.
<Kasuko> I dont need pastebin, nothing is returned
<ion> strace.initctl is empty?
<Kasuko> ah my bad, it's output to a file, my apologies
<Keybuk> compare "status rc" as a user and as root?
<Kasuko> Sorry for delay, something came up. http://pastebin.com/UTuYdNYg
<Kasuko> mediapc-desktop.root ~: status rc
<Kasuko> mediapc-desktop.root ~: exit
<Kasuko> mediapc-desktop.kasuko ~: status rc
<Kasuko> mediapc-desktop.kasuko ~:
<Kasuko> no difference
<Kasuko> anything? 
<Keybuk> no idea, your strace makes it look like an empty executable
<ion> kasuko: What distro are you running?
<Kasuko> anything? ubuntu 10q.04
<Kasuko> oops sorry about thee repeat
<Keybuk> status --help ?
<ion> Please pastebin the output of apt-cache policy upstart; md5sum /sbin/initctl; grep sbin/initctl /var/lib/dpkg/info/upstart.md5sums
<Kasuko> status --help displays the standard help output
<Kasuko> http://pastebin.com/4TKeWN6X
<Kasuko> they aren't the same
<Kasuko> but I have tried apt-get install --reinstall upstart earlier today
<ion> ls -l /sbin/initctl; file /sbin/initctl; dpkg-divert --list '*initctl*'
<Kasuko> lrwxrwxrwx 1 root root 9 2010-05-12 21:34 /sbin/initctl -> /bin/true
<Kasuko> /sbin/initctl: symbolic link to `/bin/true'
<Kasuko> local diversion of /sbin/initctl to /sbin/initctl.distrib
<Kasuko> are you kidding me?
<Kasuko> wtf
<Kasuko> ya running initctl.distrib list gives me the proper output
<Kasuko> so why would that happen?
<ion> Good question
<ion> keybuk: I take it upstart maintscripts have never done any diversions in the past?
<Keybuk> nope
<Keybuk> people do it in chroots
<Keybuk> for fun, profit, and to take over the world
<Kasuko> This isn't a chroot though, nor am I in it for profits or taking over the world ... but that would be nice
<ion> kasuko: I take it youâre the only one with root access to the box? :-)
<Kasuko> Yes
<Kasuko> Why, should I be worried?
<Kasuko> maybe I'm not the only one with root access anymore :S
<Keybuk> seems an odd thing to do
<Kasuko> There are no erroneus users and I never changed the root password from randomly generated
<ion> Iâm out of ideas for now.
<Kasuko> I'm just more curious if I should be reporting it as a bug somewhere or if it was a one time thing
<Keybuk> debootstrap does it, but it usually undoes it
<Keybuk> bug where?  until you know what made the diversion, nowhere to file the bug
<Keybuk> unless we can file "something strange is afoot" bugs on the universe?
<Keybuk> for example
<Keybuk> <fx: best police officer's voice>
<Keybuk> What were you doing on, or around, the 12th of May at approximately 9.34 pee emm ?
<Kasuko> True, well I just linked initctl to initctl.distrib but that just solves the list. Now I am going to try the work around from that bug report
<ion> The proper way to remove the diversion is dpkg-divert --rename --remove /sbin/initctl
<ion> Running the two commands listed in https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Upstart%20jobs%20cannot%20be%20run%20in%20a%20chroot would result precisely in what your system has. How that has ended up happening is unclear.
<luke-jr> how can I get upstart to log all output to a file?
<Keybuk> it logs to syslog by default
<luke-jr> there is no syslog on this machine
<Keybuk> in that case, it logs to the console
<luke-jr> I know that. It scrolls by too fast to read.
<luke-jr> that's why I need it in a file
<Keybuk> so install syslog
<Keybuk> or something that captures the console output
<luke-jr> I've found it basically impossible to capture console output since Upstart reopens /dev/console
<luke-jr> rather than using the stdin/out it inherits from pre-init
<Keybuk> sure you can
<Keybuk> e.g. bootlogd
<luke-jr> any idea where i can get bootlogd? :/
<Kasuko> I can confrim that the work around in 543506 fixed the other issue. Thank you
<luke-jr> found one, but bootlogd seems to require CONFIG_LEGACY_PTY, which I cannot provide it... (or can I?)
#upstart 2010-07-15
<frederickjh> I have a program with three daemons and three jobs. The first job start the second daemon and it starts the third daemon. Start up works fine. I then have an event that I emit to shut all the daemons down. The first two shut down fine but the third does not seem to shut down ok. 
<frederickjh> Status tells me it has shut down but ps tells me it is still running. If I kill it from the command line I can no longer start the daemon with upstart. It always tells me the status is start/killed, and the same process number or stop/killed and the same process number.
<frederickjh> So it is like it does not even try to start it. What could be causing this?
<frederickjh> I I reboot then I can start all the daemons again.
#upstart 2010-07-16
<toabctl> how can i restart a daemon automatically after a package update? i tried "initctl restart myupstartjobname" but that does not work. any ideas?
<JanC> judging from your hostname mask you use Ubuntu, so you should be able to look how other packages in Ubuntu do that?
<JanC> (I think you should shut it down when removing the old package & starting the new one after installing the new package, instead of doing a restart)
#upstart 2010-07-17
<queenz> Hello
<queenz> can i ask how upstart works?
<ion> Yes
<queenz> hi ion
<queenz> so upstart as i read is the replacement for /sbin/init?
<ion> Yes, itâs an init implementation.
<queenz> so there is /sbin/upstart instead of /sbin/init ?
<ion> Upstart provides /sbin/init.
<queenz> /sbin/init is by default in every distribution but if you install upstart it will use /sbin/upstart ?
<ion> Thereâs no /sbin/upstart, Upstart provides /sbin/init.
<queenz> oh
<queenz> i see
<queenz> where does upstart start the desktop environment?
<queenz> where can i configure it?
<ion> Depends on your distro. The jobs are defined in /etc/init.
<queenz> i have ubuntu 10.04 Lucid Lynx
<queenz> i found a lot of files in /etc/init/, which one starts the desktop environment?
<ion> /etc/init/gdm.conf starts gdm
<queenz> and gdm starts gnome right?
<ion> Yep
<queenz> oh i see now. Do you know where i can configure GDM and change which desktop environment it will start?
<ion> gdm provides a selector for that in the UI.
<queenz> i made my own program that i want to start as a desktop environment but it doesn't show up in the gdm ui
<ion> Youâll have to look at documentation and/or what the other desktop environments do. This has nothing to do with Upstart.
<queenz> ok, you're right...
<queenz> how can i make upstart run my program ?
<ion> See init(5) for documentation /etc/init/*.conf for examples
<queenz> where's init(5) ?
<ion> man 5 init
<queenz> thanks
<queenz> so does that mean that all upstart init will run all scripts found in /etc/init/?
<ion> Upstart emits the âstartupâ event in the beginning. That triggers anything that has âstart on startupâ to start. In Ubuntu, the most important thing at that point is the mountall job, which then emits events such as âfilesystemâ when things get mounted, triggering any job that has the equivalent âstart on...â stanza to start.
<queenz> ok
<queenz> so there's an order which jobs get started first ?
<ion> Everything an event causes to start starts in parallel.
<queenz> oh
<queenz> much clearer now
<queenz> thanks
<RicardoPerez> hi! i'm using lucid. i need the smbd daemon starting after openldap's slapd daemon, but the latter still uses the old-style /etc/init.d/slapd init script. what can I do? thanks in advance!
#upstart 2011-07-11
<Harzilein> hi
#upstart 2011-07-12
<csgeek> so.. I'm trying to write a script to start N number of nodes.  (node being a java process that does some computations )   is there a recommended way of doing this.. ideally I could just do service start nodes though I don't mind doing multiple .conf files if there can be a master one a user could call 
#upstart 2011-07-13
<akio> I'm trying to get a serial console going on Centos 6, I have ttyS0 in securetty and I am trying to use initctl emit --no-wait fedora.serial-console-available DEV=ttyS0 SPEED=115200 to make it available but I am failing.
<akio> What am I not doing or doing wrong?
<akio> Actually I got it by doing start serial DEV=ttyS0 SPEED=115200
#upstart 2011-07-14
<nagchampa> hi guys, i've got a problem where my fakeraid (required for dual booting) is partitioned using gpt and dmraid won't initialise the partitions when it starts the raid, falling back instead on the gpt protection mbr record
<nagchampa> i can use kpartx to initialise the partitions but i'd like to have a boot script do it automatically
<nagchampa> is there an event i should be trying to hook in order to run before local filesystems are mounted
<nagchampa> or should i be doing it another way
<nagchampa> i'm looking through existing jobs and having trouble finding which events i should be waiting on
<nagchampa> is there a way to ensure my script runs before certain local filesystems are mounted?
<nagchampa> or will I have to modify the mountall job as well?
<nagchampa> would "start on (mounting)" be the correct way to do it? would that cause my script to run before local filesystems are mounted?
<nagchampa> or would it be better to use "start on (starting mountall)"
<nagchampa> or considering the mountpoints for these filesystems won't be available until my script runs, would it be sufficient to just have it run on startup?
<pmjdebruijn> hi all
<pmjdebruijn> start on started networking should make sure a script would only run after networking is up right?
<pmjdebruijn> for something that is dependant on domain name resolution
<pmjdebruijn> hmmm I just I should use net-device-up
<pmjdebruijn> sorry /just/guess/
<ustunozgur> Hi, I'm trying to use upstart for a daemon written with python-daemon. However I couldn't find any correct documentation, http://upstart.at/2011/02/01/process-less-jobs/ for example doesn't seem to help. The daemon can currently be started as mydaemon start, stopped with mydaemon stop etc. 
<ustunozgur> Should I go with the system-v style recommended there?
<ustunozgur> Also, sometimes after I make changes, the tab completion after issuing start doesn't work, why? Is it because of errors in conf.
<twb> What's the default signal sent to food on "stop foo"?
<twb> TERM looks like
<twb> Which is what poff sends by default to pppd, so now I'm having upstart control pppd directly, that should still be fine and pppd is still likely to run the iproute2 commands I put in /etc/ppp/ip-down.d/
#upstart 2011-07-15
<praveen_pk> Hey all, I am working on creating a custom Live ISO of RHEL 6. In the initrd, I mounted the final root FS and when I run the /sbin/init command, I get "init: Failed to connect to socket  /com/ubuntu/upstart: Connection refused "
<praveen_pk> Any suggestions on what could going wrong?
#upstart 2012-07-09
<asymmetric> hi, i'm having issues with configuring upstart
<asymmetric> is anybody available to help?
<JanC> asymmetric: better ask your question, then we can see if we can help...
#upstart 2012-07-10
<hunterloftis> Hey guys, I'm following the cookbook to set uid and gid for a process, but the job doesn't start in the user's environment (so it doesn't have his PATH, etc). Any simple way for me to correct that? I can't find anything in the docs
<JanC> set the PATH yourself?
#upstart 2012-07-11
<jdsanders> Hi all - is there any way to provide a custom exec or script for the actual stop procedure?
<jdsanders> use case is a server that stops gracefully when it receives a shutdown command over tcp, but loses data when it receives TERM
<jdsanders> I tried doing it with "pre-stop exec server-cli shutdown"
<jdsanders> which shuts it down properly, but it then respawns
<jdsanders> what I really want isn't a pre-stop, but just a stop exec
<SpamapS> jdsanders: I believe there is a 'kill signal' keyword
<SpamapS>        kill signal SIGNAL
<jdsanders> SpamapS: thanks, but I actually want *no* signal
<SpamapS> jdsanders: you can also do a 'normal exit SIGWHATEVER' and the signal will not be considered something to respawn on
<jdsanders> or more importantly, I want a process killed in a pre-stop clause to not be respawned
<jdsanders> oh interesting
<jdsanders> i'll read about that command
<SpamapS> jdsanders: so if it is graceful on SIGUSR1, then 'normal exit 0 USR1' means don't respawn if it is killed by USR1
<SpamapS> jdsanders: the '0' in there also means if the exit code was 0, don't respawn. Thats the default btw, so its surprising that your graceful shutdown doesn't exit(0)
<SpamapS> jdsanders: though I believe even if you exit(0) from the USR1 handler, upstart will consider that a kill by SIGUSR1
<jdsanders> huh
<jdsanders> thanks, sounds like i have a lot more respawn research to do
<SpamapS> jdsanders: the default logging level *should* tell you what upstart thinks killed the process
<SpamapS> jdsanders: would you mind pasting what you see? youre pre-stop, btw, is the right way to go
<jdsanders> SpamapS: one moment, going back up my terminal....
<jdsanders> shoot can't reproduce!
<jdsanders> ah, here
<jdsanders> maybe a race condition actually...
<jdsanders> deploy@NCVMLITSDEVQUE01:/var/www/apps/smartgrid/current/apollo$ sudo start redis-server
<jdsanders> redis-server start/running, process 9535
<jdsanders> deploy@NCVMLITSDEVQUE01:/var/www/apps/smartgrid/current/apollo$ sudo status redis-server
<jdsanders> redis-server start/running, process 9535
<jdsanders> deploy@NCVMLITSDEVQUE01:/var/www/apps/smartgrid/current/apollo$ sudo stop redis-server
<jdsanders> redis-server start/running, process 9625
<jdsanders> deploy@NCVMLITSDEVQUE01:/var/www/apps/smartgrid/current/apollo$ sudo status redis-server
<jdsanders> redis-server start/running, process 9625
<jdsanders> SpamapS: ^^
<jdsanders> SpamapS: here's the config script - https://gist.github.com/bf5b600645ff1ddc67cf
<SpamapS> jdsanders: looking
<jdsanders> SpamapS: just got back from a meeting, any luck understanding that redis-server issue?
<SpamapS> jdsanders: oops no I got sdistracted. Looking again
<SpamapS> jdsanders: I'd need to see your syslog entries to understand what happened
<jdsanders> k, do you know what label to look for in syslog?
<jdsanders> don't see anything like "upstart"
<jdsanders> looks like "init" maybe
<jdsanders> Jul 11 15:18:08 NCVMLITSDEVQUE01 init: redis-server pre-stop process (9765) terminated with status 1
<jdsanders> seems problematic maybe
<jdsanders> hmmm, yeah it seems like my shutdown command is *expected* to have exit code 1
<jdsanders> (oddly enough)
<jdsanders> so i think that's causing the problem?
<JanC> by default it will consider exit != 0 as an error
<JanC> so just override that if you want to ignore that
<jdsanders> JanC: thanks, I'm now fairly certain my server is exiting with 0 when it shuts down, and I've modified the pre-stop to make sure it exits 0
<jdsanders> all I see in syslog is now basically "process died, respawning"
<jdsanders> is there some way I can see more info about why it decided to respawn?
<JanC> maybe use a script instead of the main binary
<JanC> and make it log whatever seems relevant
<jdsanders> ok thanks
<SpamapS> jdsanders: you may also want to try 'initctl log-priority info' to get more about why it died
<SpamapS> jdsanders: I suspect just setting 'normal exit' properly is all you need
<jdsanders> SpamapS: i'll try the log level thing, but the reason I think the exit code is 0 is, I ran the same command that I'm executing from upstart in the foreground
<jdsanders> then shut it down from another process
<jdsanders> then checked its exit status
<jdsanders> and it was 0
<SpamapS> jdsanders: right, so I am wondering what upstart thinks the exit code is
<SpamapS> jdsanders: you might also just try 'normal exit 0'
<SpamapS> I thought that was the default
<SpamapS> but man 5 init isn't entirely crystal clear on it IIRC
<SpamapS> "Tasks may exit with a zero exit status to prevent being respawned."
<SpamapS> I believe that means jobs may not by default consider 0 a normal exit
<SpamapS> " All
<SpamapS>               reasons  for  a  service stopping, except the stop(8) command itself, are considered abnormal."
<SpamapS> jdsanders: yeah, try 'normal exit 0'
<jdsanders> huh
<jdsanders> i'll try that!
<SpamapS> jdsanders: what that means is that upstart won't be able to keep redis running in the face of accidental shutdowns. But thats probably fine.
<jdsanders> well
<jdsanders> I haven't tested this
<jdsanders> but my theory is that any non-graceful shutdown will exit with a different exit code than 0
<SpamapS> it should
<jdsanders> so I think if somebody *wants* to shut it down with the command that is meant for precisely that, it is reasonable to expect that it doesn't respawn
<SpamapS> jdsanders: you're still in better shape than with a bare daemon.
<jdsanders> alright, I think I've got this now, thanks for all the help!
<jdsanders> SpamapS,JanC: ^^
<SpamapS> jdsanders: woot!
<jdsanders> woot!
<jdsanders> alright...I hate to do this, but here's another one
<jdsanders> I'm on ubuntu 10.04
<jdsanders> which has upstart 0.6.5
<jdsanders> which doesn't support setuid
<jdsanders> but I need to run my server as another user
<jdsanders> so I'm doing
<jdsanders> sudo -u $USER sh -c "/usr/local/bin/redis-server /etc/redis-server.conf 2>&1 >> /var/log/redis/server.log"
<jdsanders> problem is that it makes the fork count jankier
<jdsanders> when I start the server it actually spawns three processes - one for sudo, one for sh, and one for redis-server
<jdsanders> the pid i'd really like to track is the redis-server one
<jdsanders> (which isn't doing any forking)
<jdsanders> any better way to change users?
<SpamapS> jdsanders: sudo is one way
<SpamapS> jdsanders: better is start-stop-daemon
<jdsanders> ah
<jdsanders> ok
<jdsanders> I'll look into that
<SpamapS> http://upstart.ubuntu.com/cookbook/#changing-user
<SpamapS> jdsanders: ^^
<jdsanders> awesome, thank you
<jdsanders> sorta related: how do i get out of the stop/killed state
<jdsanders> I currently have: redis-server start/killed, process 20674
<jdsanders> but: sudo kill -0 20674; echo $?
<jdsanders> kill: No such process
<jdsanders> 1
<jdsanders> sudo stop redis-server seems to hang
<SpamapS> jdsanders: ugh did you try 'expect fork' at one point?
<jdsanders> i did
<jdsanders> i was playing with it
<SpamapS> Ok, thats a bug
<jdsanders> and  seem to have foobared it right up
<SpamapS> http://paste.ubuntu.com/1087042/
<SpamapS> this script loops over the pid space until it reaches the pid given
<SpamapS> jdsanders: its python 3.. might have to port it to python2 ;)
<jdsanders> so the theory here is that it's running somewhere, but i don't know where?
<SpamapS> no
<SpamapS> its not running
<SpamapS> upstart thinks it should be
<SpamapS> and will wait forever for it to die
<jdsanders> so how does that script help?
<SpamapS> it creates processes until the given process exists.. then lets upstart kill it
<jdsanders> haha oooooooooooh, i get it
<jdsanders> clever
<SpamapS> not really, its a hack on hack on hack
<jdsanders> is there any way to re-initialize upstart?
<jdsanders> I could always just reboot
<SpamapS> jdsanders: yes but then it forgets all job state
<jdsanders> well yeah, hacks are clever
<SpamapS> yeah reboot works if you're just noodling around
<SpamapS> jdsanders: the original fix was in ruby and about 10 lines of it at that.. this one is just more friendly
<jdsanders> what do you mean by "forgets all job state"
<SpamapS> jdsanders: you can send upstart a command to re-execute itself, but then it forgets what is running and what is not
<SpamapS> which means your shutdown does not go so smoothly
<jdsanders> hmmm
<jdsanders> ok i'll figure it out
#upstart 2012-07-12
<jdsanders> SpamapS: ping?
<SpamapS> jdsanders: pong
<SpamapS> jdsanders: another day, more fun?
<jdsanders> lol, thanks for ponging but whatever it was I was gonna ask, I've figured out at this point
<jdsanders> oh i remember now - I was wondering what you think the "expect" value should be if I'm using start-stop-daemon
<jdsanders> is it "expect fork" because it forks to run the given --exec?
<jdsanders> it seems to work fine without "expect fork", so I just left it off, but logically it seems like it should have it
<jdsanders> SpamapS: ^^
<SpamapS> jdsanders: no
<SpamapS> jdsanders: expect is only for processes that detach from their parents
<SpamapS> jdsanders: if redis has a "run in the foreground" mode, just use that
<jdsanders> oh ho ho!
<jdsanders> well, i am
<SpamapS> then no expect is needed
<jdsanders> so your point is that even though multiple processes are created, none of them are detached
<jdsanders> so everything tracks properly
<jdsanders> gotcha
<jdsanders> that clears up some confusion
<jdsanders> thanks again SpamapS!
#upstart 2012-07-13
<samurai2> hi there, is there anyone know any example of how to run java jar file as daemon process using upstart? thanks
<JanC> samurai2: I think there is an example of that in the cookbook?
<samurai2> JanC : yeah, actually I'm looking at it right now. :)
<samurai2> I have make it as a background process
<JanC> you probably want the "alternative method" then
<samurai2> is it as simple as this http://bitkickers.blogspot.tw/2011/11/running-jar-as-service-linuxupstart.html
<samurai2> ?
<samurai2> because when I do service myapp stop
<samurai2> it doesn't stop until now
<TheLemonMan> hello there, i'm having some issues with the buildsystem not generating some headers
<samurai2> I don't know why it keep saying start myapp and don't generate "start myapp with ID : blabla"
#upstart 2012-07-15
<ilian> hi
<ilian> I  am trying to create a new upstart job but I have problems how to add it, I copied the file in /etc/init and run initctl reload-configuration but the job still does not appear in the list, any ideas what is wrong?
<JanC> ilian: reload-configuration is not needed
<auntie> I have a script I need to run that effects the entire system... how do I get it to run as the very first task before any others in upstart?
<JanC> ilian: and if it doesn't show up, there must be an error
<auntie> *affect
<auntie> effectively I want it to run right after init-bottom in the initrd, just after it runs init :P
<JanC> maybe a bit of a hack, but you could add "--startup-event pre-startup" to the kernel commandline and add a job that starts on the 'pre-startup' event which does whatever you want to be done and when ready emits the 'startup' event (which is the default event emitted on boot, so it should start whatever would normally be started)
<auntie> mm, looks like that might do it
<JanC> BTW: de "pre-startup" is just something I made up, use whatever you want to call it
<auntie> right
<JanC> well, not whatever, make sure it's not the same as something used for other things  ;)
<auntie> if I do it like this, is there some other default startup script that I would be circumventing?
<auntie> don't want to break anything...
<JanC> by default the startup event is "startup"
<auntie> oh, oh I see
<auntie> that makes sense now, I thought "startup" refered to a script, but it's just an event
<JanC> yep
<auntie> I just gotta emit startup from my own script
<auntie> cool
<JanC> hm, I wonder if this trick is in the cookbook already
<auntie> it's a nice hack
<auntie> I feel like I'm trying to use upstart as System V init...
<auntie> might be an indicator that something is wrong ;)
<ilian> JanC, yes I found the error and fixed it, thanks )
<auntie> oh, aparantly upstart doesn't even use /usr/sbin/policy-rc.d
<auntie> I figured it would, and that's why I was trying to delete the file pre-startup
<auntie> guess I don't really have to? mmm
<ilian> how can I split exec command arguments in several lines without getting "unknown stanza"
#upstart 2013-07-09
<bee_keeper> hi, i'm not sure if I have the correct use case, but can i start/stop an upstart process from a django admin command?  Would that make sense?
#upstart 2013-07-11
<jodh> xnox: hi - could you take a look at https://code.launchpad.net/~jamesodhunt/upstart/bug-1199778/+merge/174138 when you get a moment?
<xnox> jodh: reviewed. Slightly confused why we need those three asserts =) looks like a timebomb waiting to explode.
<jodh> xnox: thanks. I disagree about the timebomb bit though :)
<xnox> jodh: so what are we asserting?
<jodh> xnox: MP updated
<xnox> looking
<xnox> jodh: so you are saying it is only valid to deserialise to a completely blank state? why would that be necessary?
<xnox> jodh: i can write a unit test that does 3 deserialise_all in a row and check that objects are correctly replaced?
<jodh> xnox: yes, it's only valid to deserialise from a blank state.
<xnox> jodh: and if the state is not blank, state_from_string should return error code less than 0, error condition should run - write out state_write_file, and dumn re-exec should have been run.
<xnox> s/dumn/dump/
<xnox> my understanding was that stateful re-exec should give up, under failure conditions.
<xnox> but not assert.
<jodh> xnox: I think it's probably best to raise a bug with these ideas so we can work on refining this as a separate project.
<xnox> ok.
<jodh> xnox: in terms of the bug at hand though, can you confirm the fix works based on my instructions on how to recreate?
<xnox> jodh: it should. But there are a couple things I want to try though first. I'm on my laptop in bluefin, will be back at my desktop in the evening.
<xnox> jodh: i think this bug can be caught by testing deserialisation with a dump from a system where sessions jobs are running.
<xnox> thus it should be added as a unit test.
<xnox> at the moment all of our files are without sessions.
<jodh> xnox: agreed - we should add such a test.
<xnox> jodh: so, it still fails for me.
<xnox> not sure if there is something wrong with my test.
<xnox> see: https://code.launchpad.net/~xnox/upstart/bug-1199778/+merge/174235
<xnox> or just branch lp:~xnox/upstart/bug-1199778 and build/run the test_conf test.
<xnox> this branch has your fix merged.
<jodh> xnox: is it crashing in the same place? assert/backtrace?
<xnox> ...with unflushed data
<xnox> (null): No ConfSources present in state data
<xnox> (null): No ConfSources present in state data
<xnox> (null): No ConfSources present in state data
<xnox> (null): No ConfSources present in state data
<xnox> (null): Failed to resolve deserialisation dependencies
<xnox> test_state: tests/test_state.c:3371: test_session_upgrade: Assertion `(state_from_string (json_string)) == 0' failed.
<xnox> jodh: I wonder if the pastebin that I fetched from the VM was incomplete serialisation (well chopped off due to size)
<jodh> xnox: well, is it valid json? what does "json_pp < file.json" do?
<xnox> json_pp spins at 100%.....
<xnox> produced formatted output, let me rerun again to see the exit status
<xnox> exited with 0, so it's all of it.
<jodh> xnox: I think gdb may be required to establish where the failure is being indicated :)
<xnox> it's weird.
<xnox> so running without the silly automake runner.
<xnox> Testing upgrade tests
<xnox> ...with data file 'upstart-1.6.json'
<xnox> (null): No ConfSources present in state data
<xnox> ...with data file 'upstart-1.8.json'
<xnox> (null): No ConfSources present in state data
<xnox> ...with data file 'upstart-pre-security.json'
<xnox> (null): No ConfSources present in state data
<xnox> ...with data file 'upstart-1.8+apparmor.json'
<xnox> (null): No ConfSources present in state data
<xnox> ...with data file 'upstart-1.8+full_serialisation-apparmor.json'
<xnox> ...with data file 'upstart-1.8+full_serialisation+apparmor.json'
<xnox> ...with data file 'upstart-session.json'
<xnox> (null): Failed to resolve deserialisation dependencies
<xnox> test_state: tests/test_state.c:3371: test_session_upgrade: Assertion `(state_from_string (json_string)) == 0' failed.
<xnox> Aborted (core dumped)
<xnox> So all of them have no confsources present.... which is well totally not true.
<xnox> jodh: going back to before your fix also has "No ConfSources present in state data" messages printed....
<xnox> which I guess is correct, since only full_serialisation introduced thsoe.
<jodh> xnox: correct.
<xnox> jodh: is it expected for chroot deserialisation to fail resolving dependencies...?
<jodh> xnox: slightly bizarrely, chroot sessions are not deserialised - they are detected, then ignored with a warning (see my comments on bug 1200264).
<xnox> jodh: ok. Hm..... yet something later probs for them..... like the full deserialisation code?
<xnox> i'll debug it.
<xnox> jodh: have fun wherever you are off to =)
<xnox> I guess 1-to-1 mappings don't work, if you decide to skip a couple of items from the first set, and rely on positional mapping between the two sets.........
#upstart 2013-07-12
<xnox> slangasek: or stgraber: please review https://code.launchpad.net/~xnox/upstart/bug-1199778/+merge/174372 to unblock SRU. stgraber - wasn't there something else that needs to go in the SRU? (we now pulled the last one)
<xnox> in the mean time I'm preparing saucy upload.
<xnox> stgraber:  lp:~ubuntu-core-dev/ubuntu/raring/upstart/raring
<stgraber> xnox: the respawn fix
<xnox> stgraber: ack. So we need to cherry-pick the respawn fix, above chroot-reexec-fix. Can you review above merge-proposal, if you are in the mood for upstart subtle bugs =)
<stgraber> xnox: I'll take a look once I'm fully awake ;) currently still at the processing IRC backlog and e-mails phase ;)
<stgraber> ok, I think I'm as awake as I'll be today, taking a look at that branch now
<stgraber> xnox: should test_session_upgrade do some checks of the unserialized data or is checking the return code sufficient?
<xnox> stgraber: i think it should be checking unserialized data for a complete test.
<xnox> stgraber: checking the return code is sufficient test for the bug in question: "upstart upgraded failed with active chroot session"
<stgraber> xnox: ok, can you add some tests to at least ensure those lists and hashes contain stuff post-unserialization? I don't think we need a ton of asserts but just checking that they aren't empty anymore would be nice
<xnox> right, I see what you mean.
<xnox> stgraber: and that caught a bug =)
<stgraber> xnox: yay!
<xnox> stgraber: so, pushed more asserts. As it turns out chroot-sessions only have CONF_JOB_DIR, unlike normal system init which has CONF_FILE & CONF_JOB_DIR.
<xnox> stgraber: so it checks that the correct session got deserialised with proper conf sources and that none of the job classes belong to a session.
<xnox> stgraber: since we don't deserialise those at the moment.
<xnox> stgraber: right, I'm off to my lunch break....
 * xnox scratches head
<xnox> will be back to poke upstart or android a bit more.
#upstart 2013-07-13
<cpick> I'm running precise 12.04.2 amd64 with upstart 1.5-0ubuntu7.2 and I'm having trouble debugging the upstart scripts I'm writing.
<cpick> http://upstart.ubuntu.com/cookbook indicates that I should be able to set upstart to log-priority debug
<cpick> But after doing that I don't see any init trace in /var/log/syslog or any other file I can find.
<cpick> I've tried setting it with both `sudo initctl log-priority debug` and by adding --debug to the kernel's boot options, using either method I've verified that it worked by running `sudo initctl log-priority` and seeing it's set to "debug".
<xnox> cpick: $ dmesg
<xnox> cpick: grep init /var/log/kern.log 
<xnox> cpick: is upstart logging visible in one of the above two places?
<cpick> Yeah, nothing out of init in /var/log/kern.log eithier.
<cpick> No
<cpick> I lied
<cpick> sorry
<cpick> dmesg does include init: trace
<cpick> Excellent, thank you.
<cpick> I thought upstart was supposed to switch from the kernel buffer to syslog as soon as syslog was up?
<xnox> cpick: good point. let me file a bug, to check up on it.
<cpick> It turned out the root cause of the problem I was trying to debug was: https://bugs.launchpad.net/upstart/+bug/568288
<cpick> A frustrating waste of time.
<xnox> cpick: right, sad. I'm confused why that patch was not taken into upstart.
#upstart 2014-07-07
<gcg> Hello, I am trying to start a service as a different user with sudo but it gives an error like this: "sudo: sorry, you must have a tty to run sudo" 
<gcg> my distro is centos 
<gcg> I found couple of solutions from google but all of them from 1-2 years old and mentions that this feature will be added
<gcg> did it? :) 
<xnox> gcg: yes.
<xnox> gcg: check $ man 5 init
<xnox> gcg: on your system and check if you have "setuid" & "setgid" stanzas available to you
<gcg> nice, setuid is what I am looking for, thank you xnox 
<jodh> xnox: he may be back - I think upstart in centos is too old for either logging or set?id
<xnox> ack.
#upstart 2014-07-08
<geofft> hi folks! I'm trying to debug why a "start on ((a and b and c and d and e) or f)" job isn't starting. I made test jobs with "start on a" through "start on e", and they all run. 
<geofft> what should I be trying? (there isn't a limit on the number of conditions, is there?) 
<geofft> the job in question doesn't ever get mentioned in verbose output. 
<xnox> geofft: is the job valid? e.g. status $jobname
<xnox> geofft: and to start that job you need to do "initctl emit a; ... b; ... c; ... d; ... e;" or "initctl emit f"
<xnox> geofft: if the job is stopped, the full a-e set of events needs to be re-emitted. or f event needs to be emitted.
<geofft> xnox: lemme reboot this VM, one sec, but I believe status said stopped/waiting 
<geofft> and it never started, from boot 
<xnox> geofft: then all events have not fired.
<geofft> then why did my test jobs all run? 
<xnox> geofft: and/or the events are mistyped or misnamed.
<geofft> well, it also seems to work one in several boots... 
<geofft> is it possible for events to fire too early / in the wrong order? 
<geofft> I am pretty confident I typed the test jobs the same way they are listed in the actual job 
<geofft> like, on the dumb questions front, is it known that having five "and"s works? is there some internal limit? 
<geofft> or can I ask upstart which condition it thinks didn't fire? 
<geofft> hrrrm, I wonder if it's a misparse given that d is an instanced job, and it all works fine if "and e" isn't around. 
<xnox> geofft: can you please list actual config?
<xnox> geofft: echo start on ((a and b and c and d and e) or f) | sudo tee /etc/init/foo.conf
<geofft> sure, I can pastebin or something, one sec 
<xnox> geofft: for event in a b c d e; do sudo initctl emit --no-wait $event; done
<xnox> geofft: sudo status foo
<xnox> works.
<geofft> xnox: yes, I can get it to work if I manually emit d. 
<geofft> my local changes are http://paste.debian.net/108646/ , the rest is all from Trusty (which I can pastebin if that's useful) 
<geofft> the only change the override does is adding "and e" ("and stopped baremetal-earlyauth"). 
<geofft> (and that job is successfully running and then stopping) 
<xnox> geofft: task & expect stop don't make sense.
<xnox> geofft: on boot what's the "status baremetal-earlyauth" ? is that process simply stopped and that's it?
<xnox> geofft: also task doesn't make sense and to key on "stopped baremetal-earlyauth"
<geofft> hm, sure, but I added task later as part of debugging, and it was broken before that, too. 
<geofft> I can pull it back out 
<xnox> geofft: i think you want "task", delete "expect stop" (unless baremetal-earlyauth actually uses SIGSTOP), and in the lightdm.override you want "and started baremetal-earlyauth"
<geofft> it does use SIGSTOP for readiness (there's something else that waits for "started baremetal-earlyauth") 
<xnox> since for tasks, started is emited after all process quit.
<xnox> there is no distinction between started & stopped for tasks. Task only emit "started" after all processes quit. That's how "tasks" are different from normal/regular jobs.
<xnox> if there is something else, it may be blocking for stopped to be emitted.
<xnox> ...
<geofft> hm, that doesn't match my reading of  http://upstart.ubuntu.com/cookbook/#task ? am I misreading it? 
<geofft> baremetal-earlyauth is a short-running program that (possibly) prompts you for a password at plymouth 
<geofft> and I care both about readiness, since other things communicate with it, and exit, since I don't want to start lightdm until it's done. 
<geofft> (looking again, I take that back, there isn't something that waits for "started baremetal-earlyauth", but probably I don't want task, anyway.) 
<geofft> taking out "task", same behavior, and `status baremetal-earlyauth` is stop/waiting. 
<geofft> xnox: am I misreading the upstart cookbook docs about when tasks emit started and stopped? 
<paintedbicycle> Having trouble with upstart on ubuntu with nodejs. I start the app with user called 'deploy', but app doesn't have permission to write to disk even though all files are owned by deploy. When I log into ubuntu as deploy and start app, app can write fine. Tried using setuid, asked on serverfault, still no luck.
<paintedbicycle> To follow up, at first when running "sudo -u 'usernane' ..." the sudo process wouldn't go away, so I got an answer here (http://serverfault.com/questions/608240/upstart-why-two-processes-when-running-as-a-different-user/609194) to allow the sudo process to go away and just leave me with my app running as the 'deploy' user I want. Verified that with 'ps aux'. However, when I use the app, the permissions are definitely not
<paintedbicycle>  'deploy' as it can't do anything. None of the tutorial that use setuid, etc seem to be any different from one another and are mostly out of date
#upstart 2014-07-09
<tavoe> Could someone please read this script and tell me if it seems wrong to you? http://paste.ubuntu.com/7768361/
<Eisbrecher_xnox> jodh: hey, with lp:upstart unity7 desktop session fails to start
<Eisbrecher_xnox> initctl: Method "SetEnvList" with signature "asasb" on interface "com.ubuntu.Upstart0_6" doesn't exist
<Eisbrecher_xnox> in unity-gtk-module
<Eisbrecher_xnox> unless i was running distro init, with new initctl.
<Eisbrecher_xnox> i think that's what it was.
#upstart 2014-07-12
<Super> Hello. I am having a hard time with upstart. I am used to do: "/etc/init.d/freeradius restart" but another user of same server doesn't do so. He uses. "service freeradius restart". What happens is, one session started by one method can't be ended by other method. And I've already looked for the PID file. But I seem to be missing something.
<Super> I'll read the book suggested by headline.
<Super> Where is PID saved for upstart applications? I have one application without sync between upstart and init.
<fluter> hi, does the init jobs run in the same process as the sysv services?
<fluter> is it possible for a job to hang the boot process?
#upstart 2015-07-09
<Guest38499> i have the following upstart script in `/etc/init` for my ubuntu - https://bpaste.net/show/ca9679828fb6.  The script will run manually, but will not run automatically on system boot up (or reboot).  Could someone assist me?
#upstart 2015-07-11
<durka42> can I get some help writing a service file? I'm trying to use a pre-stop script to have upstart gracefully kill my program by sending input to a screen session, like this http://unix.stackexchange.com/questions/13953/sending-text-input-to-a-detached-screen
<durka42> but it just... doesn't feel like running my pre-stop script, it seems
<durka42> ah... it was just killing the process immediately after starting the pre-stop script, without waiting for it to run
<JanC> that doesn't sound right?
<durka42> JanC: I dunno, but when I added "sleep 1" to the pre-stop script, it seems to work
<JanC> eh, if it didn't wait for the pre-stop script to finish that wouldn't help?
<durka42> hmm, you're right
<durka42> well, the first command in the pre-stop script uses screen -- maybe it forks and upstart doesn't notice?
<durka42> take a look : https://github.com/haptics-nri/nri/blob/master/nri.conf
<JanC> screen is already running in the background, I assume, so you would have to wait for whatever you are doing in screen to end
<durka42> that's correct, the pre-stop sends the quit command to the program running in screen
<durka42> so that it doesn't get killed by SIGTERM
<durka42> (because it's written in Rust which doesn't support signal handlers yet :( )
<durka42> is there a better way to wait for that exit than "sleep 1"?
<JanC> is there any (good) reason why you _need_ to run this inside screen?
<durka42> JanC: I need to be able to connect to the console and interact with the program, if necessary
<durka42> it has a CLI
<durka42> it has a web server, too, so the CLI shoul never be necessary, but you know... bugs
<durka42> anyway, I need to run
<durka42> if you have an idea on how to make that service file cleaner, I might be around here later or you can file an issue at that github :)
<durka42> thanks for your help!
#upstart 2016-07-14
<rlarkin> Hi, looking for a good link to help trouble shoot an init script inside an LXD container
<rlarkin> the service ( salt-master version 15.08 ) starts just fine directly, and other init scripts are working as expected.  but salt-master always fails with 'job failed to start' .  I can't figure out what is expected ( and not there ) by the init script.
<rlarkin> I am reading the cookbook page...
<AnrDaemon> First, enable logging of init script. That's "console log". Second, enable logging of your program, if it has one.
<AnrDaemon> And third, pastebin your init script so far. Let's take a look.
<rlarkin> k
<rlarkin> http://pastebin.com/9d6er0RC
<rlarkin> doing logging
<AnrDaemon> Well, that' snot upstart script.
<rlarkin> huh.  I just assumed trusty was upstart
<AnrDaemon> It is, but what you linked is an abomination.
<rlarkin> lol, that's good to know
<rlarkin> it's what came with the package 
<AnrDaemon> They are still living in the 2008â¦
<rlarkin> wow
<rlarkin> I was trying to figure out what might be missing from my container environment and not finding anything.  but it sounds like what I really need is a new init script.
<AnrDaemon> http://pastebin.com/v67FsCHt
<AnrDaemon> That'a about all that you need. Likely.
<AnrDaemon> If salt-master have a switch to run explicitly in foreground and not daemonize, use that.
<rlarkin> it has -d (daemonize) and -l debug options
<rlarkin> that's so simple.  
<AnrDaemon> Well, okay. Just leave -d out. Upstart does process control, so it needs to know what is running.
<AnrDaemon> Yes, it is, in many cases.
<rlarkin> thanks man
<AnrDaemon> There's 3 types of daemons. 1. Very simple ones, no config at all. 2. Those required config in comandline. 3. Those with external config.
<AnrDaemon> Upstart is good for 1 and 3, you just start daemon and it does everything it has to do.
<rlarkin> this is 3 (in a default location)
<AnrDaemon> #2, of course, needs some treatment more often than not :/
<AnrDaemon> And not always a trivial treatment, given you can't pass options from pre-start to start.
<rlarkin> cool.  I'm adding this to my deployment
<AnrDaemon> Do note the script don't have any start or stop clauses. You'll have to figure these your yourself, once you have your daemon up and running.
<rlarkin> sure, thanks
<AnrDaemon> Also check the cookbot for "expect â¦" syntax, if upstart still losing the tail.
<AnrDaemon> cookbook**
<AnrDaemon> (Some services fork to drop privileges after initialization, no way around that, unless you start them with restricted privileges to begin with, which is not always possible, i.e. if they need ports in 0..1023 range.)
<rlarkin> k.  
<rlarkin> salt-master is not starting with the simple init script either.  so I think my container env is missing something that's not needed by all services
<AnrDaemon> Look in logs. (add "console log" to the script, add -l debug or what not to the daemon parameters.)
<AnrDaemon> Log is in /var/log/upstart/<servicename>*
<AnrDaemon> "console log" is an overall good idea, though.
<rlarkin> there's no 'salt-master' file in /var/log/upstart.  
<rlarkin> the return is instantaneous
<rlarkin> root@salt01:/etc/init.d# service salt-master start 
<rlarkin> start: Job failed to start
<AnrDaemon> 1. Delete "salt-master" from /etc/init.d.
<rlarkin> ok
<AnrDaemon> 1. Run init-checkconf /etc/init/salt-master.conf
<AnrDaemon> It will at least tell you if it is syntactically correct.
<rlarkin> File /etc/init/salt-master.conf: syntax ok
<AnrDaemon> initctl start salt-master
<rlarkin> initctl: Job failed to start
<AnrDaemon> What's in logs?
<rlarkin> there's still no salt-master in /var/log/upstart
<AnrDaemon> Anything in system log?
<rlarkin> so far, syslog has only dhcp messages.
<AnrDaemon> Try something real simple? Like exec /bin/printf "Started ok"
<rlarkin> ok.  this one fails with an instanc 'Job failed to start':  http://pastebin.com/D3ZuaXrd
<rlarkin> but this one works just fine: http://pastebin.com/k70KwXfh
<rlarkin> permissions are identical
<rlarkin> my paste is wrong, old one from klipper.  I changed it to /usr/bin/printf
<rlarkin> minor detail
<AnrDaemon> Again, for the â¦ time.
<AnrDaemon> Do not confuse init script and upstart job. They are located in different places and started by different mechanics.
<AnrDaemon> Also sorry, it is /usr/bin/printf
<AnrDaemon> Just tried this script myself: http://pastebin.com/e4MFSCYM
<AnrDaemon> # initctl start xxx
<AnrDaemon> xxx start/running, process 19415
<rlarkin> ok yeah, that works
<AnrDaemon> So, if you now replace /usr/bin/printf with /usr/bin/salt-master -l debug etc. it should at least try to start it.
<rlarkin> using initctl and not service, salt-master started after I commented out #limit nofile 100000 100000
<rlarkin> and when I remove the abominable script I can start salt-master with 'service'
<AnrDaemon> 100k ? :D
<AnrDaemon> Even MySQL don't need that many.
<AnrDaemon> Happily working with 32k
<rlarkin> oh, actually it works when /etc/init.d/salt-master still exists.  I guess it's not even relevant here.  Hi upstart, nice to meet you.
<AnrDaemon> As long as it is not installedâ¦ Or not called directlyâ¦ You're using
<AnrDaemon> upstart.
<AnrDaemon> I suggested to get rid of it to reduce confusion.
<rlarkin> at 50000 it works
<rlarkin> thanks so much AnrDaemon
<AnrDaemon> Does it actually do need that many open files?
<rlarkin> in a much bigger environment , yes.  but then I probably wouldn't be using a container
<AnrDaemon> Fair point.
<rlarkin> I'm actually trying to stand up a dev test  env, so pretty small.  just a dozen or so clients ( not thousands )
<rlarkin> the default lxd env probably sets a cap
<rlarkin> ok, thanks for you help.  thanks to you I can go have some family time :)
<AnrDaemon> :D
#upstart 2016-07-16
<zer0def> hey guys, just a quick question - how would i go about enabling a service that takes keyvals with upstart?
<zer0def> (i presume it has something to do with override files, but i'm yet to make real sense of them)
<zer0def> ok, nevermind, worked around it
