#upstart 2006-12-04
<vernes> How do I add my own runlevel to the upstart system? A quick glance shows that /etc/init.d/rc is called with the runlevel as argument, do I have to edit rc to add my own runlevel?
<AlexExtreme> How nice of you.
<treepio> Do you know a guide to make a working system with upstart?, I want to learn.
<treepio> You can private message me if you do please, yould help me alot.
<treepio> And eventually help upstart :)
<treepio> Too bad, would have been great to have some reference.
#upstart 2006-12-05
<Squido> How does one pass a variable from the grub
<Squido> boot line to a script?
<_ion> /proc/cmdline
* Starting logfile irclogs/upstart.log
* Starting logfile irclogs/upstart.log
<Keybuk> afternoon
<_ion> Hi
<AlexExtreme> hey
<Keybuk> Testing nih_alloc_using()
<Keybuk> ...with realloc
<Keybuk> ...with failing realloc
<Keybuk> BAD: wrong value for ptr, expected 0x401a7d got (nil)
<Keybuk>         at tests/test_alloc.c:103 (test_alloc_using).
<Keybuk> zsh: abort (core dumped)  ./test_alloc
<Keybuk> \o/
<Keybuk> much more useful test case output
<_ion> Cool.
<_ion> And yay for using zsh. ;-)
<Keybuk> heh, I've always used zsh
<_ion> There was a long period of time i had to suffer from bash, because zsh didn't support UTF-8.
<Keybuk> how often did you need utf-8 on the shell? :)
<_ion> Quite rarely, but when you do need it (remember i'm Finnish, non-ASCII letters are used in our language), it's nice if it works. :-)
<zod> i wanted to test upstart on archlinux but if i use a different prefix to build the package it fails with the following error
<zod> libtool: install: error: cannot install `libupstart.la' to a directory not ending in /usr/lib
<Keybuk> zod: how did you compile it?
<zod> ./configure --prefix=/opt/upstart --sysconfdir=/etc
<zod> and it fails on make install
<Keybuk> odd
<Keybuk> which version?
<zod> 0.3.0
<zod> i use "make DESTDIR=$startdir/pkg install" to build a package
<Keybuk> startdir?
<zod> the directory where the files should go so i can build the package
<Keybuk> can you copy everything out of your terminal into npaste?
<Keybuk> it worked for me
<Keybuk> (ie everything from the configure line through to the failed bit)
<zod> http://nopaste.php-q.net/259171
<Keybuk> you ran "make" before you ran "configure" ?
<zod> ehm nope
<Keybuk> there's no "make" output in that paste
<zod> oh my fault :(
<zod> i used ./configure, ran make, changed ./configure without cleaning up
<Keybuk> so you built it with /usr/lib as the prefix :)
<Keybuk> which is why it failed
<zod> damn stupid ;)
<Keybuk>  nih/tests/test_list.c |  790 +++++++++++++++-----------------------------------
<Keybuk> sweet
<Keybuk> new test framework makes the test files much smaller
#upstart 2006-12-06
<Keybuk>  2 files changed, 232 insertions(+), 619 deletions(-)
<Keybuk> muahaha
<_ion> :-)
<Malte> can someone read what i am typing?
<_ion> Nope.
<_erebos> hello, someone available for a question? - maybe i found a bug.
<_ion> Well, you've already asked two questions. Feel free to ask more. :-)
<_erebos> when starting a job there is a message stating the process id (eg 13788) but when ich ckeck with "ps -ef" i see that the PID of that job actually is the one stated incremented by 1 (13789) ... 
<_ion> The first guess that comes to mind is that it forked.
<_erebos> that's why i think that "stop <job>" doesn't work because the PID is wrong ... the process is never killed
<_ion> IIRC upstart doesn't know how to find the pid of a forked process just yet (please correct me if i'm wrong).
<_erebos> forked ... well i have to look it up (i am from germany and new to linux)
<Keybuk> _ion: that's correct
<_erebos> oh well ... maybe u mean that the program (in my case proftpd) is started by upstart and then starts a subprocess, am i right
<Keybuk> it's a planned feature; but for now, processes must remain the foreground to be supervised
<_erebos> kk
<Keybuk> (this is true of other init systems as well)
<_erebos> then i#ll wait for future releases ...
<_ion> erebos: Look at the program's man page, there might be a switch for not forking.
<Keybuk> you can start proftpd with the -n switch
<_erebos> kk thx ... i'll try that ...
<Keybuk> respawn /usr/sbin/proftpd -n
<_erebos> worked .. :) thx
* Starting logfile irclogs/upstart.log
<_erebos> is there a list of yet  recognized events?
<_erebos> okay ... according to the code there are currently NO other events than the 5 basic events ... :(
<Keybuk> make up your own
<Keybuk> initctl emit EVENT-NAME
<_erebos> worked ... :) but you meant initctl trigger EVENT-NAME
<Keybuk> depends on the version of upstart
<_erebos> kk ... i have 0.27 and you are probably ahead with 0.30+ ;)
<Keybuk> yes
<treepio> Anyone got a great guilde for a minimal working system?. I want to make it but using upstart instead of normal sysvinit
#upstart 2006-12-07
<quappa> hello. is there a way to know if I upstart is ok after upgrade to Edgy? I don't see any change in startup time. People on forums say it's dramatic.
<quappa> s/if I/if/
<_ion> In edgy, upstart just launches the same old sysvrc scripts. It doesn't affect startup time until the whole bootup process is migrated to upstart jobs (that's going to happen in feisty). Edgy has other changes that may decrease startup time, though.
<quappa> oh. thanks.
<quappa> probably those other changes didn't affect my setup.
<Keybuk> Md: you'll probably like the plan to take over the world that the Ubuntu Kernel Team and I are cooking up :p
<Md> Keybuk: --verbose
<Keybuk> Md: moving the decision about which devices get bound to which drivers to userspace
<Keybuk> so udev is responsible for it
<Md> how?
<Keybuk> first, with .20 and a couple of patches, ensure that drivers are first class sysfs objects with uevents, etc.
<Keybuk> then modify the module information so that a module announces which drivers it contains, and maps modaliases to driver names instead of module names
<Keybuk> alias pci:blahblah pci:drivername
<Keybuk> alias pci:drivername modulename
<Md> but is this needed for every driver?
<Keybuk> finally merge modprobe into udev (using kay's patch) so we can lookup this in udev
<Keybuk> I think that the first two are very useful for every driver
<Keybuk> the third bit is also useful, because you can use udev to force a bind or unbind
<Keybuk> as to which drivers we make the decision for, I don't think it makes much difference; we could leave the easy decisions up to the kernel, and just do the hard ones in userspace
<Keybuk> but I don't think there's any drawback to doing it all in userspace
<Md> performance?
<Keybuk> I don't think that the bind between a device and driver is ms critical?
<Md> no, but when you load 30 drivers at boot time maybe it starts to be noticeable
<Keybuk> udev is going to get called out anyway for those 30 devices
#upstart 2006-12-08
<wasabi__> Keybuk: you around?
<Keybuk> yup
<Keybuk> what's up?
<wasabi__> initramfs questions. Trying to boot a system, which seems to be fairly broken. At some point during the initram, the HD's get probed... repeatidly (as indicated by lights blinking on then off for 1 sec on the drives)
<wasabi__> Trying to pinpoint it
<wasabi__> break seems to get me there.
<wasabi__> can I continue after breaking?
<Keybuk> yeah, just exit the shell
<wasabi__> hmm. gave me a panic last time I tried thta
<Keybuk> which release?
<wasabi__> feisty
<wasabi__> looks like udev isn't kicking off.
<wasabi__> it's um... the latest daily. I have this wonderful system here which has an intel d965.
<wasabi__> So, nothing less than 2.6.18 works on it. ;0
<wasabi__> The problem i was having is the device nodes weren't being created before mdadm ran
<wasabi__> I ran udevd --daemon;udevtrigger;pkill udevd manually during premount
<wasabi__> and then exit 0, and it continued, and worked.
<_ion> There used to a problem with the run order of udev, lvm and md stuff, but i thought it was already fixed.
<wasabi_> yay new working system
<wasabi_> sorta.
<Keybuk> oh
<Keybuk> anything to do with lvm, md, evms, etc. is totally busted in feisty :p
<wasabi_> nice.
<wasabi_> well, got it working by hand... until i reboot again
* wasabi_ sticks udevd --daemon; udevtrigger; pkill udevd into local-top/mdadm
* wasabi_ snicker
<Keybuk> doesn't it PREREQ="udev" ?
<wasabi_> Yeah
<wasabi_> Which doesn't exist in local-top
<Keybuk> weird
<wasabi_> Ahhhh.
<wasabi_> udev is now in init-bottom and init-premount.
<wasabi_> and not in local-top.
<Keybuk> right
<Keybuk> those happen first
<Keybuk> well, premount does
<wasabi_> how do the prereq's work though?
<wasabi_> Aren't they only within the one script subdir
<Keybuk> wonder if it's looping because udev doesn't exist :p
<Keybuk> yeah
<wasabi_> so, the prereq "udev" is unfulfillable.
<wasabi_> ahh, yeah.
<wasabi_> it's looping.
<wasabi_> hence the HD noise. ;0
<Keybuk> right
<Keybuk> that's the bug then
<treepio> Trying to make upstart-0.3.0 but I get alot of errors with: ./configure --prefix=/tree/temp/upstart --sysconfdir=/tree/etc -->some of my errors: make[2] : ***[cfgfile.o]  error 1, + alot of cfgfile errors
<Keybuk> treepio: we'd need to see the actual errors
<treepio> on another system, I hatve to type em all :)
<Keybuk> unfortunately we can't see the other system's console, so don't know what they are unless you type them :-/
<treepio> ../nih/io.h:221: warning: 'warn_unused_result' attribute directory ignored
<Keybuk> that's just a warning
<treepio> cfgfile.c:880: error: 'RLIMIT_NICE' undeclared (first use in this function)
<treepio> cfgfile.c:880: error: 'each undeclared identifier is reported only once), cfgfile.c:880: error: for each function it appears in), 
<treepio> cfgfile.c:880: error: 'RLIMIT_RTPRIO' undeclared (first use in this function)
<AlexExtreme> missing include?
<treepio> those are my 4 errors. Looks like I have made some basic mistake somewhere. alot of warnings and stuff
<Keybuk> hmm
<AlexExtreme> hmm
<Keybuk> which version of kernel, glibc and gcc are you using?
<AlexExtreme> does /usr/include/bits/resource.h exist for you?
<Keybuk> those two limits were added in ~2.6.12 and I guess glibc 2.3.6
<treepio> resource.h exist
<treepio> kernel 2.4.31, gcc 3.3.6 .. checking glibc.
<AlexExtreme> ah
<AlexExtreme> 2.4.31 probably won't work, if they were added in 2.6.12
<Keybuk> yeah, wayyyyy too old version of Linux :)
<treepio> glibc: 2.3.5
<AlexExtreme> definitely too old :)
<treepio> bah :).. I'll boot into another system and try :)
<AlexExtreme> what distro are you using, out of curiousity?
<treepio> this isslackware
<AlexExtreme> which ver?
<AlexExtreme> 10.0?
<treepio> 10.2
<AlexExtreme> ah
<Keybuk> upstart needs 2.6.12 or later, gcc 4, glibc 2.4 etc.
<Keybuk> slackware still ships with 2.4 kernel?!
<treepio> ok, let me see what fedora has
<AlexExtreme> 11 ships with 2.6 afaik
<AlexExtreme> but patrick really didn't want to have 2.6, don't ask me why :/
<Keybuk> upstart isn't much use without 2.6 anyway
<treepio> probably because he had to do alot of work :)
<Keybuk> the entire point is that you'd want to use it with udev
<treepio> I just want to try and build a system, and decided upstart looked nice, ruby and all.
<Keybuk> most recent version of Ubuntu, Fedora and SuSE are all suitable
<Keybuk> Debian etch should be as well I believe
<treepio> I have FC5 on the comp I'm testing with
<AlexExtreme> btw Keybuk, when will development on all these fancy new upstart features start? ;)
<Keybuk> AlexExtreme: I'm working on some of the lower level library changes at the moment
<AlexExtreme> cool
<Keybuk> I imagine I'll get to upstart next week, and probably do the bulk of them over december
<AlexExtreme> sounds good
<treepio> kernel: 2.6.18xxx, glibc: 2.4, gcc: 4.1.0
<AlexExtreme> also, how do you get udev to emit events upon device additions/changes? add calls to initctl in the rules files?
<AlexExtreme> treepio: that should work
<treepio> AlexExtreme: thanks, I will try again
<Keybuk> AlexExtreme: yeah
<Keybuk> I plan to patch udev to do it directly as well
<AlexExtreme> ok
<AlexExtreme> and one last question: will the development of the replacement initscripts take place in the respective packages themselves or in a bazaar/cvs/svn/whatever repo?
<Keybuk> depends for which packages?
<Keybuk> they'll certainly be shipped inside those
<AlexExtreme> hmm
<AlexExtreme> ok
<Keybuk> but I suspect it'll be sensible to have a bazaar repository of them for people to use
<AlexExtreme> yes, definitely
<treepio> It's hard to learn the basics of linux..
<treepio> No errors this time though, thanks.
<AlexExtreme> :)
<treepio> can I jsut take the example files and throw in event.d and just change the disk layout?
<AlexExtreme> no
<AlexExtreme> the example files are for ubuntu
<treepio> oo
<treepio> :/
<Keybuk> replacing the init daemon of your system is quite a big undertaking for a novice
<treepio> I have made my disk layout, fstab and inittab. now I decided to try upstart(looks nice). do I have to reqrite everything ?
<treepio> Keybuk: you got it right. I am a nivice in this field.. so I decided to learn it.. Have to start somewhere
<Keybuk> to do upstart properly, you'd need to write everything to boot your machine, yes
<Keybuk> (in particular, upstart doesn't use inittab)
<treepio> Problem is that upstart is so new, it's hard to find any info on it.
<Keybuk> right
<Keybuk> it's still being developed
<treepio> hmm.
<Keybuk> we're only just at the point where we're about to begin replacing init scripts with upstart jobs
<treepio> Will I need to change much to have it work on my new system?. or should I just get the old unix or messy sysvinit stuff? (I will have to learn that too, so why not learn the good looking upstart)
<treepio> Wouldn't it be nice to have 17 people in here instead of 16 ;)
<treepio> Especially because I want to learn ruby too
<Keybuk> if you're installing a Linux machine from scratch, without any distribution, I'd definitely start with upstart
<Keybuk> it's just as useful as sysvinit today
<treepio> Keybuk: the other inits got alot of help and howtos. Can you help me with the files I will need to change ?
<treepio> For a start maby help me to find out how many and what files need changing
<Keybuk> I'm confused a little
<treepio> About what
<Keybuk> are you taking an existing installation of Linux and attempting to modify it to use upstart
<treepio> no
<Keybuk> or are you trying to build a Linux install from scratch?
<treepio> I'm using an existing distro to make a new
<Keybuk> right, so you're modifying an existing installation?
<treepio> no, I have made a seperate partition with empty dirs added fstab inittab and so.
<Keybuk> ah I see
<Keybuk> the first thing is you need to throw away that inittab file
<Keybuk> instead you'd need to write /etc/event.d files to match what you originally put in there
<treepio> I'm a pretty good sysadmin if I should say it myself.. but this, the basics are really hard.
<treepio> Probably easy once I have made it work just once..
* AlexExtreme sits and waits while KDE SVN builds...
<Keybuk> you'd need to write shell scripts to check and mount the disks, etc.
<Keybuk> all the usual boot-time tasks
<treepio> Keybuk: I can just change a few parameters in the example jobs right. I don't need something fancy. I just want to have it working and end up with a prompt someday.. then I can check and learn the scripts
<Keybuk> right
<Keybuk> the example jobs are based on the Debian / Ubuntu inittab
<Keybuk> you'd need to tweak them to match a different distribution (init is gloriously inconsistent)
<Keybuk> that'd make sure that the existing SysV scripts (/etc/rc*.d and /etc/init.d) are still run
<treepio> I will try to look up an inittab from debian/ubuntu
<treepio> Do I need those?, just removed the rc.d folder I had set up .. :)
<Keybuk> you don't need them
<Keybuk> but you do need what they did
<Keybuk> if you don't want the rc.d scripts, you'd need to rewrite them as /etc/event.d jobs
<treepio> Thanks, I want it real basic. don't care about compatibility .
<Keybuk> tbh, if you wanted a REALLY quick start ...
<Keybuk> you only need one file in /etc/event.d
<Keybuk> :)
<Keybuk> ----8<--------8<--------8<--------8<----
<Keybuk> on startup
<Keybuk> respawn /bin/bash
<Keybuk> ---->8-------->8-------->8-------->8----
<Keybuk> :p
<AlexExtreme> pff :)
<treepio> huh? :)
<Keybuk> that'd give you a root shell, and keep it running
<treepio> hehe
<treepio> I want that.
<AlexExtreme> you can just put init=/bin/bash on the kernel command line for that!
<Keybuk> AlexExtreme: true, but then it wouldn't be upstart supervised
<AlexExtreme> although, that wouldn't respawn it and it would kernel panic when the shell exits :p
<AlexExtreme> oh, and you'd need console owner ;)
<_ion>     ;-)
<treepio> No more panics, got enough problems with my cpu fan I died up with speaker cables.. the retention bracket is broken in all 4 corners :) so I tied it up with wires.. complains about heat problems.. hehe
<_ion> treepio: Upstart isn't made in Ruby, it's C code.
<Keybuk> _ion: cute
<_ion> Wouldn't that example also need 'console owner', btw? :-)
<Keybuk> yes
<Keybuk> heh
<AlexExtreme> i said that ;)
* _ion is blind.
<treepio> rebuilding upstart to the right location dunno why I made it in /tree/temp. :)
<Keybuk> use --prefix=usr/ --exec-prefix=/ --sysconfdir=/etc
<Keybuk> then install with make DESTDIR=/tree install
<Keybuk> that'll do the right thing
<treepio> ok built and ready.
<_ion> /usr
<Keybuk> likewise for things like libc, etc.
<Keybuk> (admittedly, if I were building a Linux from scratch, I would do away with /usr <g>)
<treepio> I did: ./configure prefix=/tree/usr sysconfdir=/tree/etc   (where /tree is a mounted partition)
<Keybuk> treepio: the problem with that is that upstart will be looking for /tree when it boots
<Keybuk> which won't exist if you mount that partition as the root
<Keybuk> (/tree/usr will become /usr)
<treepio> auch.
<AlexExtreme> ./configure --prefix=/usr --sysconfdir=/etc --exec-prefix=/ && make clean && make && make DESTDIR=/tree install
<treepio> I will just rm -rf stuff again
<treepio> AlexExtreme, Thanks
<treepio> I will get on to installing bash, etc etc. Thanks for all your help so far.
#upstart 2006-12-10
<eobanb> hi, what's the path to the upstart binary in edgy?
<eobanb> i assumed it would be in /sbin/ but i dont see anything like that there.
<cortana> eobanb: try dpkg --listfiles upstart
<cortana> i think it might actually be /sbin/init
<eobanb> oh okay
* mode/#upstart [+o _ion]  by ChanServ
* mode/#upstart [-s]  by _ion
* mode/#upstart [-o _ion]  by _ion
<Termina> Could anyone help me out? I'm having trouble compiling upstart on slackware 11, gcc3.4.6
<Termina> I get the following error on make:
<Md> upgrade gcc
<Termina> cfgfile.c: In function `cfg_job_stanza':
<Termina> cfgfile.c:880: error: `RLIMIT_NICE' undeclared (first use in this function)
<Termina> cfgfile.c:880: error: (Each undeclared identifier is reported only once
<Termina> cfgfile.c:880: error: for each function it appears in.)
<Termina> cfgfile.c:888: error: `RLIMIT_RTPRIO' undeclared (first use in this function)
<Termina> make[1] : *** [cfgfile.o]  Error 1
<Termina> make[1] : Leaving directory `/home/will/Desktop/upstart-0.3.0/init'
<Termina> make: *** [check-recursive]  Error 1
<Md> upgrade your libc headers then
<Termina> What version would you suggest?
<AlexExtreme> upgrade gcc, glibc and kernel
<Md> very recent
<Termina> kernel is 2.6.18
<AlexExtreme> gcc 4.x, glibc 2.3.6 and kernel 2.6.18
<Termina> Ah, thanks :)
#upstart 2007-12-04
<Jc2k> morning Keybuk 
<Jc2k> had a "7 degrees of kevin bacon" moment the other day
<Keybuk> oh?
<Jc2k> commented on your blog post and saw you had twitter
<Jc2k> you poked a guy about epiphany and webkit?
<Jc2k> i followed the link cause im interested in that combo
<Jc2k> and his twitter mentioned him going for lunch with our HTML/CSS guru
 * Jc2k was surprised
<Jc2k> it started a discussion in the office about the "good old days"
<Keybuk> heh
<Keybuk> how random
<Jc2k> indeed
<Jc2k> really liked your blog on metadata and tracker btw
<Keybuk> that was itching at me :-)
<Jc2k> its really itching me to try and monkey patch f-spot
<ion_> http://bugzilla.gnome.org/show_bug.cgi?id=350728
<Keybuk> Jc2k: I've been trying out the whole Web 2.0 thing
<Keybuk> so blog as twitter, flickr and last.fm on it
<Keybuk> facebook has blog and the rest
<Keybuk> want to get facebook onto blog or something
<Keybuk> have random plan to write a wordpress pilot log book plugin, and find some kind of gps unit and tracker
<Keybuk> so the theory being that if I blog about flying, there's an associated log book entry, and associated flickr gallery, and associated gps track map (google maps api ftw)
<Keybuk> and all of them are linked together
<Keybuk> but this involves copious free time
<Jc2k> my fb has twitter, pandora, my blog, amazon wishlist and stuff on. soon to be joined by flickr.
<Jc2k> but such cross posting sounds helishly more scary :)
<Keybuk> which ps pandora?
<Keybuk> what is pandora?
<Keybuk> sorry my brain fried there
<thom> US only recommendation based music service
<Keybuk> ahh
<Keybuk> I haven't quite got the hang of last.fm yet
<Keybuk> at least, not on the pull side -- the push is fine :-)
<Jc2k> thom: "US only".
<Jc2k> lol
<thom> Jc2k: it is. try it basically anywhere else and it tells you to bog off
<Jc2k> thom: well i must have US internets then
<Jc2k> it works fine at my house (UK)
<thom> http://www.pandora.com/restricted is what i get
<Jc2k> unlucky i guess :)
<Jc2k> nope for me it just starts playing
<Jc2k> even if i go there
<Jc2k> UK at work now
<Jc2k> different city
<Jc2k> different provider
<Jc2k> hell i even signed up with a .co.uk email :P
<thom> guess their detection sucks *shrug*
<Jc2k> great site :)
<thom> i was never that impressed when it did work tbh, last.fm recommendation radio gave me much better music
<Jc2k> really? for me its been pandora > jango > last.fm
#upstart 2007-12-06
<ion_> http://pages.plotinka.ru/~cyciron/chinauser.jpg
<Keybuk> I.
<Keybuk> HATE.
<Keybuk> UNIX.
<Keybuk> specifically Linux
<AlexExtreme> why's that?
<Keybuk> so there's this syscall
<Keybuk> waitid
<Keybuk> it has this nice WNOWAIT option
<Keybuk> it means you can "peek" at the top of the wait list without actually taking things off
<AlexExtreme> yep
<Keybuk> except the fucking wait fucking list can fucking change
<Keybuk> so if you waitid (..., WNOWAIT)
<Keybuk> and then waitid () afterwards
<Keybuk> you may have just taken a different event off than you had before
<AlexExtreme> ah
 * Keybuk beats his head against the wall
<Keybuk> init: Failed to detach traced test (#0) main process (6132): No such process
<Keybuk> ?!
<Keybuk> scott     6132  0.0  0.0   3668   136 ?        S    19:00   0:00 /tmp/test
<Keybuk> LOOK, THERE IT IS
<Keybuk> attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
<Keybuk> AND I KNOW YOU HAVE A TRACE ON IT
 * Keybuk gets angry
<Keybuk> oh, I know this one
<Keybuk> you can't detach from the process without first sending it a signal
<AlexExtreme> a quote from something I read today "UNIX is stupid"
<Keybuk> anyway
<Keybuk> :-)
<Keybuk> http://pastebin.com/m692d8cd2
<Keybuk> \o/
<AlexExtreme> neat
<Keybuk> FOUR WEEKS of fucking work
<AlexExtreme> makes my 103 line init program look like total bollocks ;)
<Keybuk> I feel like running out into the rain, screaming UUUUULLLLLAAAAAHHHH or something into the air
<Keybuk> and then checking myself into a mental asylum
<AlexExtreme> haha
<Keybuk> something which should be *so* simple
<Keybuk> now to tidy up the code, the scary if statements, etc.
<Keybuk> and commit
<AlexExtreme> <Keybuk> I.
<AlexExtreme> <Keybuk> HATE.
<AlexExtreme> <Keybuk> UNIX.
<AlexExtreme> <Keybuk> specifically Linux << I should digg that, "Ubuntu's Development Manager hates Linux" :P
<Keybuk> heh
<Keybuk> we decided that wasn't our job title anymore
<Keybuk> I'm "Ubuntu Desktop Team Manager" now
<Keybuk> (since my team is now the desktop team, rather than the "red team")
<AlexExtreme> heh
<AlexExtreme> fine, fine: "Ubuntu's Desktop Team Manager hates Linux"
<AlexExtreme> :p
<Keybuk> Colin is the Ubuntu Platform Team Manager
<AlexExtreme> I know I keep asking, but is there any possibility of a fully native upstart boot sequence getting into hardy?
<AlexExtreme> or rather, keep asking after every ubuntu release
<Keybuk> hardy? no
<Amaranth> I've been asking that since edgy :P
<Keybuk> remember, I'm not an ubuntu developer :p
<Keybuk> Upstart is my spare time, personal project
<Keybuk> so I'm more cautious than usual about "putting it in" simply because I know I don't have the time to fix it when it breaks
<thom> Keybuk: is it likely that canonical will commit resources to upstart in a reasonable timescale?
<Keybuk> thom: no idea, I'd probably be quite annoyed if they did since it's my project
<thom> how can canonical justify *not* commiting any resources to their default init system?
<thom> to put it more bluntly
<Keybuk> Canonical didn't commit any resources to sysvinit when that was the Ubuntu default?
<Keybuk> I don't think anybody does, in fact :-)
<thom> they didn't write it, and more than just ubuntu used it by default
<Keybuk> it seems like you're talking around a point you want to make?
<thom> not really
<thom> it just seems unfortunate that ubuntu has a chance to really lead something
<thom> and isn't
<Keybuk> Upstart development is slow mostly not because I don't have enough time
<Keybuk> but because it involves solving hard problems
<Keybuk> and nobody else seems interested in them
<thom> i'll try and put my point better in a minute; i need to finish a classics essay first :)
<Keybuk> ... :-)
<thom> a minute was maybe hopeful
<thom> references are PITA
#upstart 2008-12-01
<sinak> hello. I have installed upstart in debian using apt-get
<sinak> the pc didn't boot any faster
<sinak> do I have to do an extra configuration?
<Md> the debian upstart package is obsolete and more or less useless
<Md> installing it will not provide any real benefit
<sinak> I understood that
<sinak> is there any way to configure it to boot faster?
<Md> reinstall sysvinit and enable parallel boot
<sinak> mm ok
 * sinak bbz
<mbiebl> Md: what do you mean by obsolete?
<mbiebl> It's still using the sysv compat layer, yes
<mbiebl> but I wouldn't call upstart obsolete because of this ;-)
<unbuntucanuck> I have 8.04 Hardy Heron unbuntu and can't find any docs on upstart. I'm told i have it in the distro - what's up?
<ion_> /usr/share/doc/upstart/README.Debian.gz, http://upstart.ubuntu.com/ and the comments in the source.
<unbuntucanuck> cheers ion, I'm check the docs out!
<ion_> The state of documentation could be better. :-)
#upstart 2008-12-02
<ion_> http://whygitisbetterthanx.com/
#upstart 2008-12-03
<keesj> what is wrong when initctl list returns strange strings like service_5fapm
<keesj> and is it normal that initctl start with no argument segfaults
<keesj> what is the replacement for logd?
<keesj> what happens why is intrepid not uing 0.5?
<keesj> is 0.5 used somewhere?
 * keesj is getting a bad feeling
<ion_> 0.5 wasnât released early enough to get to intrepid.
<sadmac2> keesj: Fedora has had some stability issues with 0.5
<keesj> but I could look at fedora as ref platform
<notting> no, fedora 10 does not use upstart 0.5
<keesj> the main problem I have now is that initctl doesn't return the same output as it did on 0.3.8 
<sadmac2> keesj: we had issues with it when we /tried/ it I should say
<keesj> I really pushed to get the change to update...
<sadmac2> keesj: notting has a mystery box that 0.5 segfaults on. We still aren't sure what best to do about it.
<keesj> but the segfault I have when for example running start without arguments 
<keesj> or basic stuff like that. did you experiance such things or did I really screw up the setup
<sadmac2> I never noticed, but its possible
<keesj> and what does the output of initctl list or initctl status return?
<sadmac2> yeah, that stuff is different
<sadmac2> and weird
<sadmac2> for a variety of reasons
<keesj> but dbus doesn't make is easyer to understand for me
<sadmac2> brb kernel
#upstart 2008-12-04
<keesj> What could I put in /etc/init/init.conf ?
<shriven_> Hello. I'm having some trouble getting my upstart jobs to run on startup. Here is an example of one of my jobs: http://pastebin.com/d784c2e32
<shriven_> it's meant to keep that ssh connection open so that the port forwards stay open.
<shriven_> which seems to work great, but I have to start it manually.
<shriven_> with initctl start "jobname"
<shriven_> any ideas why this might not be working?
<keesj> shriven_: I can't see the job the site is dead
<keesj> try http://paste-it.net/
<keesj> does it have a start on startup or similar
<shriven_> yeah
<shriven_> I've tried "start on startup"
<shriven_> doesn't seem to do anything
<keesj> and what does inictl list say ?
<shriven_> possibly because it requires network and that starts it to soon? to test that I also tried some "start on network and filesystem" one sec and I'll get the paste bin.....
<shriven_> initctl just says they are "waiting"
<shriven_> and then as soon as I do initctl start on them they work fine
<shriven_> keesj: here is the one I tried without "start on startup" seemed to make more sense: http://paste-it.net/public/ice1969/
<shriven_> keesj: and here is the normal one that also doesn't work: http://paste-it.net/public/u8595e7/
<shriven_> my /var/log/boot is empty
<shriven_> I'm not really sure how to get any good information about what is happening. : (
<keesj> you can try to start upstart with some extra -vvv
<keesj> perhaps append console output to your jobs
<shriven_> hmmm
<shriven_> is there anyway I could force my jobs to log to somewhere like /var/log/upstart_jobs
<shriven_> I mean, I know I could make the commands inside the jobs do that, but that wouldn't help me see what upstart is doing so much
<shriven_> keesj: when you say adding extra verbosity, where would I do that?
<keesj> it's a upstart "stanza"
<shriven_> hmmmmm
<keesj> so if you add "console output" in your job andy error /stdout from that jobs will be shown on the screen
<shriven_> hmmmm
<shriven_> would that show information during boot?
<keesj> yes
<shriven_> ok. I'll give that a try.
<shriven_> can't reboot now as it's our router firewall. : ( thanks for the idea I'll try it later.
<keesj> :p
<keesj> be carefull
#upstart 2008-12-05
<plundra> Hey, would you look at that.
<plundra> Ok, got a quick question for you; I can't find any built in way of doing it, so, are you supposed to change directory and user in the pre-start script, or in the actual start-script?
<mbiebl> plundra: what do you want to do?
<plundra> Launch an application from a certain directory and with another user.
<plundra> So (cd /path ; sudo -u foo ./crap) or whatever :)
<plundra> Maybe using su instead.
<mbiebl> do it within a script .. end script
<mbiebl> and run su via exec
<plundra> Ok, so pre-start script, right?
<mbiebl> no script ... end script
<plundra> Ok, but why not start it within the script too?
<mbiebl> http://pastebin.ca/1276763
<plundra> Ah
<plundra> Cool, seem to work just fine, respawn and everything :)
<mbiebl> do you want to monitor the application?
<mbiebl> ah, you seem to have figured that out already
<plundra> Yeah.
<plundra> (But I do think a man-page would be a good thing... :-P Not just for initctl/start/stop/whatnot)
<mbiebl> plundra: there is a wiki
<plundra> That really bugs me, more often then not, random linux-projects are awesome, but the lack of documentation makes it unusable.
<mbiebl> so if you want to contribute
<mbiebl> that is a great start
<plundra> Wikis are for faqs and examples, you shouldn't have to use them for basic configuration-syntax etc. :)
<plundra> But that's just me, and I'm to lazy to contribute right now so I'll stop complaining :-D Just wanted to say it.
<plundra> Also, lunch! And thanks for your help.
<mbiebl> plundra: yeah, the man pages could definitely be improved
<mbiebl> but take a look at the home page http://upstart.ubuntu.com/
<mbiebl> especially scotts blog posts (linked on the front page) and the wiki
<plundra> After respawning too fast, will it try again later or do I manually have to start it again?
<plundra> Doesn't seem like it :-) So, is it possible to have a script runt WHEN it's stopped completly due to respawning too fast?
<plundra> For informing/whatever that it's the case.
<plundra> I know a respawn will emit a start/stop, and nothing special, but is there something that is emitted on respawning too fast?
<mbiebl> plundra: not sure, you can check with "initctl events" what events get emitted by upstart
<plundra> Ah, great :-) "stopped xxxx failed respawn"
<plundra> Hmm, can't get my "on xxxx/failed" (with and without respawn afterwards) to work.
<plundra> Ah!
<plundra> "on stopped xxxx failed" did the trick :)
<plundra> All though, I'd rather have that kind of stuff inside the xxxx-file it self.
<plundra> But on the other hand, now I can create a generic script I guess. That's probably better \o/ I bet you can get 'xxxx' as a parameter or variable somewhere 8-) *searches the wiki*
<plundra> Maybe not. I think I'm getting a UPSTART_EVENT=stopped, and nothing else. 
<johnflux> Hey all
<johnflux> How's upstart coming along?
<johnflux> on your webpage, I've noticed that dbus communication is now working?
<johnflux> Does this mean that I can find out, as a normal user, what services are running?
<mbiebl> johnflux: yes
<mbiebl> needs some tweaking, though
<Tv> So... I'd like to migrate from runit to upstart, but I'd like to retain the benefits of easy logging of stdout/stderr.. is there anything nice in upstart for that?
<Tv> i mean, i can make my logging library use syslog, but 1) syslog sucks 2) i'd like to separate the logs from different daemons better 3) i want to capture stdout/stderr to see bugs etc
<sadmac> Tv: do the syslog migration and use a better system logger :)
<sadmac> Tv: rsyslog seems pretty powerful
<Tv> sadmac: doesn't fix the "something writes to stderr" part of the equation
<sadmac> Tv: the problem we've had with that is that if whatever application which is reading/marshalling the stdout/stderr data gets killed, it takes all the applications it was watching with it (massive SIGPIPE)
<Tv> sadmac: yeah that's why daemontools/runit puts a more reliable process in between
<sadmac> Tv: its not reliability per se. It could be a deliberate kill, such as during shutdown.
<Tv> restarting the logger part is perfectly normal for the runsv/svlogd combo
<sadmac> yes, but that's a different kind of connection
<Tv> well yes and it's the thing keeping me using runit
<Tv> about twice a year i try to migrate away, and there's just nothing better..
<sadmac> Tv: then keep using runit :)
 * sadmac has no desire to dominate the planet
<Tv> i wanted to have instance jobs
<Tv> oh well
<sadmac> its a problem we've looked at a lot, and for what upstart does, none of the solutions we've found are quite right. But we'll get there
#upstart 2008-12-06
<Tv> actually to correct myself, IIRC runsv doesn't put a process in between, it just keeps the read side of the pipe alive in the parent, and starts a new log consumer if old one exits
<Tv> which would be doable in upstart, i guess
<mbiebl> Keybuk: hi
<Keybuk> hey
<mbiebl> About 0.5 and dbus:
<mbiebl> If want to schedule reconnect attempts within upstart, where should I best do that
<mbiebl> so it also works for systems, where dbus daemon is started *after* upstart
#upstart 2008-12-07
<sadmac2> Keybuk: wb
<Keybuk> hey
<sadmac2> Keybuk: you were on vacation?
<Keybuk> I was
<sadmac2> Keybuk: where do?
<sadmac2> *to
<sadmac2> or did you just stay home?
<Keybuk> San Francisco
<sadmac2> how was that?
<sadmac2> brb groceries
<Keybuk> it was awesome
<sadmac2> Keybuk: you're up early. or are you just not sleeping?
<Keybuk> I'm still in SF for UDS
<sadmac2> ah
<sadmac2> so this is fair hours then
<sadmac2> oh, it isn't even late there yet.
<ion_> keybuk: Welcome back.
<Keybuk> hey
#upstart 2009-11-30
<shyam_k> i was wondering how to boot into two different user configurations from the same root partition from grub itself! is it possible?
<sadmac_home> shyam_k: you could have different grub lines pass different kernel arguments. Then early userspace/init can read those arguments out of /proc/cmdline and boot the system differently
<shyam_k> oh wow /proc/cmdline was new to me.. great:)
<rohdef> why wont this: http://pastebin.com/d2d3c83e6 start automatically when the xbmc-live job is started? I placed it in /etc/init as I should (as far as I can read at least)
 * rohdef is wondering if there's any activity here
<JanC> did you check if the xbmc-live job was actually started?
<rohdef> JanC, I can see that it starts, since it's my complete gui, I'll try a reboot and check the status, but I'm very certain
<rohdef> JanC, "status xbmc-live" returns "xbmc-live start/running, process 750"
<rohdef> why wont this: http://pastebin.com/d2d3c83e6 start automatically when the xbmc-live job is started? I placed it in /etc/init as I should (as far as I can read at least), I also tried with other setups such as "start on startup" and "start on started hal". The script works fine when using "start krnet"
<sadmac> rohdef: did start on startup and start on hal work?
<rohdef> nopes
<sadmac> startup should definitely work
<sadmac> hmm
<rohdef> I gotta admit I'm a bit puzzled about this myself, first time trying though, but it seems very straight forward, which makes it wierder to me that it doesn't work
<rohdef> and it would be really typical if it's due to some very stupid detail :p
<sadmac> rohdef: anything in /var/log/messages?
<rohdef> sadmac I'll check just a sec
<rohdef> sadmac, ... a segfault that could be caused by my script, only way I can see it possible is if it runs too early, I'll just try some things
<rohdef> sadmac thanks a lot, your question lead me to the problem; premature execution
<rohdef> gotta get used to the thought of asyncronious execution (actually a really good thing, just have to get used to it ;) )
<sadmac> rohdef: heh. glad to help.
<superm1> Daviey and I were talking the other day and were wondering how doable a feature for upstart would be to add a dependency that only exists if it's installed. for us it would be only starting before mysql if it's there, otherwise wait for the standard other things  this same thing came up during UDS  to try to solve a problem in the proprietary x session
<Keybuk> I think it makes sense
<Keybuk> you'd need the logic to automatically disable a job if other things weren't there
<Keybuk> otherwise Upstart might think mysql exists if it was removed but not purged because /etc/init/mysql.conf still exists
<Daviey> Keybuk: would it be possible to make upstart "apt aware"?
<Daviey> ie, query the apt db?
<Daviey> well i know it *would* be possible, but is it feasible?
<Keybuk> you could do that
<Keybuk> if you had an addon that parsed the apt db and created states for each installed package
<Daviey> I imagine it would be quite expensive in time to do it for every upstart task.. but perhaps cache or add an apt hook?
<Keybuk> and then you'd need it updated each time you changed the db
<Keybuk> (you mean the dpkg db btw)
<Daviey> yeah
<Daviey> i'm trying to think of a way that is generic, rather than having specific code tied to an application/package
<Daviey> actually, "if upstart job mysql exists"
<Daviey> Does that make sense?
<Daviey> I'm happy to try and help, but a few pointers would be appreciated :)
<Keybuk> that's what I was thinking
<Keybuk> have a state for "job exists"
<Keybuk> while mysql or not exists mysql
<Keybuk> type thing
<Daviey> jah
<Keybuk> though that's somewhat booleanly mad
<Daviey> hmm
<Daviey> syntatically?
<Daviey> syntactically*
<Keybuk> yeah
<Keybuk> while foo or foo doesn't exist
<Keybuk> because while foo if foo exists is a bit more difficult to parse ;)
<sadmac> Keybuk: I've been thinking about an enable stanza
<sadmac> Keybuk: that would allow you to shift other jobs into auto mode when it came up.
<sadmac> Keybuk: basically its a way to do the "profiles" thing as jobs.
<Keybuk> how do you mean?
<sadmac> Keybuk: It works exactly like the before stanza, only its OR'd on the other end. for example, if you have 2 jobs with "before a" in them, then BOTH need to be running for a to start. If you have 2 jobs with "enable a" in them, then a can start as long as either one is running
<Keybuk> still not following?
<sadmac> Keybuk: ok, lets start with the practical case. So you had that idea to let the user list services they wanted to start at boot on the kernel command line right?
<Keybuk> right
<Keybuk> well
<Keybuk> more to create pretend services
<Keybuk> but yes
<sadmac> Keybuk: basically, we'd have the kernel command line always name one service called "default"
<sadmac> Keybuk: and the default service definition would just have stanzas like "enable hal / enable tty / enable X / enable dbus / enable ..."
<Keybuk> I'd rather do that the other way around
<Keybuk> in the HAL definition, have "while default"
<sadmac> Keybuk: that makes it hard to create new profiles.
<Keybuk> I don't think profiles are common enough to worry about it
<sadmac> Keybuk: so if I wanted to create a new set of services called "turbo_mode" that had some different configuration, I'd have to edit every job I wanted to start in that mode.
<Keybuk> sure
<Keybuk> jobs start by default anyway
<Keybuk> what you really want is a profile that disables jobs you don't want
<sadmac> Keybuk: usually if you care enough to have profiles you have a huge number of services to worry about, and the set you want actually /running/ at any one time is much smaller than that.
<Keybuk> right, so you're talking about someone who'd have upstart set up that all jobs were in manual mode by default
<Keybuk> and explicitly enable the ones they wanted?
<sadmac> Keybuk: sort of. basically all jobs would be in manual mode always unless hit by an "enable" stanza.
<sadmac> Keybuk: the security people are going to murder you if you're not careful about this "default to running" thing :)
<Keybuk> err
<Keybuk> Ubuntu and Debian have always done "default to running" :-)
<Keybuk> if you didn't want it running, why did you install the package?
<ion> Indeed
<sadmac> Keybuk: you didn't. A partial exploit allowed an attacker to get some privileges on the box. He was then able to install a service and get even more privileges because the service was turned on for him.
<Keybuk> well
<Keybuk> I guess Fedora defaults to letting anyone install any package
<Keybuk> :D
<sadmac> Keybuk: you're connecting exploits that get you one operation on one component and giving them the effectiveness of any exploit anywhere in the universe.
<sadmac> Keybuk: we did for a bit actually... did you follow that? People were unhappy.
<Keybuk> but going back to non-trolling for a second
<Keybuk> I guess we're going to have to support the RH not-enabled-by-default mode
<Keybuk> even if in Ubuntu we still enable-by-default
<Keybuk> in that circumstance, I guess your proposal makes a crazy sense
<Keybuk> though you'd have to manually update that job file each time a package is installed?
<Keybuk> (to start it?)
<sadmac> it also means profiles and services are one object.
<sadmac> Keybuk: not necessarily... let me think about that
<sadmac> Keybuk: part of the advantage here is "profiles are services" so we get all the same crazy tools to wire them together.
<Keybuk> right that bit makes sense
<sadmac> Keybuk: we still allow jobs in folders, right? You could enable by path.
<sadmac> Keybuk: enable defaults/*
<sadmac> ah, hello chkconfig. I remember you. Good to see you again. Have you been well?
<sadmac> its not exactly chkconfig though, because you shouldn't need symlinks
<Keybuk> yeah that kind of thing
<sadmac> Keybuk: the other issue is you can't do a "disable" stanza because then you get a race between the service and the profile that turns it off.
<Keybuk> indeed
<Keybuk> enable makes sense though
<Keybuk> there'd be a companion option (/etc/init.conf returns? :p) to actually enable the enable stanza
<Keybuk> ie. if you were in enable-by-default mode, enable would do nothing
<Keybuk> it only applies in disable-by-default mode
<sadmac> Keybuk: Ooh, idea: you could have a "disable" stanza that just complements the enable stanza. So if /in the same job/ you had "enable foo* / disable food" you would enable anything starting with foo except the service called "food"
<sadmac> Keybuk: then, we ship as I described, and you guys just ship a profile with "enable *". the user can then add disables to the bottom of that profile for explicit disabling.
<Keybuk> or we could support zsh globbing
<Keybuk> foo*~food
<sadmac> Keybuk: I'd rather do glibc regexen
<sadmac> Keybuk: at any rate zsh globbing would be less convenient for the use case I mentioned
<sadmac> Keybuk: this way is actually really nice, because you can do either. Your single-user profile can have "enable this-one-thing", and your multi user profile can have "enable * / disable just-this-one"
<sadmac> I don't think there's any other system who's effect can't be achieved this way, and its cheap to do. It seems right.
<JanC> having a standard way to enable & disable services would also be useful for those who want to create a web or graphical UI to enable/disable services...
<sadmac> and this way ends up being pluggable too, so tools won't step on each other's toes.
#upstart 2009-12-01
<harovali1> hi, what's the correct way of deactivating gdm from upstart in karmic ubuntu ?
<ion> If you want to kill it, stop gdm. If you want to prevent it from ever starting, you might e.g. comment out the âstart on...â line by adding # in front of it, or making /etc/X11/default-display-manager an empty file.
#upstart 2009-12-02
<yodgo> !ops
<jarl> Hi I need a little help making my own upstart conf file. Is anybody active here now?
<juan__> I'm trying to use upstart to launch x as me (directly instead of using xdm/etc), but i'm no sure what to put as started on, is there a state for "boot finished" or would i be better of finding out xorgs dependancies (HAL and filesystems?)?
<ilowe> hi guys, is there a way for me to specify a command to stop a job?
<sadmac> ilowe: I don't understand the question
<ilowe> sorry: I have a command that starts a process but I need to use a different command to shut it down gracefuuly
<sadmac> juergbi: depends on how your distro sets up upstart.
<ilowe> I don't want to have the process simply terminated by PID 
<sadmac> ilowe: try putting it in pre-stop
<ilowe> will stop succeed even if the PID no longer exists? I mean, pre-killing it in pre-stop won't cause an isseu?
<sadmac> not entirely sure. I don't think it will be a disaster even if there is a little hiccup.
<ilowe> sadmac: killer! that worked perfectly! Thanks
<sadmac> ilowe: awesome
<ilowe> any ideas on how to respond to custom events? I want my job to start on runlevel 2 as well as when abitrary event "xyz" occurs (via emit)
<ilowe> I've tried adding "start on xyz" to my job but "initctl emit xyz" doesn't seem to start the job
<sadmac> ilowe: you had it right... dunno what the issue is
<ilowe> sorry, I was trying to put the two conditions on the same line with an "or" which wasn't working
<sadmac> ilowe: what version of upstart?
<ilowe> splitting them on two lines works beautifully
<mbiebl> ilowe: that must be 0.3.x then
<ilowe> 0.3.9-8
<sadmac> ilowe: yeah. in 0.6 you can't have multiple start on lines and have to use or. in 0.3 there's no or and you have to use multiple start on lines
<ilowe> is there a PPA build? I'm still on Jaunty on most of my servers.
<ilowe> how would I use instance jobs with events to start those jobs? I mean, I'd like to emit "xyz" and have a bunch of instances of a job start.
<sadmac> ilowe: not sure if you can in 0.3
<ilowe> OK, how 'bout in 0.6?
<sadmac> if the environment from the event causes the instance's name to evaluate to something not used a new instance is born
<wasabi> ilowe, I use a task job to start instances.
<wasabi> Oh, .3
<ilowe> wasabi: I can use 0.6 if I have to... I'm figuring out the upgrade path right now...
<JanC> running 0.6 on jaunty isn't a good idea probably, so you would have to upgrade to karmic I think
#upstart 2009-12-03
<danderson> Hello all.
<danderson> I'm trying to puzzle out what the difference between 'expect fork' and 'expect daemon' is in an upstart config.
<danderson> I'm writing a config for tpmd (TPM emulator daemon). When exec'd, it backgrounds itself. Using 'expect daemon' makes the start/stop commands hang, whereas 'expect fork' starts and stops the daemon as expected.
<danderson> what is the actual difference between these two expects?
<juan__> I'm not sure but this entry seams relevant http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/
<danderson> well, that talks about daemons and how to track them in general. I'm more looking for the distinction upstart makes between 'fork' and 'daemon'.
<drocko> hello
<drocko> i'm trying to write an upstart job to run when my system starts up, but it never seems to run. I can run it after the system is booted and everything is fine, but i really need this to run at startup. Can someone help me out?
<babel> I don't think you will get some helpful information here. I asked some question like you a few days ago without any help. maybe you should try the mailling list next ...
<drocko> rats
<drocko> have you made an upstart job that has worked at boot?
<drocko> I feel like im missing something that is probably obvious
<drocko> like is there a command that you have to run to notify upstart that there are new scripts in /etc/init ?
<babel> i tried to create a job that should be started before kvm shutdown (i would like to shutdown some kvm guest gracefully). i was able to run the job fine via an emit event, but I wasn't able to find a way to invoke the script before kvm was killed.
<drocko> hm
<drocko> dang
<babel> drocko: no, this is done via inotify (and there you shouldn't need such a tool or command)
<drocko> yeah that is what i figured
<drocko> so let me ask you another question
<babel> the upstart doc is somewhat ...
<drocko> when upstart runs these jobs, it's running them as root, right?
<babel> as fas as i know, yes.
<babel> far
<drocko> http://pastebin.com/d40ca71b9
<drocko> this is my job
<drocko> and it works, just not on boot
<babel> start on stopped rc[2345] -> start on runleven[2345]
<babel> runlevel
<drocko> I'll try that
<drocko> i dunno
<drocko> wow, thanks babel. that worked!
<drocko> also it means that this bullshit answer is totally wrong: https://answers.launchpad.net/upstart/+question/83223
<babel> maybe.
<drocko> yes
<drocko> maybe 
<drocko> it's all voodoo
<babel> now, better docs would help.
<drocko> yeah, you know it's the same problem with grub2
<drocko> like
<babel> and something to make a dry-run
<drocko> people think that a wiki would like really be great for documentation
<drocko> because everyone could read it and contribute
<drocko> but really it turns into like
<babel> if the wiki is up to date that's true but.
<drocko> a collection of cryptic notes 
<drocko> right
<drocko> that are out of date
<Keybuk> the trouble is, very few people are good at writing good documentation :)
<Keybuk> danderson: the difference is how many forks upstart expects ;)
<Keybuk> "expect fork" means Upstart counts one fork()
<Keybuk> "expect daemon" means Upstart counts two fork()s
<danderson> aaah.
<danderson> I see.
<Keybuk> to "properly" daemonise, a process needs to fork twice
<danderson> so, this daemon I have isn't actually daemonizing properly, just forking into the background
<Keybuk> of course, most things don't properly daemonise, so just "expect fork" is enough
<danderson> right, I know; I assumed that the author of the software knew that as well :-)
<Keybuk> the fact you need to be careful is because we use ptrace() to track this stuff
<Keybuk> which is so less than ideal it's not even funny
<danderson> (I'm just building an ubuntu package for his software, and writing the appropriate upstart config)
<danderson> ouch ptrace().
<danderson> but yeah, I don't see any other way to figure that out :(
<Keybuk> there are some good new ways
<Keybuk> kernel proc events and stuff
<danderson> hmm, is the wiki read/write?
<Keybuk> yes
<danderson> perhaps I should try to start a "configuration writing manual" with some of this knowledge
<sadmac> Keybuk: kernel proc events? Is that something new? reading material?
<Keybuk> sadmac: proc connector, proc events, proc stats
<Keybuk> just different names for the same thing
<sadmac> Keybuk: ah
<danderson> oh, and also, while people are around: woot upstart, thank you for building it! It's so much saner than futzing with init scripts it's unbelievable.
<drocko> hm
<drocko> alright so next challenge. my job runs at boot, but it needs to have the network up and running for it to be successful. how can i build in a dependency like that?
<babel> try start on net-device-up
<drocko> should i remove the start on runlevel [2345] or should I use both?
<drocko> like start on (runlevel [2345]
<drocko> and net-device-up)
<drocko>  ?
<babel> just start on net-device-up
<babel> since you only depend on these event.
<drocko> alright let's see what happened
<drocko> babel2: thanks for the help. i think I got it sorted
<babel2> no problem, share your knowlegde next time with some newbie :)
<drocko> yeah definitelty
<drocko> upstart is cleaner than like launchd on OS X and makes a little more sense than svcs on solaris, but like the documentation has to get there
<drocko> Maybe i'll add what i've found to the wiki
<mbiebl> Keybuk: around?
<Keybuk> yus
<mbiebl> having a problem with karmic and bridge devices
<mbiebl> the system in question has two bridge devices configured
<mbiebl> which are attached to kvm instances
<Keybuk> yeah they don't work
<mbiebl> ah, ok
<mbiebl> seems the libvirt-bin init script tries to start the kvm instances beforce br0 and br1 are up
<Keybuk> yes
<mbiebl> Keybuk: is there a solution available?
<Keybuk> actually nothing brings up br0 and br1
<Keybuk> not that I know of
<mbiebl> well, the devices are available after some time and if I add a sleep 30 inside the libvirt-bin init script, I can get it to work
<mbiebl> this is of course fugly
<wasabi> is there an event when br* comes up?
<wasabi> net-device-added seems to be setup
<ion> net-device-up, /etc/network/if-up.d/upstart
<wasabi> ahh there iti s
<wasabi> was wondering who was emitting it
<mbiebl> I havea network-interface (br0) start/running
<mbiebl> and the same for br1
<wasabi> I'm kind of working on the same, with init scripts for virtualbox.
<wasabi> Haven't yet tackled this. ;0
<mbiebl> Keybuk: still around?
#upstart 2009-12-04
<Younder> I am trying to start ubutu in runlevel 3 with text mode
<Younder> However gdm is started by upstast with a script /etc/init/gdm.conf
<tormod> Younder, to boot without X just add the "text" boot option
<Younder> in grub's menu.lst?
<tormod> runlevels are yesterday
<tormod> yes, or just at the grub prompt if you don't want to save it
<Younder> ok 'll try that
#upstart 2009-12-06
<tormod> how can I get the nih_debug messages? ENV or recompile?
<ion> init --verbose
<ion> Or was it init --debug
<tormod> actually it is not upstart I am looking at, but ureadahead, which also uses nih
<ion> ureadahead --debug
<tormod> thanks
#upstart 2010-12-07
<twb> Does "init --verbose --debug" stack the two options, or are the mutually exclusive?
<richcollins> How should I start a process as un unprivileged user?
<twb> I use start-stop-daemon, but that's probably wrong for upstart
<twb> In /etc/init/uec-component-listener.conf I find
<twb> exec start-stop-daemon --start --chuid eucalyptus:eucalyptus --exec /usr/sbin/uec_component_listener
<twb> Stuff like apache seems to still be using /etc/init.d/ as at Lucid.
<richcollins> How do I debug "Unknown job" messages?
<richcollins> I added the file to /etc/init.d
<richcollins> Do I need to load the file or something?
<JanC> upstart jobs go into /etc/init/
<richcollins> JanC: Ah ok thanks
<richcollins> The output from start was: luciebot-server start/running, process 20284
<richcollins> but I don't see the process and the log file is empty
<richcollins> Is there a log for upstart?
<richcollins> Ah daemon.log?
<richcollins> Is the exec command only for the process that you want to start or can you use it for other commands within a script block?
<richcollins> exec cd /some/path
<richcollins> ...
<richcollins> JanC: Can you create symlinks in /etc/init to files elsewhere? 
<JanC> if you use a script block, no need for exec?
#upstart 2010-12-08
<Keybuk> >>> mountall.Get("com.ubuntu.Upstart0_6.Job", "start_on", dbus_interface="org.freedesktop.DBus.Properties")
<Keybuk> dbus.Array([dbus.Array([dbus.String(u'startup')], signature=dbus.Signature('s'))], signature=dbus.Signature('as'), variant_level=1)
<Keybuk> \o/
<Keybuk> >>> plymouth.Get("com.ubuntu.Upstart0_6.Job", "start_on", dbus_interface="org.freedesktop.DBus.Properties")
<Keybuk> dbus.Array([dbus.Array([dbus.String(u'starting'), dbus.String(u'mountall')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'runlevel'), dbus.String(u'[016]')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'stopped'), dbus.String(u'gdm')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'stopped'), dbus.String(u'kdm')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'/OR')], signature=dbus.Signature('s')), 
<Keybuk> dbus.Array([dbus.String(u'stopped'), dbus.String(u'xdm')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'/OR')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'stopped'), dbus.String(u'lxdm')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'/OR')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'/AND')], signature=dbus.Signature('s')), dbus.Array([dbus.String(u'/OR')], signature=dbus.Signature('s'))], 
<Keybuk> signature=dbus.Signature('as'), variant_level=1)
<Keybuk> wheee
#upstart 2010-12-09
<yaaang> what's the precise connection between upstart and init.d/rc's? if i have an upstart conf in /etc/init/ with "start on runlevel [2345]" do i still need to create a symlink to /lib/init/upstart-job and run update-rc.d on that?
<yaaang> i notice a bunch of services have presence in both directories, which is confusing
<rgl> hello
<rgl> for some reason, service mongrel2 status says "mongrel2 start/killed, process 12548
<rgl> " but there is no process 12548 ... doing a service mongrel2 stop does not work either ... how can I "unstuck" upstart?
<ashb> rgl: sounds like its forking. 'expect fork' stanza or something along thosel ines in the config
<ashb> also check the log to make sure its not just respawning really fast then stopping
<ion> Donât add an âexpectâ stanza unless youâre *absolutely* certain of the forking behavior of the main process. Otherwise youâll confuse Upstart. A future release will have a better implementation of following forks.
<rgl> ashb, I have respawn like in other upstart files (eg. the cron one). 
<ashb> i was just guessing - my upstart knowledge is teeny
<rgl> oh w8... respawn does not seem the same as fork!
<rgl> err
<ashb> yeah respawn says restart if it crashes/stops(?)
<rgl> on the previous version ... I was using expect fork too. but it does not work either.
#upstart 2010-12-10
<ashb> isn't there another one? 'deamonize' or something like that
 * rgl RTFM
<rgl> http://upstart.ubuntu.com/wiki/Stanzas?highlight=(expect)|(fork)#daemon it says "expect fork" replaces daemon :|
<ashb> check your logs then
<ashb> and/or strace it
<rgl> nothing in the logs :|
<rgl> how do I strace it? you mean, strace init?
<ashb> oh fair point that wouldn't work
<ashb> i was thinking strace start mongrel2, but that doesn't actually spawn it dierctly
<yaaang> anyone able to help me with this question?
<yaaang> https://lists.ubuntu.com/archives/upstart-devel/2010-December/001343.html
<jetienne> q. when i put a symlink in /etc/init, upstart doesnt seem to accept it. i need an actual file in there. is there a way to make it accept symlink ?.
<jetienne> when a upstart doesnt start, where the output is logged ?
<jetienne> q. is there a way to do a "initctl stopifrunning" ? initctl stop is reporting an error if not running
<jetienne> same question for "startifnotyetstarted"
<ViRUS> I've got some problem. It's an ubuntu system, but it seams that you guys can help me better.
<ViRUS> When booting up the system no gettys are started and it seams upstart is not doing anything
<ViRUS> runlevel reports "unknown" and calling initctl yields "Warning: Fake initctl called, doing nothing"
<ViRUS> I did now execute "init 2" and the system starts the gettys and everything else. Now I'm confused why this happens. Why does it end up in an "unknown" runlevel?
<JanC> did you change anything on your system?
<ViRUS> no. it's a fresh ubuntu 10.10 server installation. Only thing that is special about is is the software raid. Though it is assembled correctly and for some reason even sshd is started. Without sshd I'd not even be able to look at it. So I'm glad dhcp and ssh works regardless of the weird runlevel.
<ViRUS> and for some reason "initctl" still reports - even after setting the runlevel - that it's "Fake initctl" was called.
<JanC> hm, tty1 etc. get started after the rc task is run with a RUNLEVEL parameter, so it seems like that doesn't/didn't happen...
<JanC> if I understand correctly "unknown" runlevel means $RUNLEVEL & $PREVLEVEL are not set and there is no runlevel record in /var/run/utmp
<ViRUS> I'm puzzled. I never really understood upstart and I'm kinda missing that manhole to look and debug what's going on.
<JanC> ViRUS: the "fake initctl" might be because you start it as 'init 2' instead of 'telinit 2'
<JanC> changing to runlevel 2 should normally happen when the rc-sysinit task runs
<JanC> which runs when "start on filesystem and net-device-up IFACE=lo"
<JanC> ViRUS: maybe there is something that caused one of those 2 events not to happen
<ViRUS> hmm, is there any log? How can I check this?
<ViRUS> it really seams rc-sysinit is never called
<ViRUS> Is there a way to enable debugging (logging of events, etc.)
<JanC> there is some info here: http://upstart.ubuntu.com/wiki/Debugging
<JanC> maybe also search https://bugs.launchpad.net/ubuntu/+source/upstart for known bugs...
<ViRUS> I'm just looking at the output of âdebug
<JanC> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/543506 <-- might be this bug
<ectospasm> I restarted, and my upstart jobs didn't start.  Is there a specific way to tell upstart to start these jobs?  "start on ..." doesn't seem to be enough.
<ViRUS> ok. gtg. I think I'll just switch to Ubuntu LTS and see it that helps. Makes much sense for a server anyways
<jetienne> q. is there a way to do a "initctl stopifrunning" ? initctl stop is reporting an error if not running ? same for "startifnotyetstarted"
#upstart 2010-12-11
<ectospasm> How do I tell upstart to start my custom job on boot?  I have "start on (startup \ and filesystem \ and networking)" but the service doesn't start when I reboot.  When I issue "start <service>" from the shell, the service starts as expected.  Do I have to issue the equivalent of update-rc.d command to get this working?
<ion> Drop the âstartupâ, and change ânetworkingâ to âstarted networkingâ assuming youâre running Ubuntu.
<ectospasm> ion: OK, thanks
<ectospasm> ion: heh, I do have started networking.  startup removed now
<ectospasm> ion: is there anything else I need to do with that?  Or will upstart pick it up on next boot?
#upstart 2011-12-05
<linas> whoopsw, netsplit, reposting
<linas> JanC, sorry, it was for ubuntu 11.10 oneirc
<linas> I opened a bug report for this, its ... 899795
<linas> https://bugs.launchpad.net/upstart/+bug/899795
#upstart 2012-12-03
<xnox> jodh: there is a typo in the failed case.
<xnox> jodh: the filename will not be defined :P
<jodh> xnox: need a few more bytes of context - we're talking about lp:~xnox/upstart/fix-qemu-test presumably?
<xnox> jodh: yes, mere re-reproposal is on the way.
<xnox> jodh: https://code.launchpad.net/~xnox/upstart/fix-qemu-test/+merge/137517
<xnox> s/mere/the/
<jodh> xnox: ah! I'd missed that. Could you also therefore wrap the unlink in assert0() like: 'assert0 (unlink (filename))'
<xnox> jodh: no, since it may not exist.
<xnox> cause it's in the maybe-failed code path.
<jodh> xnox: gah - agreed :)
<jodh> xnox: btw - I raised bug 1085836 just now. It would be great to have this facility for Raring, particularly for the DEP-8 tests. We can discuss with stgraber later.
<xnox> jodh: interesting. /me ponders if we can re-exec ourselfs under sudo for a test wrapped in NEEDS_ROOT
<stgraber> xnox, jodh: one option would be to have a separate "root-check" target or similar which requires root permissions, those wouldn't be called at build time but could be called under sudo on the autopackagetest machine
<jodh> stgraber: right.
<xnox> jodh: https://launchpad.net/~xnox/+archive/scratch/+build/4031890
<xnox> jodh: stgraber: https://buildd.debian.org/status/fetch.php?pkg=upstart&arch=amd64&ver=1.6-3&stamp=1353265111
<xnox> Kernel: Linux 2.6.32-5-amd64 amd64 (x86_64)
#upstart 2012-12-04
<soren> jodh: (Moving here, as it's not really on topic for #launchpad) So what are the current requirements for (current) upstart?
<jodh> soren: wrt the kernel version '2.6.24' according to Keybuks top-level README. The PPA environment appears to provide 2.6.24-32-xen. Upstart is built and run in many other environments and we've never seen the test failures currently seen when attempting to build lp:upstart in a PPA env.
<jodh> soren: so that kernel version _may_ be problematic although I do not understand how the kernel version could cause the failure we're seeing.
<soren> jodh: Do older versions fail in the same way? Did the environment change?
<jodh> soren: older versions of what? We have never been able to build lp:upstart in a PPA env sadly, due to the issue outlined.
<soren> jodh: Oh, I thought it was a new issue.
<soren> jodh: Wow, so upstart has never built in PPA's? Ever?
<soren> https://launchpadlibrarian.net/124769395/buildlog_ubuntu-quantal-amd64.upstart_1.5-0ubuntu9_BUILDING.txt.gz
<jodh> soren: correct - I was the first to try it I believe some months back and have been trying to work out what the problem is.
<jodh> soren: no - not the ubuntu build, the build of lp:upstart.
<xnox> soren: it does build, but cannot run/pass upstream test-suite. But the reason why we want to build in the ppa is to have daily-builds and test-suite runs.
<soren> xnox: Doesn't the  Ubuntu build run the test suite?
<xnox> soren: it does, but not on every upstream commit & we are doing a lot of upstream development this cycle.
<soren> xnox: I don't follow. So the upstream test suite is run by the Ubuntu builds and these Ubuntu builds work in PPA's, but not "upstream" builds. Am I correct so far?
<xnox> soren: not quite.
<xnox> soren: lp:ubuntu/upstart is quite modified from lp:upstart. When we merge lp:upstart into lp:ubuntu/upstart and upload into the ubuntu archive, non-virt distro builders build it / ran the test-suite and all is fine.
<xnox> soren: but when we upload just lp:upstart into the ppa (without ubuntu specific modifications) it builds, but the test-suite hangs the virt PPA.
 * xnox is now not sure if that's what you meant or not.
<soren> I think so.
<soren> I'm just a wee bit surprised that we have one version that works and another that doesn't (which is a pretty good starting point for pinpointing the problem if it can't be done by simple code inspection), yet instead of fixing the problem we're replacing the build infrastructure to avoid it.
<soren> Not my call, obviously, but I'm just concerned that the issue causing this failure is going to come bite me in the behind one day.
<jodh> soren: We are surprised too
<jodh> soren: is there any plan to upgrade the PPA env environment to atleast lucid?
<soren> jodh: I have no idea.
 * soren is not involved with Launchpad
<soren> Sorry if I gave that impression.
<jodh> soren: ok. so back to #launchpad? :-)
<xnox> jodh: I am looking at the multiple directories support and upstart does cleanly support multiple conf sources, but the libnih option parsing just uses the last one passed.
<xnox> jodh: so the question I have, is do we want syntax similar to:
<xnox> --configdir dir1 --configdir dir2
<xnox> or 
<xnox> --configdir dir1:dir2
<xnox> in the first-case libnih should get support for building up a nih_list of options, in the latter case proper : splitting and escaping validation needs to be done.
<xnox> it is a bit moot, since --user (or whatever option we will use for user sessions) will default to a list of xdg-config environment variables with fallbacks.
<xnox> fallbacks to default xdg locations....
<jodh> xnox: I'd prefer '--confdir dir1 --confdir dir2'
<xnox> jodh: ack.
<xnox> jodh: i will look into tricking libnih to build a nih_list from those.
<jodh> xnox: this is possible with nih by utilising an NihOptionSetter. See ignored_events_setter() in initctl.c for an example.
<jodh> xnox: nih will 'visit' each argument, and call the provided setter function each time.
<xnox> jodh: should it be --configdirs dir1 --configdirs dir2, cause currently --configdir dir1 --configdir dir2 results in dir2 being used by upstart.
<jodh> xnox: so all you need to do is create a NihListEntry list and add the paths to it.
<xnox> jodh: interesting. Let me look that up.
<jodh> xnox: it should be '--confdir' as that is the current option name.
<xnox> ok.
<jodh> xnox: so yes, in the simplistic case, "the last option wins", but if you use a setter function, you have full control.
<xnox> jodh: it's just feel uneasy changing the meaning of current command line arg parsing.
<xnox> s/feel/feels/
<xnox> hence the argument to support both --confdir & --confdirs.
<xnox> but that can be confusing.
<jodh> xnox: we're not changing the current behaviour though: '--confdir /foo/bar' should still continue to work.
<xnox> jodh: '--confdir /foo/bar --confdir /bar/foo' today vs in future is changing, unless we reverse the confsource list (e.g. the last one has highest priority, i.e. first in the confsource list)
<xnox> that should work.
<jodh> xnox: well from the Upstart perspective nobody should be even using --confdir let alone specifying it multiple times :-) We could always add in a --traditional flag maybe but I'm not convinced its worth it.
<jodh> xnox: what we could do is only use the new behaviour if --user is specified and document clearly in init(8) the impact using --user has on --confdir.
<xnox> jodh: well we should have been erroring out on passing multiple confdirs, but we cannot turn the time back.
<xnox> jodh: the "backwards" compatible way is to then list --confdir /etc/xdg/upstart --confdir /etc/xdg/xdg-ubuntu/upstart --confdir ~/.config/upstart
<jodh> xnox: that's not how nih works by default. To do that, every option would need to have a setter which just shouldn't be necessary.
<xnox> this way it looks good to me ( the ignorant) LTR speaker.
<jodh> xnox: you forgot ~/.init :)
<xnox> jodh: the impact difference is that in the past only the jobs in the last confdir were used, but now the unique onces in the previous dirs will also be used.
<xnox> jodh: but that does not help with the environment variable.
<xnox> jodh: what priority UPSTART_CONFDIR has? =)
<xnox> and XDG_CONFIG_HOME? =)
<jodh> xnox: we have (attempted to) document this behaviour here: https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Configuration_Files_for_User_Jobs
<jodh> xnox: although I've never heard of UPSTART_CONFDIR :)
<xnox>  * CONFDIR_ENV:
<xnox>  *
<xnox>  * If this environment variable is set, read configuration files
<xnox>  * from the location specified, rather than CONFDIR.
<xnox>  *
<xnox>  * Value is expected to be the full path to an alternative job
<xnox>  * configuration directory.
<xnox>  **/
<xnox> #ifndef CONFDIR_ENV
<xnox> #define CONFDIR_ENV "UPSTART_CONFDIR"
<xnox> #endif
<xnox> =))))))))))))))))))))))))))))))
<xnox> jodh: blame says 1284.1.1 james.h =)))))
<jodh> xnox: that was added for testing and is not a documented "external".
<xnox> jodh: shows up in the gtk-docs I generated locally ;-)
<xnox> jodh: what does CONFFILE "/etc/init.conf" used for?
<xnox> is it in the case when upstart is used as sysvinit compat mode only? and /etc/init.conf bootstraps that and that's it
<xnox> ?
<soren> jodh: Well, what I wanted to discuss was about upstart, not Launchpad. Hence the move here. But meh.
<jodh> xnox: init.conf is not used at all right now.
<xnox> jodh: sure, but it's loaded as a conf source by default =)
<jodh> xnox: ignore it.
<xnox> =))))
<xnox> jodh: "Currently, PID 1 looks for a users Job configuration files in directory $HOME/.init/. This behaviour will be retained."
<xnox> as in the PID 1 will continue to parse those, or will the usersession upstart parse those at the highest priority?
<xnox> jodh: and the override file will only "work" next to the job file.
<xnox> e.g. ~/.config/upstart/foo.override will not override /etc/xdg/upstart/foo.conf, but /etc/xdg/upstart/foo.override will override /etc/xdg/upstart/foo.conf
<jodh> xnox: that sentence is certainly ambiguous. Certainly only the Session Inits should be considering ~/.init for enhanced sessions. I think we should document ~/.init as deprecated, but honour it for now as being the first directory to search.
<jodh> xnox: well, we want the user to be able to disable a system job, so ~/.config/upstart/foo.override should override /etc/xdg/upstart/foo.conf. I think it would be highly beneficial if you added some more detail to the spec on this to make it totally clear. We can discuss tomorrow if you like with stgraber? (currently trying to get something finished by COB :)
<xnox> So the order is: --confdir ; ~/.init ; xdg_config_home; for each in xdg_config_dirs
<xnox> first one wins.
<xnox> jodh: no. I disagree, because ~/.config/upstart/foo.conf will be treated higher priority than /etc/xdg/upstart/foo.conf
<xnox> jodh: but the system administrator may want to override that job for all users in /etc/xdg/upstart/foo.override
<jodh> xnox: yes. ok, well lets add some more use cases to the spec and discuss tomorrow?
<xnox> jodh: and the user may want to temprorarly over-override ~/.config/upstart/foo.conf with ~/.config/upstart/foo.override, regardless whether /etc/xdg/upstart/foo.* exist or not.
#upstart 2012-12-05
<Robot101> I understood that my "task" job which was "start on runlevel [016]" would finish before other runlevel stuff would continue
<Robot101> but it seems this isn't the case, so it gets terminated by the sysv task killer
<Robot101> (I have a file sync from workstation back to server which would ideally be completed at system shutdown)
<Robot101> (and also similarly, the reverse which needs to be done before gdm appears)
<SpamapS> Robot101: runlevel is not waited on, so no, your task won't finish before other runlevel stuff will continue.
<SpamapS> Robot101: what you probably want then is 'start on deconfiguring-networking'
<SpamapS> Robot101: that is the latest possible moment before the network goes down
<SpamapS> Robot101: IIRC sendsigs should actually wait because your task is in start/ goal state... it does not send kill to those processes.
<Robot101> SpamapS: is runlevel special-cased by "task" somehow, and other events will be OK?
<jodh> Robot101: not sure I understand your question. However, take a look at upstart-events(7) and you'll see why SpamapS suggestion will work (because deconfiguring-networking is a hook event that blocks).
<jodh> Robot101: an alternative would be to have your job 'start on starting rc RUNLEVEL=[016]' which would block the starting of the rc job which causes the SysV shutdown sequence in this case.
<toabctl> jodh, is there some spec about the dconf bridge you want to implement?
<jodh> toabctl: it's partially done: https://code.launchpad.net/~stgraber/upstart/upstart-dconf-bridge
<toabctl> jodh, yes. checked this already.
<stgraber> still need to port it to gdbus, been busy with other things lately :)
<toabctl> stgraber, maybe I'll help a bit
<toabctl> stgraber, what about listening to the systembus and waiting for upstart to appear instead of an exit if upstart is not available on the bus?
<toabctl> sessionbus, not systembus
<jodh> toabctl: this bridge shouldn't be listening on the system bus - it's per user.
<toabctl> jodh, yes. sorry
<stgraber> toabctl: so, ultimately that bridge will be started by upstart itself once dbus is started, so there's no real need for the bridge to wait for the bus as upstart will guarantee it's spawned after dbus is ready (and respawn it if dbus dies for some reason)
<toabctl> stgraber, ok
<jodh> stgraber: could you add some details on this to the spec?
<toabctl> jodh, stgraber how can I test the bridge? I guess I have to run upstart in my session..
<stgraber> toabctl: right, do "mkdir ~/.init", then "init --session --confdir=~/.init/". That'll spawn an upstart instance on your session bus
<toabctl> stgraber, does that work with upstart from raring? or should I install upstart from bzr?
<stgraber> toabctl: works fine with upstart from raring
<toabctl> great. thanks!
<toabctl> funny. I get a lot of events when I resize a window because some programs (eg dconf-editor) store their window settings (height, width, maximized, ...) with gsettings.
<toabctl> is there some html doc for libnih?
<toabctl> stgraber, https://code.launchpad.net/~toabctl/upstart/dconf-bridge-gdbus
<toabctl> stgraber, maybe a split of keyname and keypath would be good for the environment
<toabctl> btw: where are the tests for the files in extra?
#upstart 2012-12-06
<jMCg> Hello happy people.
<jMCg> I just discovered that the upstart cookbook uses some horrible anti-patterns in its examples
<jMCg> for dir in `ls /var/lib/queues`
<jMCg> Anyways, the question I'm here for actually, other than, how do I fix the examples in that cookbook and send you patches, is: Can I change setuid/setgid *per* instance?
<jMCg> Use more quotes: http://apaste.info/12l8
<toabctl> jodh, are you working on the file bridge? and if so, is there already some code?
<toabctl> I also wanted to know if there is html documentation for libnih. would be nice to have this at developer.ubuntu.com
<jodh> toabctl: yes, I am. I'll push some code somewhere soon. I forget who (xnox?), but someone @ UDS offered to auto-gen some dev docs using doxygen as NIH uses the KDE commenting-format.
<xnox> jodh: s/KDE/gtk-doc/
<jodh> xnox: close :)
<xnox> toabctl: jodh: yeah I did generate gtk-doc locally for both, it doesn't look very nice (formatting errors), tried to clean up and integrated and it broke again.
<toabctl> xnox, would be nice to autogenerate the doc with the package. so build-dep would be gtk-doc
<jodh> toabctl: I appreciate this isn't to everyones tastes, but I've configured vim for ctags for nih+dbus so you can just CTRL+] to jump to the actual NIH code (and doc of course).
<xnox> toabctl: jodh: filed as bug 1087269 subscribe if you are interested =)
<xnox> toabctl: yeah, i know. But gtk-doc needs correct bootstrapping with autoconf first which I didn't quite do right the first time around. When it works, I will propose a merge ;-)
<jodh> xnox: subscribed.
<jodh> xnox: Keybuk still owns NIH upstream, but if you can put an NIH branch with doc changes somewhere we can work on a new release branch and see if it gets his blessing :)
<jodh> I'm still waiting for STL man pages :)
<toabctl> jodh, how do you want to implement user sessions? with a new upstart instance for every user? or only one upstart instance which handles all the stuff?
<xnox> jodh: STL? stereolithography file format?
<jodh> toabctl: it's all here: https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions
<jodh> xnox: C++ standard template library :)
<jodh> toabctl: but in short, 1 instance per user. Makes for a much cleaner design and avoids nasty DoS possibilities.
<jodh> toabctl: make that 1 instance / user *session* :)
<toabctl> jodh, something different is mentioned here: https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-upstart-session-requirements (see bottom of page)
<toabctl> jodh, sometimes imho it's very confusing with alle the blueprints, wikis and mailinglists. I never know what's the right source
<jodh> toabctl: that's the quantal blueprint, not the raring one.
<toabctl> jodh, so half a year later all is different ? :-)
<toabctl> jodh, some should at least mark the blueprint as outdated/invalid
<toabctl> and point to the latest information for the topic
<jodh> toabctl: it is marked "Implementation: Deferred".
<jodh> toabctl: it's not that difficult - just go to https://blueprints.launchpad.net/ubuntu/$release (ie raring) and see what the community is working on.
<toabctl> jodh, ok. and the blueprints from blueprints.launchpad.net/upstart ?
<jodh> toabctl: first time I've seen that page :) Those bp's refer to "upstream Upstart projects" whereas we are driving changes via the Ubuntu project (even though they actually land in upstream Upstart first).
<toabctl> :)
<stgraber> slangasek: when you have a minute, I'd like an opinion on https://code.launchpad.net/~stgraber/ubuntu/raring/libnih/libnih-dbus-as-type/+merge/138582
<stgraber> slangasek: it appears to work here, diffing upstart's generated code shows that it's only fixing the one variable I added, but I won't pretend to understand all the potential impact of that change ;)
<slangasek> stgraber: hmm, I'm not familiar enough with this code myself to be a particularly good reviewer
<slangasek> I can dive into it, but it'll take me a while.  Maybe it's better to have jodh review?
<stgraber> slangasek: ok. I wasn't sure how much of libnih you knew about. I can wait till tomorrow for jodh to review.
<stgraber> slangasek: at least I have a local build with that fix so I can now write tests for my dbus branch without having upstart die on me :)
<stgraber> slangasek: spoke too soon, looks like I'll need more magic in nih, the generated code segfaults in upstart though the nih testsuite itself passed. I guess it's missing a test with an empty array...
* You're now known as ubuntulog
<slangasek> mmk :)
<stgraber> right, so I managed to fix the generated code so that the upstart testsuite works, now to fix the generator to give me something that roughly matches my manually patched file :)
#upstart 2012-12-07
<stgraber> and success! Had to do quite a few more changes in nih-dbus-tool to get it to generate the right code and still have its tests pass, but it looks good now and my upstart branch builds and passes its tests!
<ryanf> is it normal behavior for upstart to assume your process has died if you send it a USR1 signal?
<ryanf> and if so, how can I tell it not to assume that?
<ryanf> ideally I'd like to be able to send that signal to a process that upstart is watching without upstart itself noticing or caring
<ryanf> it won't result in the process terminating
<SpamapS> ryanf: no it won't assume your process has died on USR1
<SpamapS> ryanf: upstart is ptracing looking for an exit of some kind.
<SpamapS> ryanf: or if you havn't used 'expect fork' then it is just waitpid() on the process, which will only return if the process exits.
<ryanf> SpamapS: that's really weird then
<ryanf> SpamapS: what I'm getting is stuff like
<ryanf> [170555.273477] init: sidekiq (0) main process (29388) killed by USR1 signal
<ryanf> in the syslog
<ryanf> and then it's marked as stopped
<ryanf> but I can see with ps that the process is still running
<ryanf> (I am not using expect fork btw)
<SpamapS> ryanf: thats really odd, that message is only printed when libnih claims the child process was killed or core dumped
<ryanf> let me double-check that
<ryanf> oh, I see! in reality I am an idiot
<SpamapS> ryanf: the process does exit doesn't it?
<ryanf> yes. the twist is that there are two processes
<ryanf> initctl lists the pid for start-stop-daemon
<ryanf> and I was assuming that was the pid for the process started by start-stop-daemon
<SpamapS> waitid() will only return that state if the process is literally *killed* by that signal
<ryanf> so I was sending USR1 to start-stop-daemon, thereby killing it
<stgraber> expect fork instead of expect daemon?
<SpamapS> ryanf: you may not be calling start-stop-daemon right then. It should be exec'ing your process, not staying around and forking
<stgraber> though having an upstart job use start-stop-daemon sounds pretty weird, considering upstart is doing pretty much everything start-stop-daemon was designed to do :)
<ryanf> apparently it's the recommended way to create a pidfile for the process
<ryanf> although come to think of it, I don't need the pidfile anymore, so maybe I should just stop using it
<stgraber> right, you don't need a pidfile as long as upstart can figure out what your final pid is and track it
<SpamapS> ryanf: why are you making a pidfile?
<SpamapS> ugh, lag
<SpamapS> as I'm hitting enter my IRC client catches up from 2 minutes ago
<ryanf> I needed one before because I was trying to integrate with the tools that come with this software
<ryanf> which want a pidfile
<ryanf> but as soon as I get my own script doing the USR1 thing correctly, I have no reason to use those tools
<ryanf> back to using a pidfile, because otherwise I don't have a way to get the pid to send USR1 to it -- semi-long story
<ryanf> thanks a lot for pointing out my false assumptions about what was going on before though
<ryanf> got it working completely now. thanks again.
<jodh> xnox: your changes to https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Configuration_Files_for_User_Jobs are still ambiguous. Now that you've removed the table, it is not clear what happens if an override file exists earlier in the search path *and* in the current search directory. So if /etc/xdg/upstart/foo.override, ~/.config/upstart/foo.override and ~/.config/upstart/foo.conf exist, which .override applies? Can
<jodh> you clarify this in the spec please.
<xnox> jodh: The first one only applies.
<jodh> xnox: also, the table would have helped a lot with writing the tests for this part of the feature I think as we need full coverage :)
<xnox> jodh: ok, I will.
<xnox> jodh: not really, cause by default there are 3 "system dirs" and 2 "user dirs"
<xnox> jodh: and none of them have anything special about them. It's just a priority ordered list of conf sources.
<jodh> xnox: I'm not saying we need to test every possible combination of those 5 directories, but we need representative tests that cover atleast 2 directories with .conf and .override in each to prove the behaviour.
<xnox> ack.
<xnox> jodh: I thought the test needs 3 directories and do a matrix test of all possible combinations of foo.conf & foo.override existance across all three directories.
<xnox> It is a little overkill, but guarantees coverage.
<xnox> jodh: updated the spec again. Please re-check for ambiguity.
<jodh> xnox: works for me. Your update LGTM.
<xnox> thanks.
<jodh> xnox: I think all these on-list discussions are slowly drawing out some of the implicit assumptions we've all had up to now :)
<xnox> =))))) yeah, the "OMG, but I thought it will do this instead" is not we want =)
<jodh> xnox: right ;D
<xnox> jodh: well. I now think to not change --confdir behaviour. And even in the Session Upstart to continue the same --confdir semantics (specify N times and only the Nth will be loaded)
<xnox> jodh: while system init has conf_sources which is a NihList, the session init only has a string conf_path.
<xnox> Does this imply that while system init supports on api level multiple conf sources, the session init doesn't?
<xnox> Or am I misinterpreting system init & it actually also does not support multiple conf sources?
<stgraber> jodh: hey there. Do you think you'll have time to look at my libnih merge proposal today?
<stgraber> jodh: and thanks for the comment on the prctl branch, I'll try to add some autoconf magic around that block
<jodh> stgraber: probably not I'm afraid - currently in the middle of putting a release together.
<jodh> stgraber: thanks.
<xnox> jodh: does that mean that I should clean up the autopkg merge?!
<jodh> xnox: I'm only doing an upstream release today, but if you want to get the DEP-8 bits ready for Monday that'd be great.
<xnox> jodh: ok. I am writting XDG config dir parser for upstart now & I have installer bug to look into. Hopefully, all will be done by Monday.
<jodh> xnox: cool
<ajp> trying to make my new script run on upstart, im new to upstart, where should I start?
<JanC> ajp: probably the cookbook, see /topic
<JanC> http://upstart.ubuntu.com/cookbook/
<JanC> and of course the manpages  ;)
<ajp> instead of using upstart, is it wise to add my script to @reboot in crontab? 
<xnox> ajp: no. because you can't stop/restart/respawn @reboot entries.
<xnox> ajp: or let users/admins temporary override some options in the job with an override file.
<ajp> xnox: it's a script that monitors a folder for new files, compresses and moves them. I'm the only user. I just need the script to start at boot
<xnox> ajp: I recommend you to create a logrotate snippet in /etc/logrotate.d/
<ajp> not sure what that is
<xnox> ajp: logrotate is a daemon that does: monitoring of files or logs, re-compresses them and keeps archived copies for a defined period of time.
<ajp> I have the script done and it works, i just want it to run at boot so i dont have to launch it every time
<xnox> ajp: e.g. it's the daemon that creates, keeps and cleans up all the /var/log/*.gz files.
<ajp> the files im "compressing" are PDFs and it uses ghostscript to make them smaller, not actually compressing them
<xnox> ah, I see.
<ajp> :D
<xnox> ajp: @reboot should be fine, an upstart job as well.
<ajp> both
<ajp> ?
<ajp> or just 1
 * xnox thinks with enough twiddling you can ask logrotate to use a custom "recompressor" command and use logrotate facilities for the rest.
<ajp> i'm thinking the @reboot sounds much easier to accomplish
<xnox> ajp: just one of the above is enough =)
<ajp> xnox: thanks man, imma try the @reboot and see
<ajp> so i tried the @reboot, didnt work
<ajp> looks like imma learn upstart
<ajp> xnox: do I only have to modify one file to add it to upstart?
<xnox> yes.
<ajp> /etc/init?
<ajp> xnox: which file am i editing?
<ajp> xnox: sorry if im pestering
<xnox> /etc/init.d/my-cool-recompressor.conf
<xnox> bah.
<xnox> wrong.
<xnox> /etc/init/my-cool-recompressor.conf
<ajp> ok i created the file
<ajp> but i named it MontiorScannedPDFs.conf
<ajp> xnox: how does this look? http://pastebin.com/DVhstVqa
<xnox> ajp: remove stop on, change start on to be
<xnox> "start on filesystem"
<xnox> (no need for explicit stop, as your job will be killed on shutdown anyway)
<ajp> ok
<ajp> so is this ready to go now
<ajp> ?
<xnox> yeah.
<ajp> cool, im gunna try it. brb
<ajp> so I start it by typing$ service MonitorScannedPDFs start   ???
<ajp> or should i just reboot
<xnox> either should work.
<ajp> when i did the first one it says: http://pastebin.com/DVhstVqa
<ajp> oops
<ajp> start: Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=1000 pid=1696 comm="start MonitorScannedPDFs ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
<xnox> sudo ?
<ajp> i did
<ajp> wait i didnt
<ajp> lol
<ajp> but now it says: start: Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=1000 pid=1696 comm="start MonitorScannedPDFs ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
<ajp> sry
<ajp> start: Job failed to start
<ajp> xnox: this is what I have now: http://pastebin.com/zUjJ9G8c
<ajp> do I need the . in front of the script path?
<ajp> oh wait, fixed it. I had to add sudo in front of script path
<ajp> now for testing
<xnox> ajp: you can use setuid
<ajp> explain
<xnox> ajp: http://upstart.ubuntu.com/cookbook/#setuid
<xnox> to run as your username.
<ajp> oic
<ajp> its running but the script isnt doing its job
<ajp> although when i run the script by itself it works
<ajp> not sure what's wrong here
#upstart 2013-12-03
<mikedevita> i have an upstart script which for some reason isnt sourcing env variables that i have defined in /home/root/.bashrc
<mikedevita> env variables like passwords and such for a nodejs app
<dsimon> hey all; is there a convenient way to keep instanced jobs persisted?
<dsimon> e.g. suppose i have a job foo that has a line "instance $BAR"
<dsimon> and i do "start foo BAR=a" and also "start foo BAR=b"
<dsimon> 5 minutes later, my UPS fails for a bit and the system shuts down hard
<dsimon> i'd like those specific instances to be restarted when the system comes back up
<xnox> dsimon: have a job" task\n script\n start foo BAR=a; start foo BAR=b\n end script" with appropriate start-on conditions.
<xnox> dsimon: that way on each boot those instances are started. (or otherwise arrange for events to happen to bring those jobs up)
<xnox> dsimon: there is no persistence across reboots, apart from what's encoded in the job config files.
<dsimon> xnox, yeah, i just saw that same suggestion from a stack overflow answer, makes sense to me :-)
<xnox> dsimon: your other option however is for the instance job to write it's own config file out on disk ;-)
<dsimon> oh geez, that makes my brain hurt just thinking about it
<dsimon> "when i start, create a thing that starts me"
<dsimon> hm... actually, now that i say that, though
<dsimon> maybe that's not a terrible idea
<xnox> dsimon: "echo '@reboot root initctl --system start BAR=$BAR' > /etc/cron.d/custom-foo-$INST"
<xnox> dsimon: but make sure you clean up that same file as well, one the instance gracefully stops and no longer needed, e.g. in post-stop.
<dsimon> hm, in cron?
<dsimon> shouldn't i use upstart itself instead?
<xnox> dsimon: that's another option. It's best to write out upstart job though.
<xnox> dsimon: or write a template and parse / write it out.
<dsimon> yah
<dsimon> well, maybe my best bet is to just have a manager
<xnox> dsimon: because that way you get the "start on" conditions right =)
<dsimon> my situation is: i have daemons that implement web services which are available on particular ports during particular scheduled date ranges
<dsimon> so maybe i should just implement a thing that checks the running services list vs. the list of services that should be running given the current date, and starts/stops instances as necessary
<dsimon> and have cron run it once a minute
<dsimon> xnox, does that seem like a good idea to you?
<xnox> dsimon: yes.
<xnox> dsimon: i'm a freak so I would have used nagios for this encode the policy when the service must be up, and give nagios agents to execute start/stop commands to bring them up/down.
<xnox> dsimon: cause it has recovery options, such that when the time is right nagios start them.
<dsimon> hm, that could work
<xnox> dsimon: there is a long term plan to implement temporal events, such that one would can do "start on midnight" "stop on 1am"
<xnox> or somesuch, but there is no working implementation yet.
<dsimon> ah, i see
<dsimon> ok, cool; xnox, thanks for your help :-)
<xnox> no problem =)
<dsimon> hm
<dsimon> i just ran into a weird issue
<dsimon> i had a misconfigured upstart config for nginx
<dsimon> so it was starting stuff up badly
<dsimon> i corrected it...
<dsimon> but things still did not work :-(
<dsimon> both "start" and "stop" would hang, regardless of the expect stanza setting
<dsimon> ... oh, wait
<dsimon> wait wait
<dsimon> i bet it was the pid file
<dsimon> well, possibly
<dsimon> at any rate; after restarting the machine, everything seemed to be behaving correctly
<dsimon> so that makes me happy and sad :-|
<dsimon> happy because it works, but sad because i am not sure what happened, or how to prevent it from happening again
<dsimon> the reason i mention pid files is because "status" would falsely report an old pid for nginx, even if it was stopped
<dsimon> okay, now it's happening again; i was starting and stopping nginx just fine, but when i tried "restart", it hung
<dsimon> and now, start and stop also hang, and start fails to actually start any processes
<dsimon> what could be causing this?
<xnox> dsimon: please read the cookbook on "establishing the pid count" and the states it could force your job into.
<xnox> dsimon: at the moment, if the expect stanza is wrong, one can get into a "deadlock" you described about (job stuck, cannot reset state)
<xnox> dsimon: this is in-progress being fixed (merge proposal under review into trunk)
<JanC> well, you can "reset" it with some tricks  ;)
<xnox> JanC: yes, yes you can. I've heard of them........ but in no way, i'll suggest that for anyone to do =)))))
<JanC> well, they are fine to solve temporary issues
<JanC> certainly beats rebooting between tries to get a job right  :p
<xnox> true =)
<xnox> JanC: anyway it's getting fixed properly =)
<JanC> that would be nice
<JanC> xnox: any ETA?
<xnox> JanC: as I said there is a merge proposal under review for trunk.
<xnox> JanC: it should make it into Trusty (14.04 LTS)
<JanC> that's more or less what I meant  :)
<JanC> a merge proposal is not merged yet, and trunk is not released yet
<JanC> (and I haven't followed the ML in ages)
<xnox> JanC: i've been misquoted on ETAs in the past =))))) i'm trying to be careful.
<JanC> well, the E in ETA is for "estimated", so I don't take them as a promise  :)
<xnox> ack =)
<xnox> I still have nightmares from time to time, from the times when i was in "consulting"
<JanC> ugh
<xnox> i'm in a happy place now =)
<JanC> I get nightmares from consultants  ;)
<JanC> but there are some exceptions, of course
<xnox> haha =)
<JanC> I've seen some very competent ones, and many, many who know less than an average helpdesk person with a high school diploma  :-/
<JanC> (and when I say helpdesk, I mean a real helpdesk, not a bunch of people answering phones with the goal to end calls within less than 1 min 32 sec on average--and one sec less next month, to improve productivity)
#upstart 2013-12-04
<SpamapS> slangasek: thanks for the 11 minute patch turn around time. :)
<xnox_> SpamapS: Thanksgiving patch piloting for the win =) anyway man page patches are a touchy subject in upstart given how ellaborate procedure one manpage patch went through =))))))
<slangasek> hah
#upstart 2013-12-05
<leedev> I can't seem to get setgid and setuid to work in 1.5 on ubuntu precise 
<leedev> and then I get "start: Unknown job: daq"
<leedev> as soon as you start a job with setgid and setuid, upstart seems unstable
<xnox> leedev: upstart rejects jobs with invalid syntax, can you paste full job?
<leedev> working on it
<xnox> leedev: you may used pastebin service, e.g. http://paste.ubuntu.com/
<leedev> http://pastebin.com/jWZ2ESLw
<xnox> thanks.
<leedev> is is as simple and plain as it gets
<xnox> File foo.conf: syntax ok
<xnox> leedev: that's what init-checkconf says.
<xnox> leedev: what's the name of the file and where do you put it?
<xnox> also what is encoding / line endings?
<leedev> lets say it this way, it works fine on newer versions
<leedev> and I am using vi
<xnox> leedev: do you have init-checkconf available to run against that file?
<leedev> $ init-checkconf /etc/init/daq.conf 
<leedev> ERROR: failed to ask Upstart to check conf file
<xnox> (in precise i think it fortunately needs dbus-launch and thus a DISPLAY)
<xnox> darn.
<xnox> yeap =/
<leedev> hahah
<xnox> leedev: yes, i don't understand why dbus needs that either.
<xnox> not a bug in the init-checkconf script itself.
<leedev> I can't start or stop any upstart once I use one with setuid or setgid
<leedev> but i'm not guaranteeing the sanity of install, so if you tell me it looks fine, I might do a fresh up to date install
<xnox> leedev: do note that HOME will not be set, so you do want to add "export HOME=/home/lee" or somesuch.
<leedev> this program isn't dependent on the HOME environment variable, but thanks for the tip
<xnox> leedev: the paste you gave me is a valid job file, i've tested it in precise vm just now.
<leedev> oh ya, I should have made a quick precise lxc to test it
<leedev> thanks, xnox 
#upstart 2013-12-06
<jodh> Upstart devs - please can someone re-review https://code.launchpad.net/~jamesodhunt/upstart/bug-530779/+merge/197080 as this is blocking work on bug 1258098.
<xnox> jodh: does above in any way help with bug 406397?
<jodh> xnox: no.
<xnox> jodh: and for what services were affected by bug 530779? would be good to test them. I vaguely remember: syslog-ng, cups, mysql, something else or some such?
<jodh> xnox: yes, slangasek has a better list somewhere? It would be good to get QA to run boot+DEP-8 tests for all such packages with a build using that branch.
<slangasek> well, no services are affected by it with their current job definitions :)
<slangasek> cups is a big one to fix, but requires a follow-on change to not de-ptrace on exec
<xnox> slangasek: so a manually crafted test-cases passes, but i wanted to run the change on the pre-existing affected service (in the config when it would be affected)
<slangasek> xnox: well, look for things with 'while' in a post-start :)
<xnox> slangasek: omg, i see.
<xnox> jodh: first upstart job diff http://bazaar.launchpad.net/~upstart-devel/upstart/upstart-jobs/revision/5   not sure if email / branch notification got send to the mailing list or not.
<jodh> xnox: wow, and what a diff :). I haven't seen any notifications as yet.
<xnox> jodh: ha, upstart-devel was "no email" notification.
<xnox> (me deletes revision and retriggers import)
 * jodh got a notification :)
#upstart 2013-12-08
<xmj> moin
<xmj> I've heard through #debian that Upstart's looking into being ported to run with the freebsd kernel (and maybe natively)
<xmj> Any news on that front?
<xnox> xmj: yes, see my blog posts from me on debian planet (blog.surgut.co.uk) at the moment - only kfreebsd/eglibc is targetted (that is freebsd kernel and GNU eglibc, not the BSD libc)
<xmj> xnox: would that work with debian/kfreebsd, then?
<xnox> xmj: at the moment waiting for eglibc2.18 to be uploaded into debian, mostly.
<xnox> xmj: ah.... yeah that's the target, that's what debian/kfreebsd is.
<xmj> gotcha
<xmj> Do they plan to move from glibc to eglibc ?
<xnox> xmj: they have many years ego.
<xmj> ohh, didn't know that
<xnox> http://blog.aurel32.net/47 in 2009
<xmj> xnox: what's the showstopper to getting upstart to work with libc, though?
<xnox> xmj: but now that glibc upstream is sensible again, i believe the plan is to fold back into glibc.
<xnox> xmj: which libc?
<xmj> freebsd's
<xnox> xmj: no idea, try compiling and see. it has different header includes and different syscall wrappers etc.
<xmj> hmm, interesting
#upstart 2014-12-02
<myndzi> i'm trying to run a node app as a daemon; using daemonize to launch it, we encountered a config error that caused daemonize to throw a nonzero exit code, but upstart still thinks it is running
<myndzi> how do i make it properly track the process?
#upstart 2014-12-03
<dryicerx> Hello. Is there some way to make two services mutually exclusive?
<dryicerx> (making it an error, or preventing two services from being started at same time)
#upstart 2015-12-02
<johnjelinek> hihi all
<johnjelinek> how's it going?
<johnjelinek> I have a problem, when I try to start a job it fails: `Dec  1 23:18:12 ubuntu kernel: [18131.837454] init: Failed to spawn syncthing main process: unable to find setuid user`
<johnjelinek> `user` is the name of the user I'm logged in with
<johnjelinek> $(id user) `uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lpadmin),111(sambashare),999(docker)`
<johnjelinek> any ideas?
#upstart 2016-12-05
<hallyn> huh, digitalocean won't let me use a 4-cpu instance without paying more.  i only want it a few hours, what on earth
 * hallyn should yell at utlemming
<hallyn> hm, wrong window
<hallyn> sorry about that!
#upstart 2016-12-08
<ericsysmin> if I have an upstart script, and i want it to stop respawn when i do a initctl stop <service> what should I change?
<ericsysmin> it correctly on failing restarts itself, but when running a stop, it still restarts itself
<ericsysmin> is this something I should use a PID for?
<JanC> it should not restart when you use stop
<JanC> maybe it crashes when you try to stop it or something?
<JanC> or something else restarts it?
<ericsysmin> give me a few removing the respawn value to see if it works without respawn in the file
<ericsysmin> when i remove respawn, it stops as it should
<ericsysmin> and stays stopped, so it's definitely having respawn in the service
<ericsysmin> that causes it
<JanC> do you have a pre-stop script or something like that?
<ericsysmin> yea
<ericsysmin> i do have a pre-stop script which does cleanup if you "stop" the service
<JanC> most likely something goes wrong in there
<JanC> something that returns a non-zero exit status
<JanC> at least, that's my guess
<ericsysmin> ah ok
<JanC> remember all scripts in upstart are run with "sh -e"
<ericsysmin> nothing exiting with non-zero
<JanC> are you sure it's okay to clean up _before_ stopping the service?
<JanC> some services might crash if you try that (clean up in post-stop script then)
<ericsysmin> omg lol dur, that is probably it
<JanC> "cleaning up" is more or less what post-stop is for usually  :)
<ericsysmin> typo on my part
<JanC> while pre-stop is often used to stop the service process if that requires a special command
<JanC> or sometimes to cancel the stop
<ericsysmin> yea, it's a post-stop style script
<ericsysmin> it would most definitely break it if running
<ericsysmin> JanC, thanks for your help man
<ericsysmin> how would i create a list of vars that are used throughout my upstart file?
#upstart 2016-12-09
<AnrDaemon> ericsysmin: What do you mean by "list of vars"?
<ericsysmin> i want to name a value lets say, "myvar" and set it to "value" then reference "myvar" multiple times in both script, and post-stop portions of upstart, how would I do that?
<ericsysmin> i've seen using env myvar=value and i'd put that above script
<ericsysmin> not sure if that's correct though
<AnrDaemon> ericsysmin: It's correct, but highly questionable practice.
<AnrDaemon> ericsysmin: First, it opens up the possibility to manipulate your daemon externally by setting these vars at init time.
<ericsysmin> so it's best to manually set these?
<ericsysmin> and not use vars in upstart
<AnrDaemon> You can, and sometimes should use vars. But consider their use carefully.
