#upstart 2007-03-05
* Starting logfile irclogs/upstart.log
<Keybuk> hmm
<Keybuk> so "status foo", pretty obvious that should return one entry for a normal job
<Keybuk> and I think it's correct to return a list of jobs for an instance job
<Keybuk> but should it also return the "master" job, which would always be stop/waiting
<Keybuk> or should I have a special message for an instance job list
* Keybuk starts tackling initctl
<AlexExtreme> heh
<AlexExtreme> "Do not stand directly in front of this door."
<AlexExtreme> well do you expect blind people to read it without going up to it? :p
<Keybuk> that was my point :p
<AlexExtreme> yeah i know ;)
<Mithodin> Hello
* Starting logfile irclogs/upstart.log
* Keybuk is much happier
<AlexExtreme> why's that?
<Keybuk> initctl is turning out to be rather simpler with the new IPC messages
<AlexExtreme> cool
<mbiebl> Keybuk: I wanted to prepare a 0.3.5 release for experimental today. 
<mbiebl> Got a couple of questions
<Keybuk> sure
<mbiebl> Is console logged still unsafe?
<Keybuk> it's still disabled yeah, I haven't touched logd any further yet
<Keybuk> the problem is the bad behaviour of just about every app when they can't write to stdout
<mbiebl> ok, then I'll better also use console output then.
<mbiebl> The next issue is rc0-poweroff/rc0-halt, which were obsoleted.
<Keybuk> haven't traced it further; can't see why they terminate, rather than just ignore it
<Keybuk> yes
<Keybuk> since we can transfer environment variables in an event, it made more sense for shutdown itself to set INIT_HALT, just as it did with sysvinit
<mbiebl> You seem to backup them to dpkg-bak if they were modified in preinst. Why not just remove it?
<Keybuk> general "don't remove other people's modified conffiles" behaviour
<mbiebl> You also delete the unmodified ones in preinst, so they are still recorded as installed by dpkg
<Keybuk> that's a dpkg bug
<Keybuk> older dpkg behaves correctly
<Keybuk> there's currently no way to remove a conffile without it still showing up in dpkg -L
<Keybuk> even if it's not shipped in the current version of a package
<mbiebl> I tried it that way:
<mbiebl> mv the modified ones in preinst to .dpkg-bak, the unmodified ones to .dpkg-remove
<mbiebl> Remove .dpkg-remove files in postinst.
<mbiebl> If upgrade fails, restore .dpkg-bak and .dpkg-remove files back.
<mbiebl> (abort-upgrade in postinst)
<Keybuk> how does that change it?
<Keybuk> dpkg still records the conffile, no?
<mbiebl> no, it doesn't
<Keybuk> ahh
<Keybuk> interesting
<Keybuk> that's changed recently then
<Keybuk> shiny
<Keybuk> I'll update my functions accordingly
<mbiebl> It also restores the state completely on an aborted upgrade.
<mbiebl> If I rmmed the unmodified ones in preinst that wouldn't be possible.
<Keybuk> I rm them in postinst, no?
<mbiebl> Yes.
<Keybuk> the recipe always used to be:
<Keybuk>   in preinst, move to dpkg.bak if modified, leave alone if not
<Keybuk>   in postinst, remove if still exists
<Keybuk>   in postrm abort-upgrade, rename .dpkg-bak back to the conffile
<Keybuk> -- 
<Keybuk> so what happens there is the conffile is in place when the package is upgraded, so dpkg notes it in status as an obsolete
<Keybuk> looks like dpkg has been fixed so dpkg actually stats the file, and doesn't note a missing file as obsolete now
<Keybuk> so the recipe should be:
<Keybuk>   in preinst, move to .dpkg-bak if modified, .dpkg-remove if not
<Keybuk>   in postinst, remove .dpkg-remove if it exists
<Keybuk>   in postrm abort-upgrade, rename .dpkg-bak or .dpkg-remove back to the conffile
<Keybuk> yes?
<mbiebl> yeah, that's what I do currently.
<mbiebl> I just wanted to hear your thoughts on this, if you think this is the correct way (tm) to do it.
<Keybuk> that makes perfect sense
<mbiebl> I really hoped dpkg would be a bit more clever in that regard.
<mbiebl> And did that automatically.
<Keybuk> :D
<Keybuk> note a bug in the Ubuntu upstart package
<Keybuk> migrate-inittab generates the wrong runlevel event names
<mbiebl> I haven't synced this feature into the Debian postinst (yet)
<Keybuk> *nods*
<Keybuk> btw, woooooo shiny:
<Keybuk> wing-commander util% sudo ./initctl start tests/foo 
<Keybuk> tests/foo (start) waiting
<Keybuk> tests/foo (start) starting
<Keybuk> tests/foo (start) pre-start
<Keybuk>         pre-start process 2533
<Keybuk> tests/foo (stop) pre-start
<Keybuk> tests/foo (stop) stopping
<Keybuk> tests/foo (stop) killed
<Keybuk> tests/foo (stop) post-stop
<Keybuk> tests/foo (stop) waiting
<Keybuk> initctl: tests/foo pre-start process killed by SEGV signal
<Keybuk> -- 
<Keybuk> start blocks until the job is running/finished, and returns an error if the job failed, and outputs all the interim process states
<mbiebl> oh, I remember another issue: postinst/purge
<mbiebl> I added a call to remove .dpkg-bak there.
<Keybuk> hmm, interesting
<Keybuk> hadn't previously considered that
<Keybuk> does dpkg remove modified configuration files on purge?
<mbiebl> yes, that's why I added it
<mbiebl> To be compliant with dpkg's behaviour
<Keybuk> *nods*
<Keybuk>  tests/foo (start) post-start
<Keybuk>         main process 2865
<Keybuk>         post-start process 2866
<Keybuk> \o/
<mbiebl> Does that mean, I could start a daemon in (pre|post)-(start|stop) (and have it monitored/respawned)?
<Keybuk> no, upstart wouldn't know the process id
<Keybuk> Mar  5 19:59:52 wing-commander init: Caught segmentation fault, core dumped
<Keybuk> Mar  5 20:00:23 wing-commander last message repeated 19073 times
<Keybuk> Mar  5 20:01:24 wing-commander last message repeated 33310 times
<Keybuk> oops
<AlexExtreme> Keybuk, that looks bad ;)
<Keybuk> AlexExtreme: yeah, haven't figured out a way to dump core *and* get over the problem instruction yet
<Keybuk> so when it SEGVs, it basically ends up in an infinite loop writing core to the disk
<AlexExtreme> yes
<AlexExtreme> so basically it needs to stop calling the function that's causing the SEGV if possible?
<Keybuk> right, but how do you do that?
<Keybuk> the function has probably altered state
<Keybuk> so you have no idea whether the global state is consistent
<Keybuk> you may have a job that has dangling pointers into the nether
<Keybuk> so you can't carry on, because you'll just dump core again
<AlexExtreme> yep :/
<Keybuk> and you can't even reexec and transfer your state, because you could dump core while reexecing
<Keybuk> the best solution so far is to reexec without transfering state
<Keybuk> which will cause X to crash :p
<AlexExtreme> :)
<Keybuk> but I figure X crashing is better than nothing
<AlexExtreme> yes
<Keybuk> brb, need to SUB
<Keybuk> right
<Keybuk> better
<Keybuk> that works actually
<Keybuk> SEGV'ing init might crash X
<Keybuk> but apport catches it
<Keybuk> so you get a friendly explanation *why* and can click to file a bug
<Keybuk> which is nice
<Keybuk> wing-commander util# ./initctl status tests/inst
<Keybuk> tests/inst (instance)
<Keybuk> wing-commander util# ./initctl start -n tests/inst
<Keybuk> wing-commander util# ./initctl start -n tests/inst
<Keybuk> wing-commander util# ./initctl start -n tests/inst
<Keybuk> wing-commander util# ./initctl status tests/inst  
<Keybuk> tests/inst (instance)
<Keybuk>     (start) running
<Keybuk>     (start) running
<Keybuk>     (start) running
<Keybuk> ^ do we like that as a method for reporting instance jobs?
<Keybuk> (and stop tests/inst stops every single instance)
<AlexExtreme> Keybuk, looks good
<Keybuk> needs some cleaning up, and testing but I'm pretty happy with it
#upstart 2007-03-06
<andreas___> hi
<andreas___> doesn't upstart have a log file? I am trying to find out why my script doesn't work, but there isn't anything in syslog or elsewhere
#upstart 2007-03-07
<reppel> is it possible to use something like
<reppel> env CURDATE=`date` ?
<reppel> or, more general
<reppel> what's the syntax of the env keyword? :)
<Keybuk> _ion: the "master job" stuff we talked about last week is working out really well
<Keybuk> thanks!
<_ion> Nice
<_ion> Thanks to you, you're the one who did all the work. :-)
<Keybuk> it seems that pretty much every command does the right thing now
<Keybuk> still got to test the timing of replacement instance jobs properly
<Keybuk> I tried it on monday, and I'm not sure it worked
<Keybuk> quest scott% whois sbin-init.org 
<Keybuk> NOT FOUND
<Keybuk> tempting ;)
<AlexExtreme> hehe
<AlexExtreme> you should ;)
<Keybuk> wtf?
<Keybuk> "pointer type mismatch in conditional expression"
<Keybuk> wing-commander util% sudo ./initctl --show-ids start tests/foo
<Keybuk> tests/foo [#43]  (start) waiting
<Keybuk> tests/foo [#43]  (start) starting
<Keybuk> tests/foo [#43]  (start) pre-start
<Keybuk> tests/foo [#43]  (start) spawned, process 20549
<Keybuk> tests/foo [#43]  (start) post-start, process 20550
<Keybuk>         main process 20549
<Keybuk> tests/foo [#43]  (start) running, process 20549
<Keybuk> -- 
<Keybuk> that looks nicer
<_ion> Cool
<Keybuk> wing-commander util% sudo ./initctl --show-ids status tests/inst
<Keybuk> tests/inst [#29]  (instance)
<Keybuk>     (start) running, process 20617
<Keybuk>     (start) running, process 20619
<Keybuk>     (start) running, process 20621
<Keybuk> -- 
#upstart 2007-03-08
<HTSJacket_> Hello, I am try to write an event for upstart 0.2.7 that needs input from the keyboard.  I've put "console output" as the last line.  Am I heading in the wrong direction?  Thanks for any help you may be able to give!
<HTSJacket_> the three lines in my event are: start on startup          exec /usr/bin/passwd         console output
<HTSJacket_> I've been testing with no splash... but I guess I am misunderstanding the concept of /dev/console... how would I switch to a tty to get the input?
<fatal> Could this be correct or should it be fixed some other way? http://fatal.se/tmp/upstart-sig.diff
<_ion> fatal: You probably should send it to Keybuk or the mailing list.
<fatal> I probably fucked something up, so I'll wait a while more before spreading it around too much... I just posted it to http://bugs.debian.org/413944 ... hopefully "djpig" will do another build attempt on sparc soon and verify if it's enough to build...
<Keybuk> *sigh*
<Keybuk> every time I try to explain or demonstrate how upstart works, I find buts
<Keybuk> bugs too
* Keybuk found two state transition bugs last night
<Keybuk> the diagram says that pre-stop to running should not emit a "started" event, because we never emitted stopping or stopped.  However the code did emit a started event again, and also didn't "forget" the reason that the job was tried to be stopped.
<Keybuk> the other was that the diagram and code both said that starting to waiting shouldn't emit "stopped"; however this transition occurs if respawn/restart fails, so we do need to emit stopped
<_ion> It occurs to me that there might be nice state machine generators that generate both efficient code *and* a graphviz-style diagram, which could be checked for errors. They probably have the same problems as yacc has as a parser generator (which is why you wrote your own config parser).
<_ion> Btw,
<_ion> to110450 < fatal> Could this be correct or should it be fixed some other way? http://fatal.se/tmp/upstart-sig.diff
<_ion> to113739 < _ion> fatal: You probably should send it to Keybuk or the mailing list.
<_ion> to115309 < fatal> I probably fucked something up, so I'll wait a while more before spreading it around too much... I just posted it to  http://bugs.debian.org/413944 ... hopefully "djpig" will do another build attempt on sparc soon and verify if it's enough to  build...
<Keybuk> http://codebrowse.launchpad.net/~keybuk/libnih/main/revision/scott%40netsplit.com-20070213153816-p1uyfqil3b33jt2w?start_revid=scott%40netsplit.com-20070302112615-e8kojdbnxg2pytz0
<Keybuk> http://codebrowse.launchpad.net/~keybuk/libnih/main/revision/scott%40netsplit.com-20070213180004-442ndyfx5pq1a70i?start_revid=scott%40netsplit.com-20070302112615-e8kojdbnxg2pytz0
<_ion> Ah. :-)
<_ion> keybuk: Btw, have you had time to inspect the delayed_watch changes?
<_ion> Of course, there are more acute things.
<Keybuk> yeah I've looked over them quite a bit
<Keybuk> my plan is to integrate your patch directly into nih/watch.c, since it's useful enough that it should be done by default
<_ion> Ok, nice.
<Keybuk> it doesn't eliminate the need to make sure that handling functions are idempotent, but it does at least eliminate some of the strange churn with the way editors make backup files, or write over other files
<Keybuk> (random)
<Keybuk> the difference in languages is incredible
<Keybuk> upstart would be substantially larger and more complex if it *weren't* written in C
<Keybuk> but initctl would be substantially smaller and simpler if it was written in something like Python
<_ion> Heh
* Keybuk tries to work out what's left to do to initctl
<wasabi_> merging huge branches of code which have been independent for 2 months is pretty mindnumbing.
<wasabi_> </random>
<Keybuk> yeah
#upstart 2007-03-09
<Keybuk> morning
<_ion> time of day
<Keybuk> ugh, SoC
* Keybuk might put some upstart ideas on there
<Keybuk> heh
<fatzeus> hi, i've some trouble compiling upstart
<fatzeus> configure runs fine, but when i give make:
<fatzeus> cfgfile.c: In function `cfg_stanza_limit':
<fatzeus> cfgfile.c:1776: error: `RLIMIT_NICE' undeclared (first use in this function)
<fatzeus> ?
<Keybuk> fatzeus: what are you trying to compile it on?
<Keybuk> Distribution?  gcc version?  glibc version?  kernel version?
<fatzeus> Gentoo
<fatzeus> let me check the version..
<fatzeus> gcc 3.3.6
<fatzeus> kernel 2.6.19.2
<fatzeus> glibc 2.3.5
<Keybuk> it's likely that both your gcc and glibc are too old
<Keybuk> upstart needs a reasonably up to date system
<Keybuk> RLIMIT_NICE was added in 2.6.12; so if your glibc is older than that, it might not have the prototype
<fatzeus> i see...there isn't a minimum system requirement
<fatzeus> ?
<fatzeus> i would like to say..wich version is required
<Keybuk> recommended system is GCC 4.1, glibc 2.5, kernel 2.6.20
<fatzeus> uhm ok...i didn't see that in the README...i'll try to upgrade so
* Keybuk should probably put something in the README sometime
<Keybuk> \o/
* Keybuk finally pushes the new initctl
<AlexExtreme> \o/
<AlexExtreme> mmm
<AlexExtreme> the launchpad beta is really nice
<Chetwin> Hi all.  I have an interesting issue
<Chetwin> When I have restricted modules installed, my boot process hangs 1/2 way through for about 30 - 45 seconds
<Chetwin> Without restricted modules installed, it boots very quickly
<Chetwin> And advice?
<Chetwin> Any*
<AlexExtreme> not an upstart problem, you should ask in #ubuntu
* ..[topic/#upstart:Keybuk] : Upstart 0.3.7 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | http://codebrowse.launchpad.net/~keybuk/upstart/main/changes | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo
#upstart 2007-03-10
<Keybuk> *bounce*
<AlexExtreme> hey
<AlexExtreme> i'll test out 0.3.7 tomorrow hopefully
<Keybuk> cool
<Keybuk> I've not had any death threats yet, so it seems to be working
<AlexExtreme> heh
<Keybuk> already thinking what to put in the next version
<Keybuk> think the big change will have to be re-implementing restart
<_ion> keybuk: The resources idea sounds great.
<Keybuk> difficult it is deciding which state it needs to stay in
<Keybuk> start/waiting I gues
<_ion> keybuk: It would be nice if a shell script could make the 'uses' information.
<_ion> E.g. block-device-added could find out the actual physical device for any of /dev/sda1, /dev/mdsomething and /dev/lvm-volumegroup/something, and say 'uses $DISKNAME' based on that.
<_ion> s/block-device-added/the fsck job/
<Keybuk> why would the disk size make a difference?
<_ion> Size?
<Keybuk> oh
<Keybuk> dunno where I read that
* Keybuk blames the wine
<_ion> :-)
<Keybuk> yeah, the problem there is you'd have to either include that in the event, or compute it in the jobs
<Keybuk> I'm inclined to suggest the event is better there though, since it probably *has* that information in the first place
<Keybuk> and it's cheaper than calculating it on every single job
<_ion> Good point.
<Keybuk> it's just DEVICE=$(readlink /sys$DEVPATH/device) after all
<_ion> For LVM and MD, /sys/block/$foo/slaves seems to be the right way to find the physical device.
<Keybuk> yeah, it'd be annoying to code all the different logic into the "check the filesystem" event
<Keybuk> uh job
<Keybuk> AND any other job that wants it
<_ion> True.
<Keybuk> much easier to handle it in the specific events
<Md> be sure to check a > 2.6.20 kernel with the compat sysfs links disabled :-)
<_ion> Oh, 'slaves' is deprecated?
<Keybuk> no, device is going away
<_ion> Ah
<Keybuk> because /sys/block/hda itself is a symlink
<Keybuk> like I said, much easier to put this into the event emission
<Keybuk> Md: that hasn't happened yet though?
<Md> what?
<Keybuk> the move of block devices to under the physical device
<Keybuk> (which means the device symlink is still necessary)
<Md> I am not sure, I had to roll back because the 2.6.21rcsomething rawhide kernel broke resume from RAM on my system (any clue about how to debug this? the screen is not working, but I can reboot using magic sysrq)
<Keybuk> 2.6.20 here, /block/hda is still a directory
<Keybuk> that may be caused by the deprecated option though, looking at the code
<Keybuk> might have to try turning it off and see what happens
<AlexExtreme> wait
<AlexExtreme> umm
<AlexExtreme> wrong channel
<AlexExtreme> sorry
<cortana> dumb question, perhaps, but how stable are the contents of /sys?
<Md> not much so far
<Keybuk> about as stable as upstart's job definition syntax :p
<_ion> Excuse my ignorance, but what's the correct way to find the corresponding /sys/block/... path for a file in /dev, e.g. sda*, md*, mapper/*? Comparing the contents of /sys/block/**/dev to the device types of the /dev files probably works, but there's a better way, isn't there?
<Md> _ion: udevinfo -n I think
<Keybuk> udevinfo -q path -n hda1
<Keybuk> though you're not *really* supposed to use udevinfo as a database <g>
<_ion> Thanks. Works for sda1 and md0, but not /dev/mapper/*.
<Keybuk> did you try dm-0 as the name?
<Md> _ion: because these are not managed by udev
<Keybuk> udevinfo -q path -n dm-0
<Keybuk> Md: they are in Ubuntu
<_ion> "no record for 'dm-0' in database" (an Edgy box)
<Keybuk> hmm
<Keybuk> dunno how to make a devmapper device
<Keybuk> dmsetup create foo just blocks
<Keybuk> ah
* Keybuk pressed ^D
<Keybuk> wing-commander scott# udevinfo -q path -n mapper/foo
<Keybuk> /block/dm-0
<_ion> Funny, doesn't work here.
<Keybuk> hmm
<Keybuk> feisty?
#upstart 2007-03-11
<Keybuk> Md: the CONFIG_SYSFS_DEPRECATED option makes some amount of difference
<Keybuk> a bunch of stuff in /sys/class gets turned into symlinks and moves under /sys/devices instead
<Keybuk> but doesn't seem to change /sys/block at all yet
<Keybuk> interesting
<Keybuk> initctl emit doesn't seem to always work
<Keybuk> except the not working seems to be consistent
<_ion> I'll try to get around to writing a small C tool that works like this: 'foo --dev /sys/block/sda/sda1' prints '/dev/sda1', 'foo --sys /dev/sda1' prints '/sys/block/sda/sda1', 'foo /dev/volumegroup/foo' prints '/sys/block/dm-0' (--sys is the default, as opposed to --dev), Both 'foo --slaves /sys/block/dm-0' and 'foo --slaves /dev/volumegroup/foo' print '/sys/block/md1', 'foo --physdev /dev/volumegroup/foo' prints '/sys/block/sda /sys/block/sdb', 'foo ...
<_ion> ... --dev --physdev /dev/volumegroup/foo' prints '/dev/sda /dev/sdb'. Also --short would omit either the '/sys/block/' or the '/dev/' prefixes from the output.
<Keybuk> where'd we use that?
<Keybuk> assuming you generate the events from udev, you already have that information?
<_ion> You have the information about what physical device any partition is, whether it's on LVM or MD or a combination of those?
<_ion> device(s), that is.
<Keybuk> it's quite hard to determine "physical device" for LVM or MD :p
<Keybuk> it might be several
<_ion> It's not hard, and one of the examples showed the tool printing several devices because of RAID. :-)
<_ion> I did some prototyping for the functionality in sh,
<_ion> % foo() { local syspath="${1#/sys/block/}"; syspath="${syspath%%/*}"; set -- $(ls -1 /sys/block/"$syspath"/slaves); if [ "$*" = "" ] ; then echo "$syspath"; else for file in "$@"; do foo "$(readlink -f /sys/block/"$syspath"/slaves/"$file")"; done; fi; }; for f in dm-0 md1 sda; do foo "$f" | xargs echo "$f":; done
<_ion> dm-0: sda sdb
<_ion> md1: sda sdb
<_ion> sda: sda
<_ion> Also: sda/sda1: sda
<Keybuk> *nods*
<AlexExtreme> <off-topic>i'm installing ubuntu edgy server edition, does anyone here know where it's default location for apache's DocumentRoot is if I select the LAMP server option?</off-topic>
<wasabi> /var/www
<AlexExtreme> thanks
<wasabi> i assume there's some very compelling reason why you didn't just read /etc/apache2
<AlexExtreme> i haven't installed it yet, i'm just asking because i need to know what to do with the partitions
<_ion> http://tnx.nl/php.jpg
<wasabi> haha nice
<AlexExtreme> :P
<wasabi> Oh. Use LVM.
<wasabi> THen when I turn out to be wrong, you can fix it.
<AlexExtreme> Yeah, I will :)
* Starting logfile irclogs/upstart.log
<Keybuk> oh
<Keybuk> so that's why it doesn't work if you try and emit an event that stops an instance job
<Keybuk> Mar 11 17:51:42 wing-commander init: job.c:714: Assertion failed in job_change_goal: (! job->instance) || (job->instance_of != NULL)
<Keybuk> Mar 11 17:51:42 wing-commander init: Caught abort, core dumped
* ..[topic/#upstart:Keybuk] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | http://codebrowse.launchpad.net/~keybuk/upstart/main/changes | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo
#upstart 2008-03-03
<sadmac> Keybuk: are you here?
<Keybuk> sadmac: hi
<Keybuk> ion_: did you get a chance to read through http://upstart.ubuntu.com/wiki/JobAtomicity ?
<ion_> Thanks for pointing it out, will read.
<sadmac_> Keybuk: initctl start isn't behaving like it should
<sadmac_> It blocks until the job is stopped again, rather than until its started.
<Keybuk> did you declare the job as a service?
<sadmac_> Keybuk: ...I'm guessing not. What's needed to do that?
<Keybuk> "service"
<Keybuk> or "respawn"
<sadmac_> ahh.
<Keybuk> there's some debate there about which is the right default
 * sadmac_ needs a kvm with network support
<sadmac_> hard to test upstart through ssh
<Keybuk> heh
<sadmac_> Keybuk: if a pre-start script returns nonzero, does the job not run?
<Keybuk> right
<Keybuk> the job will fail
<sadmac_> perfect
<Keybuk> all scripts are run with -e too
<sadmac_> ahh, that explains some things I saw earlier
 * Keybuk believes in properly written shell scripts ;)
<ion_> -e ftw.
<sadmac_> It gets interesting when you're trying to debug stuff, and your ls's and tty's are failing and bringing everything to a halt
<Keybuk> heh
<sadmac_> But now rhgb should work :D
<ion_> You can always say set +e temporarily.
<sadmac_> It makes me all tingly
<ion_> âExtra handling is required in both the pre-start and post-stop scripts depending on this variableâ
<ion_> keybuk: post-stop?
<Keybuk> ion_: ref?
<ion_> keybuk: The http://upstart.ubuntu.com/wiki/JobAtomicity page you mentioned. :-)
<Keybuk> ion_: that's correct
<Keybuk> ie. start apache HTTPS=yes
<Keybuk> HTTPS=yes should be set in post-stop
<Keybuk> since it might have to undo things done in pre-start
<ion_> keybuk: Does that conflict with what we talked about earlier, or am i missing something?
<Keybuk> no
<Keybuk> what we talked about earlier was something like
<Keybuk>   stop on wibble
<Keybuk> initctl emit wibble WIBBLED=YES
<Keybuk> the pre-stop script will have two extra environment variables
<Keybuk>   WIBBLED=YES
<Keybuk>   UPSTART_STOP_EVENTS=wibble
<Keybuk> in addition to what all the other processes get
<Keybuk> post-stop doesn't have those variables
<ion_> Alright
<ion_> keybuk: Wouldnât it be better for multiple concurrent stop requests all blocked?
<ion_> keybuk: And also if concurrent start requests all blocked until itâs running or it fails?
<Keybuk> I'm not sure
<Keybuk> what would be the benefit of multiple stop/start requests all blocking
<Keybuk> [1] start apache HTTPS=yes
<Keybuk> [2] stop apache
<Keybuk> [3] start apache HTTPS=no
<Keybuk> surely #1 should be cancelled and unblocked by #2
<ion_> Yes
<Keybuk> it shouldn't subsequently reblock because #3 happens
<ion_> [1] start apache HTTPS=yes
<ion_> [2] start apache HTTPS=no
<Keybuk> #2 will fail because it's already started
<ion_> apache should start with HTTPS=yes, but both should block IMHO.
<ion_> Oh
<Keybuk> it has to fail, because even if it said "ok, and I'll block" it's lying to you
<ion_> Thatâs okay, too.
<Keybuk> (since it doesn't result in an apache with no http)
<Keybuk> start will fail if the goal is already
<Keybuk> +start
<Keybuk> stop will fail if the goal is already stop
<ion_> Yeah, iâm fine with that.
<Keybuk> it used to be that in the 1/2/3 example above, #1 would actually block until apache stopped again
<Keybuk> and #2 would block for the same length of time
<Keybuk> that seemed wrong to me
<Keybuk> if it's not going to start, it should unblock immediately and return an error code
<ion_> Right
<Keybuk> likewise the "stop apache" should unblock and return an error code when someone on another console tries to start apache again
<ion_> Aye
<sadmac> Keybuk: ...I did evil
<sadmac> Keybuk: http://sadmac.fedorapeople.org/rhgb
<sadmac> put the tea down
<Keybuk> heh
<Keybuk> doesn't seem bad to me
<Keybuk> I like the pre-start exec test -x thing :)
<Keybuk> you know that post-start will be run*after* rhgb --no-daemon right?
<Keybuk> ah, no, you appear to be deliberately waiting for the pts it creates
<Keybuk> so that's right
<Keybuk> pop-tty should probably be in the pre-stop script
<Keybuk> otherwise the pty will be gone while rhgb isn't
<Keybuk> but hmm, pre-stop isn't run when it dies
<Keybuk> so yeah, post-stop it'll have to be
<sadmac> busy-waiting is scary.
<sadmac> Keybuk: we could reeeely improve the elegance of all this if we could ship a working logd
<ion_> Perhaps write a small script that uses inotify to wait for the file.
<sadmac> ion_: thinking about that. Is there a shell exposure of the necessary forms of inotify?
<ion_> Uh, i meant program, as in a C program, unless something equivalent already exists.
<sadmac> ion_: ahh. yeah, I might.
<ion_> There seem to be tools using inotify.
<ion_> inotify-tools - command-line programs providing a simple interface to inotify
<ion_> iwatch - realtime filesystem monitoring program using inotify
<ion_> iwatch seems to depend on Perl.
<ion_> I donât know how they handle [ -e /foo ] || someinotifyprogram /foo when /foo appears after [ ] but before someinotifyprogram.
<sadmac> ion_: I have it inotify based now :)
<sadmac> I'll see what the others concerned think
<ion_> What did you use?
<sadmac> ion_: inotifywait -m /dev/pts 2> /dev/null | grep -m 1 "CREATE" > /dev/null
<ion_> How about if /dev/pts/0 gets created before inotifywait is run?
<sadmac> ion_: its in an if [ -e ] block
<ion_> Thereâs still a race condition. :-)
<sadmac> a very small one
<ion_> Arenât they all? ;-)
<sadmac> and as long as this damn thing takes to start I'm not worried.
<ion_> Better start watching the directory first, then check for the fileâs existence, and continue watching if the file doesnât exist.
<Keybuk> sadmac: logd strikes me as a bit of a hack
<Keybuk> it shouldn't exist, instead one of the other logging daemons should be patched
#upstart 2008-03-04
<sadmac> Keybuk: what do you have in mind?
<sadmac> Does the pid of the process get sent to post-start in any manner?
<keesj> Hi
<keesj> I finished my state machine thingy.
<keesj> I now need to send event from within the kernel. it that possible?
<Keybuk> sadmac: "status" will give it to you
<keesj> re
<keesj> I have two more interesting questions :P
<keesj> it looks like when I perform an emit from one jobs it waits for the emit to be processesd before it returns
<keesj> is there a way around this? (my job does a pivot_root) 
<keesj> hmm --no-wait helps
<Keybuk> keesj: right, you found it ;) --no-wait <g>
<Keybuk> also make sure the job is configured right
<Keybuk> if the emit is waiting for the job to stop again, and it's a daemon, you need either "service" or "respawn" in the job
<Keybuk> then emit will only wait until it's started
<sadmac_> Keybuk: so... logd... how do we replace it?
<Keybuk> define what we want ;)
<Keybuk> for me the main thing is to be able to capture output from jobs
<Keybuk> and have that logged and not lost
<Keybuk> (even if filesystem not mounted)
<Keybuk> and maybe even mail that (cron-like)
<keesj> what would service do?
<sadmac_> Keybuk: pushing it into syslog would do most of that.
<keesj> cool, after a pivot root and a kill 1 it sill works (init apparently reloaded from a different partition)
<Keybuk> sadmac_: indeed
<sadmac_> Keybuk: so the issue is: how do we attach a reliable file descriptor to processes and how do we get the input from there to syslog
<Keybuk> sadmac_: right
<Keybuk> and e.g. how does upstart tell the logging daemon that the output of a particular job should be e-mailed out
<Keybuk> (since the job failed)
<sadmac_> Keybuk: I'd assume upstart would have pipes open to the programs being logged, and simply stuff the output to syslog
<Keybuk> that means init has to do quite a bit of work for every process running though, no?
<sadmac_> Keybuk: is there a way to open a socket direct to syslog?
<sadmac_> Keybuk: if we want to keep an external daemon, using ptys for each bothers me less and less.
<Keybuk> yeah, the problem then is when that logging daemon dies
<Keybuk> strange things happen to shell scripts
<sadmac_> Ahh, yeah, if you loose the master fd the pty still drops
<sadmac_> I know what kind of IO we need, and I can write a kernel module to support it, but I don't like the idea of pushing that upstream :(
<Keybuk> hehe, indeed
<sadmac_> That's what I need to do, find some kernel devs. There's got to be a mechanism for this.
<Keybuk> there probably is already
<Keybuk> I just haven't read the relevant section of Stevens yet
<Keybuk> logd is quite low on my priority list right now
<Keybuk> the existing one "works" for people that want it
<sadmac_> Keybuk: which book is Stevens?
<Keybuk> any of his
<Keybuk> his Unix Network Programming series will have the likely answer
<Keybuk> since that covers all types of sockets, file descriptors and IPC
<sadmac_> ahh, that one
<sadmac_> Keybuk: I've got it :)
<sadmac_> Keybuk: Pipe it to a file in /dev/shm
<Keybuk> the book?
<Keybuk> /dev/shm isn't mounted when init starts
<sadmac_> It could be. For us at least
<sadmac_> Hmm, and it turns out it doesn't spool the way I had hoped
<Keybuk> some kind of shared ring buffer would be ideal
<Keybuk> so the app could output freely
<Keybuk> and a logging daemon could pick it up and read from it
<Keybuk> but if it didn't, that wouldn't be bad
<sadmac_> exactly
<sadmac_> in fact what we need is very nearly the example from the linux device drivers book.
<Keybuk> heh
 * sadmac_ looks at list of known major numbers in linux kernel
<Keybuk> right, back tomorrow
 * Keybuk heads to london
<sadmac_> damn. he left
#upstart 2008-03-05
<sadmac_> Keybuk: how do you feel about fusefs?
<Keybuk> sadmac_: in what kind of sense?
<sadmac_> Keybuk: In the sense of solving your logd problem
<Keybuk> how would that help?
<Keybuk> is there anything you can do with fusefs that you can't do with any other fs?
<sadmac_> Keybuk: we can create those ring buffer files without having to submit a kernel patch
<Keybuk> you can do that with a tmpfs
<sadmac_> how's that?
<Keybuk> well, ish
<Keybuk> it wouldn't be a ring
<sadmac_> and it would keep growing through the life of the system
<sadmac_> s/system/service
#upstart 2008-03-07
<Keybuk> *sigh*
<Keybuk> I wish upstart's test suite wouldn't drop a core file
<Keybuk> but I don't see any way of fixing that
<Keybuk> (unless anyone knows a syscall that you can invoke on a child process to find out the name of the core file it generated? :p)
<sadmac_> Keybuk: I think you pass a parameter to that one that tells you whether an arbitrary binary/input will halt
<sadmac_> :D
<Keybuk> I can find out that it generated a core file
<Keybuk> since that's exactly what's being tested :p
<Keybuk> which means this test case leaves a core file in the working directory
<sadmac_> Inotify?
<Keybuk> bah,
<Keybuk> foiled by Ubuntu anyway
<Keybuk> apport steals the core file and writes it itself
<Keybuk> so it shows up after the test has completed
<ion_> Heh
<Keybuk> so, which config fields should undergo parameter expansion?
<Keybuk> the obvious ones to me are:
<Keybuk>   "stop on"
<Keybuk>   "instance"
<Keybuk>   "uses"
<Keybuk>   "depends"
<Keybuk> (where the last two are resources and file dependencies respectively)
<Keybuk> exec and script obviously don't need to undergo parameter expansion since a shell is used, which will do it for us
<Keybuk> "start on" can't, since it's matched for the config not the job
<Keybuk> (and it would be nonsensical anyway)
<Keybuk> "description", "author" and "version" don't seem to need it
<Keybuk> "emits" probably doesn't (and isn't used by anything anyway)
<Keybuk> "wait for", "respawn timer", "kill timer", "normal exit", "console", etc. are kinda tricky
<Keybuk> "umask", "nice", "limit", "chroot", "chdir", etc. likewise
<ion_> What kind of parameter expansion?
<Keybuk> so, say you have this job
<Keybuk>   start on tty-added
<Keybuk>   stop on tty-removed $TTY
<Keybuk>   instance $TTY
<Keybuk>   respawn
<Keybuk>   exec /sbin/getty 38400 $TTY
<Keybuk> -- 
<Keybuk> and the tty-added and tty-removed events have the TTY parameter set
<Keybuk> that job can be started/stopped by things like:
<Keybuk>   start getty TTY=ttyS0
<Keybuk>   stop getty TTY=ttyS0
<Keybuk>   emit tty-added TTY=ttyS0
<Keybuk>   emit tty-removed TTY=ttyS0
<Keybuk> the $TTY in the "stop on" is expanded at match time, against the $TTY variable stored in the job when it was started
<Keybuk> (the variables in the job come from the start request, which is either explicit or the combination of the events)
<Keybuk> I've also suggested there allowing the instance stanza to be expanded
<Keybuk> this would provide the instance match
<Keybuk> so you could have one instance of the getty job running for each unique value of the $TTY variable
<Keybuk> if you did
<Keybuk>   start getty TTY=ttyS0
<Keybuk>   start getty TTY=ttyS0
<Keybuk> the second one would fail with "already running"
<Keybuk> (the $TTY in the exec is actually *NOT* undergoing upstart parameter expansion, the entire exec string is passed to a shell, so /bin/sh expands that with the environment)
<Keybuk> the question is, what other stanzas should undergo parameter expansion?
<ion_> Right
<sadmac_> Keybuk: can start on use parameter matching? i.e. start on hal.have_tty TTY==ttyS0 ?
<Keybuk> sadmac_: yes
<Keybuk> though it's just TTY=ttyS0
<sadmac_> cool.
<Keybuk> (HAL is an entire WORLD of pain though)
<Keybuk> do you know how difficult it would be to have an event or state to simply say, for any given HAL udi, "available"/"not available" ? :)
<sadmac_> "I'm sorry, Dave, but I'm afraid I can't do that"
<Keybuk> something (and here's the problem already) would listen for org.freedesktop.Hal.Manager.DeviceAdded and DeviceRemoved signals
<Keybuk> also NewCapability as well
<Keybuk> those signals only contain the object ref, so are pretty useless
<Keybuk> the something would then need to probe the device
<Keybuk> so it needs to know in advance what kinds of devices it's actually looking for
<Keybuk> as well as, for each device, listen for PropertyModified signals
<Keybuk> ion_, sadmac: so, any comments?
<ion_> Not yet. Too tired for the synapses to fire. :-)
<ion_> Sounds good so far.
<Keybuk>   umask $UMASK
<Keybuk> I don't think that kind of thing should be allowed
<ion_> I canât think of a use case for that.
<Keybuk> aye, me neither
<Keybuk> I think the same applies for everything process-setup wise
<Keybuk> so console, umask, nice, limit, chroot & chdir shouldn't be expanded either
<Keybuk> if you reeeeally want that, after all, you can just call things in the script
<ion_> Indeed.
<Keybuk> respawn related things like respawn timeout, kill timeout & normal exit don't make sense to me to be expanded
<ion_> Ack
<Keybuk> which pretty much just leaves the newer things
<Keybuk> "stop on" definitely makes sense to match against the events found by "start on"
<Keybuk> so no argument there
<Keybuk> and I think using it for instance limiting makes sense too
<Keybuk> "uses" is about locking, so there is actually a use-case for it
<Keybuk>   start on block-device-added
<Keybuk>   uses $DEVICE
<Keybuk> would be a job that locked out any other job using $DEVICE
<ion_> Is there a way to do something equivalent to /lib/udev/watershedâs functionality with âusesâ or something else?
<Keybuk> something like that is an idea on the TODO list, yeah
<Keybuk> the main difference between uses and watershed is that in the former, all jobs are queued
<Keybuk> whereas with watershed, only one needs to be queued
<ion_> Yep
<ion_> Would be nice if watershed were in /bin, btw. :-) Itâs useful outside udev as well.
 * Keybuk is amused
<Keybuk> an English sci-fi magazine (SFX) did a summary of Peter Petrelli's powers,
<Keybuk> working out who they came from, and what other ones he might possess by inference
<ion_> Heh
<Keybuk> they first of all worked out that since his absorption appears instant, he will always have the upper hand on Sylar since the minute they meet, Peter will also have whatever other powers he's gained in the meantime
<ion_> Yep :-)
<Keybuk> then they worked out that Peter's met the Haitian, so he must have the power to stop Sylar's powers whenever they meet
<Keybuk> (unless the Haitian's power inherently stopped Peter from absorbing it -- possible writer loophole)
<ion_> Hehe
<Keybuk> finally obviously Peter has met Hiro, and absorbed his powers
<Keybuk> so all Peter needs to do is use Molly's powers (they met in S1 finale) to find everybody else
<Keybuk> absorb all their powers
<Keybuk> (quick and easy using teleportation)
<Keybuk> and then go back in time, and meet himself
<ion_> :-)
<Keybuk> thereby giving his younger self all the powers of everybody
<ion_> Heh
<Keybuk> they suggested his might be unlikely, since it would give the writers a bit of a problem
<ion_> Thereâs a big fuss about some guy scripting a wireframe 3D cube in Excelâ¢ <http://youtube.com/watch?v=vypETZbkU94> while we made a texturemapped raytraced tunnel in Excelâ¢ four years ago <http://youtube.com/watch?v=_whSnPErl7c>. :-P
<Keybuk> oops
<Keybuk> it appears I've broken "respawn limit"
<ion_> No problem, itâs just a matter of adding a sufficient amount of hardware.
<ion_> (E.g. if whatever you execute forks and exits)
<Keybuk> lol
<sadmac_> Keybuk: the counterstrike fans will prefer it this way
<Keybuk> the bug is that the instances get cleaned up now
<Keybuk> so if you stop; sleep 5; start ... the start won't be subject to any limit since the stop would have freed the struct that contains the count of how many times the instance has actually been started or stopped recently :)
<Keybuk> it's also not immediately obvious to me whether a respawn limit is per job or per instance
<Keybuk> e.g. dbus, it clearly doesn't matter since there can only be one
<Keybuk> but getty, if you start 6 different gettys in quick succession, does that mean that the 6th fails to start?
<Keybuk> or does it only apply should they attempt to respawn themselves?
<sadmac_> Keybuk: the latter. It is a REspawn limit
<ion_> Agreed.
<Keybuk> but for a multi-instance job, you can start as many as you like very very quickly
<Keybuk> should it apply to them?
<Keybuk> *shrug*
<sadmac_> Keybuk: no. If we need that functionality we need a separate feature for it
<Keybuk> I guess that respawn limit is useful if it just catches a job that's runaway respawning]
<Keybuk> ie. dying and resurrecting over and over again very quickly
<sadmac_> "instance count" or such
<Keybuk> in which case you actually don't want it to catch a restarting job
<Keybuk> or new job
<Keybuk> (manual restart, that is)
<Keybuk> if you do;
<Keybuk> while true; do stop --no-wait dbus; start --no-wait dbus; done
<Keybuk> then I guess that technically *shouldn't* trigger the respawn limit, since the request is external
<ion_> Yep.
<ion_> The user requested it to do something stupid instead of there being a problem. :-)
<sadmac_> You need it to keep the automated behavior from breaking things. If the admin breaks it its not upstart's business
<sadmac_> what happens when respawn limit is hit? Does it retry after some time?
<Keybuk> no, stops the job
<sadmac_> yeah, makes sense.
 * sadmac_ thinks about adding exponential backoff for jobs that contend on resources.
 * sadmac_ hits himself with a stapler
<ion_> Oh, i didnât know youâre into that.
<sadmac_> ion_: collision recovery?
<ion_> selfstapling
<sadmac_> ion_: yeah. office supplies make me feel like more of a man.
<sadmac_> Keybuk: I've been thinking about a potential new stanza called "expect" Where you could specify a way to tell that the service is ready
<ion_> Isnât the post-start script sufficient?
<sadmac_> ion_: not always. some services are dumb and there's no clean way to do it in bash.
<Keybuk> sadmac_: what kind of thing would we put there?
<sadmac_> Keybuk: "expect sigstop" for services that will stop themselves when prepped, "expect file /path" for services that are ready when a file appears (presumably a named pipe or unix domain socket)
<sadmac_> Keybuk: you can even (and this is scary) do a bit more ptrace magic. "expect syscall_listen"
<Keybuk> pretty much like the "wait for" in trunk then? :)
<Keybuk> wait for signal
<Keybuk> wait for fork
<Keybuk> wait for daemon
<sadmac_> ah.
<Keybuk> I'd planned to extend that to wait for a dbus name
<Keybuk> the listen() is kinda cool, though I'm not sure how easy that would be to trap
<sadmac_> Keybuk: wait for file would also be useful. rhgb is ready when a certain pts device appears.
<sadmac_> wait for file /dev/pts/0
<sadmac_> what's different between wait for fork and wait for daemon?
<Keybuk> one waits for a single fork()
<Keybuk> the other waits for a double fork()
<sadmac_> hm
<sadmac_> Keybuk: how hard would it be to get arguments/environment variables persistent across respawns in 0.3.9?
<sadmac_> Its becoming kind of a major issue
<Keybuk> I really don't understand why that is an issue
<Keybuk> sysvinit doesn't even *have* this
<Keybuk> so if you're only trying to replace sysvinit, why are you using events at all?
<sadmac_> Because we had something really ugly that's going to be easier to do the right way than it is to rebuild in upstart.
<Keybuk> I'm still unclear what you're actually trying to do :-/
<sadmac_> Keybuk: we want upstart to run agetty every time a serial console becomes available
<Keybuk> any serial console?
<Keybuk> you run getty on all serial ports?
<sadmac_> any serial console
<sadmac_> Keybuk: there's a nearly infinite potential number
<Keybuk> right
<Keybuk> so you're using an instance job?
<sadmac_> In effect I suppose
<sadmac_> oh
<sadmac_> that would be an issue.
<Keybuk> you know you can only start one job once, right? :)
<Keybuk> start getty
<Keybuk> ... ok
<Keybuk> start getty
<Keybuk> ... already running
<Keybuk> so you could only have one getty at a time with your job file anyway
<Keybuk> start on fedora.serial-console-available *
<Keybuk>  
<Keybuk> stop on runlevel [016]
<Keybuk> respawn
<Keybuk> exec /sbin/agetty /dev/$1 $2 vt100-nav
<Keybuk> (stealing from your bugzilla)
<Keybuk> won't work, since only one instance of that can run at a time
<Keybuk> (the "*" is kinda unnecessary too, btw)
<sadmac_> this I'm just realizing
<Keybuk> want an ugly way to fix it? :)
<Keybuk>     start on fedora.serial-console-available
<Keybuk>     instance
<Keybuk>     stop on runlevel [016]
<Keybuk>     exec /sbin/agetty /dev/$1 $2 vt100-nav
<Keybuk>     post-stop exec initctl emit fedora.serial-console-available $1 $2
 * Keybuk grins
<Keybuk> though that would respawn forever, ignoring the "stop on" bit
<sadmac_> oh, instance jobs are in 0.3.9?
<Keybuk> yeah
<Keybuk>     start on fedora.serial-console-available
<sadmac_> I thought that was still trunk only
<Keybuk>     stop on runlevel [016]
<Keybuk>     instance
<Keybuk>     exec /sbin/agetty /dev/$1 $2 vt100-nav
<Keybuk>     pre-stop script
<Keybuk>         touch /tmp/ok-to-respawn-$1
<Keybuk>     end script
<Keybuk>     post-stop script
<Keybuk>         [ -f /tmp/ok-to-respawn $1 ] || exit 0
<Keybuk>         initctl emit fedora.serial-console-available $1 $2
<Keybuk>         rm -f /tmp/ok-to-respawn
<Keybuk>     end script
<Keybuk> (using the fact that pre-stop won't be run if the getty stops unnaturally)
<Keybuk> and fix my obvious bugs of the ok-to-respawn filename :p
<sadmac_> It needs to respawn in that case too.
<Keybuk> ?
<Keybuk> oh, I have the logic backwards
<Keybuk> should be do-not-respawn :p
<sadmac_> Its making sense now.
<Keybuk> it's a hack, I know
<Keybuk> but it will suffice
<Keybuk> in trunk, the job would be somewhat simpler
<sadmac_> Keybuk: do you want to post that to bugzilla or should I?
<Keybuk> already done
<sadmac_> cool
<Keybuk>     start on fedora.serial-console-available
<Keybuk>     stop on runlevel [016] or fedora.serial-console-gone $TTY
<Keybuk>     instance $TTY
<Keybuk>     respawn
<Keybuk>     exec /sbin/agetty /dev/$TTY $BAUD vt100-nav
<Keybuk> -- 
<Keybuk> you might even stick
<Keybuk>     env BAUD=38400
<sadmac_> Keybuk: the big ugly in the 0.3.9 one is explicitly running /sbin/stop won't do anything
<Keybuk> in there so you don't have to supply $BAUD to start if you don't want to
<Keybuk> sadmac_: how do you mean?
<sadmac_> Keybuk: never mind
<Keybuk> running stop in a job script kinda hangs? :p
<sadmac_> Keybuk: I was following the logic wrong
<ion_> sadmac: http://gitweb.heh.fi/?p=ion/wait-for-file.git;a=blob;f=wait-for-file.c;hb=master
<sadmac_> Interesting
<sadmac_> ion_: I already have an inotifywait+bashism solution.
<sadmac_> though this might be better
<ion_> With a race condition. :-)
<sadmac_> ion_: ah, you were there
<ion_> I specifically open the inotify watch first, then check whether the file exists and decide whether to begin waiting for the appropriate inotify event.
<sadmac_> Hmm, I could build this in event-compat-sysv I suppose.
<ion_> (Iâm tired, there may very well be something wrong with the code. I did some quick testing and valgrinding and it seems to work.)
<sadmac_> cool :)
<sadmac_> ion_: thanks
<ion_> np
<sadmac_> ion_: is there a git:// url for this?
<ion_> http://gitweb.heh.fi/?p=ion/wait-for-file.git shows it: git://heh.fi/ion/wait-for-file.git
<sadmac_> cool
<Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080307213253-zd7x3w606y947zoj?start_revid=scott%40netsplit.com-20080307213253-zd7x3w606y947zoj
<Keybuk> \o/
<ion_> \o\
<Keybuk>     o      o     o    o     o    <o     <o>    o>    o
<Keybuk>    .|.    \|.   \|/   //    X     \      |    <|    <|>
<Keybuk>     /\     >\   /<    >\   /<     >\    /<     >\   /<
<ion_> ^     ^
<ion_>  
<ion_>    _
<sadmac__> pimp
<sadmac> (^-_-^)  <( -_-<) (>-_- )> (V-_-v)
<ion_> Did you know that your nick reversed is cadmas?
<sadmac> ion_: actually its camdas
<ion_> No, i reject that.
<sadmac> ion_: kernel panic - not syncing: total ordering property assertion failed
 * ion_ considers going to maintenance mode.
<sadmac> ion_: you can only fix code problems and configuration problems that way. It doesn't help you when math is broken.
<sadmac> Keybuk: so what else is outstanding?
<ion_> Bug #1 for one.
<Keybuk> sadmac: still a few bits for an 0.5.0
<Keybuk> name-limited instances
<Keybuk> and obviously D-BUS, which will involve rewriting initctl
<Keybuk> other 0.5 bits can then come after the release
<sadmac> Keybuk: what's with name-limited instances?
<Keybuk> so at the moment, there are two possibilities
<Keybuk> a job may only have one instance (the default)
<Keybuk> if you attempt to start when already started, you'll just get an error
<Keybuk> OR
<Keybuk> a job may have unlimited instances ("instance")
<Keybuk> if you attempt to start, you'll always get another job
<Keybuk> I want to add a third
<Keybuk> a job may have a limited number of instances, each identified by a unique name
<Keybuk> ("instance $TTY")
<sadmac> ahh
<Keybuk> if you attempt to start, it may start a new job OR fail because it's already started, depending on the value of $TTY you give
<Keybuk> that means, for example, that if you have a job like:
<Keybuk>   start on tty-added
<Keybuk>   stop on tty-removed $TTY
<Keybuk>   instance $TTY
<Keybuk> and you very quickly do
<Keybuk>   initctl emit --no-wait tty-added TTY=ttyS0
<Keybuk>   initctl emit --no-wait tty-removed TTY=ttyS0
<Keybuk>   initctl emit --no-wait tty-added TTY=ttyS0
<Keybuk> that will cause the *existing* instance to be restarted, rather than spawn a new one
<sadmac> ha
<sadmac> so for tomcat, say....
<sadmac> the tomcat instances might be named after the apps they are running
<Keybuk> right
<Keybuk> it's also the basis for an interesting way to permit multiple instances of things like apache
<Keybuk>   instance $CONFFILE
<sadmac> hm
<Keybuk>   exec apache2 -f $CONFFILE
<Keybuk> for example
<ion_> If i want to start such instances automatically on startup based on a list of apps in /etc/something, would i need another job to start those ones?
<Keybuk> that'd let you start as many instances as apache2 as you had conffiles
<Keybuk> ion_: only until we have file eventts
<ion_> Ah, right. Theyâll be a nice solution to that.
<sadmac> Keybuk: this is really important for the user session case
<sadmac> instance $SOMESESSIONUNIQUEPROPERTY
<Keybuk> yeah, you can be quite arbitrary
<Keybuk> instance $USER-$TTY-$BAUD-$FOO
<Keybuk> etc.
<Keybuk> that's why I decided to just expand environment there
<Keybuk> instance ${TTY:-notatty}
<ion_> Nice
 * Keybuk had fun writing that
<sadmac> Keybuk: you're going to want to talk about this to the PolicyKit folk
<Keybuk> If by "the PolicyKit folk", you mean davidz? ... :)
<ion_> No, heâs now DavidKit.
<sadmac> ion_: I still have the original david, its not kit built
<Keybuk> sadmac: I talk to david a fair amount
<sadmac> Keybuk: ah, cool
<sadmac> I'd imagine it will get interesting once we need policies around starting and stopping jobs for per-session tasks
<sadmac> DBus will probably give us a lot of that for cheap though.
<Keybuk> the trouble with Upstart is a tendancy for people to try and fix all their problems at once with it
<Keybuk> including myself
<sadmac> Keybuk: 0.5 will be able to simonize my car, right?
<Keybuk> user sessions are easy in Upstart, since a user session is just a collection of environment variables to set
<Keybuk> "simonize" ?
<sadmac> Its a fancy waxing job that I could be misspelling
<ion_> dict(1) knows simonize. :-)
<Keybuk> well, obviously misspelling since it should be "simonise" ;)
<ion_> :-D
 * sadmac just got britished
<ion_> Britised, you mean.
<Keybuk> not our fault you guys aren't keeping up with the updates to the language you're using ;)
 * sadmac git pull english
<Keybuk> (actually -ize vs. -ise is a long standing division between the major two British dictionary presses, but I digress)
<sadmac> I was really surprised when I found out you guys had an extra vowel in "Alumin[i]um." I just thought it was creative pronounciation.
<ion_> In which dialect do you pronounce pronunciation pronounciation? :-)
<sadmac> ion_: good question
<sadmac> pronounciation (n): The act of making something into a pronoun.
<ion_> In Finnish, pronoun is pronomini, but noun is substantiivi.
<sadmac> hm
<sadmac> prosubstantiivi
<sadmac> ^^If that's edible, I want some.
<ion_> No, but you can take it intravenously.
<sadmac> what's it do
<sadmac> ?
<ion_> It puts your mind to a state where you experience being on IRC, usually on #upstart@Freenode, and you have very vivid hallucinations about other people talking with you online.
<sadmac> Is Julia Child there?
<ion_> Youâll have to ask her.
 * sadmac expands his mind
<Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080307232034-k4dlc4humlxubprd?start_revid=scott%40netsplit.com-20080307232050-9u2sj8ld588t441q
<Keybuk> ^ name-limited-instance support
<sadmac> Keybuk: so that leaves DBus.
#upstart 2008-03-08
<Keybuk> I'm going to make a change to the state machine before that
<Keybuk> that won't take long to do, mostly just updating test cases
<sadmac> cool
<Keybuk> https://lists.ubuntu.com/archives/upstart-devel/2008-March/000589.html
* Keybuk changed the topic of #upstart to: Upstart 0.3.9 | http://upstart.ubuntu.com/ | http://irclogs.ubuntu.com/ | https://lists.ubuntu.com/archives/upstart-devel/2008-March/000589.html | http://upstart.ubuntu.com/wiki/OutstandingIssues
<Keybuk> http://upstart.ubuntu.com/wiki/ExpandEventVariables
<Keybuk> http://upstart.ubuntu.com/wiki/NamedInstances
<Keybuk> yay for writing specs after implementing them
<ion_> keybuk: Hehe
<Keybuk> I need to get a shuttle or some other super-lightweight computer
<Keybuk> it's very silly having an entire server here just for local DNS
<Keybuk> . o O { why don't I just install a lightweight DNS cache on the OpenWRT box }
<ion_> Iâve been planning to replace a PC runninhg OpenBSD with a Via Epia, Soekris or something like that for years. But all my money seems to go to other stuff than computers. :-)
<Keybuk> is funny, sometimes you write a spec and realise in doing so that it's pointless
<Keybuk> e.g. http://upstart.ubuntu.com/wiki/MandatoryJobEnvironment
<ion_> :-)
 * Keybuk gets the creeping feeling he'll need libdbus-nih (or libnih-dbus)
<ion_> Heh
<Keybuk> I love autoconf
<Keybuk> it's a great improvement on everything that's been written since
<ion_> ...
<ion_> :-D
<Keybuk> I added a libnih-dbus.la to libnih
<Keybuk> obviously, this can only be built if dbus development stuff is on the disk
<Keybuk> so autoconf checks for that
<Keybuk> if you have dbus, you get libnih-dbus
<Keybuk> if you don't, you don't
<Keybuk> obviously, you might want to suppress generating it; so you can configure --without-dbus or --with-dbus=no
<Keybuk> then it won't get built anyway
<Keybuk> or you might want to force generating it, just in case; so you can configure --with-dbus
<Keybuk> if it doesn't exist, configure will exit with an error
<Keybuk> that's just at the configure library
<Keybuk> applications like upstart will want to force dbus support since they always need it
<ion_> Alright
<Keybuk> so upstart has NIH_INIT([dbus]) in its configure.ac
<Keybuk> that acts as if --with-dbus was always specified, failing if it doesn't exist
<Keybuk> except it doesn't check the configure arguments (--without-dbus does nothing) and even doesn't show up the existance of that in the --help output
<Keybuk> I *love* autoconf
<ion_> Have you pushed that anywhere?
<Keybuk> not yet
<Keybuk> why?
<ion_> No reason, just looked at nih intending to look at the changes out of curiosity.
<Keybuk> haven't actually written the dbus stuff yet :)
<ion_> Ah, right. :-)
<Keybuk> I made dinner instead
<Keybuk> then mucked around with autoconf ;)
<Keybuk> gotta love the way half your desktop vanishes if you restart dbus
<ion_> Hehe, yeah. :-P
<ion_> irssi manages to restart itself preserving IRC connections, without forking even.
<ion_> Handy for upgrades.
<Keybuk> funny, I've hit the first dbus stumble already
<Keybuk> and I've only just got as far as the damned bus connection
<Keybuk> sometimes I think that fd.o/gnome/etc. people are utter morons
<ion_> Whatâs the problem?
<ion_> With dbus, that is. :-)
<Keybuk> dbus calls exit() if the socket is closed :p
<ion_> Ouch. :-)
<Keybuk> happily it sets that *right in the middle* of the dbus_bus_get function
<ion_> :-P
<Keybuk> hmm
<Keybuk> 090606 24012KT 9999 SCT025 PROB30 TEMPO 1117 26015G25KT 6000 SHRA SHGS SCT020CB
<Keybuk> somebody likes me
<Keybuk> weather starts to turn nasty just 30 minutes after my flying lesson is due to end
<Amaranth> having upstart exit when dbus goes away is bad, no? :)
<Keybuk> indeed
<Keybuk> it's similar to that moronic abort() if malloc() returns NULL in glib
<Amaranth> g_try_malloc
<Keybuk> "oh, bother, I can't be arsed to deal with errors - let's just go away"
<Keybuk> Amaranth: and how do you tell all the various glib internals that malloc to use that instead of g_malloc()?
<Amaranth> I understand the thought process that led to that in glib
<Keybuk> there were thought processes?
<Amaranth> If you're out of memory something _really_ bad has happened
<Keybuk> not true at all
<Keybuk> it's utterly the wrong way to view it
<Amaranth> well, glib is meant for use with desktop things
<Keybuk> if you're out of memory, you can't do what you were trying to do
<Keybuk> desktop things shouldn't vanish
<Keybuk> not without explanation
<Keybuk> not without a change to save their state
<Keybuk> etc.
<Amaranth> they will anyway, oom killer
<Keybuk> right now, if you open a large file in inkscape, half the desktop apps vanish
<Keybuk> oom killer is smart enough to normally kill the application using the most memory :p
<Amaranth> got me there
<Keybuk> in fact, not only half the desktop apps
<Keybuk> but half of the underlying daemon stoo
<Amaranth> although iirc handling malloc failure adds like 30-50% more code to your project
<Amaranth> so i guess people are lazy :)
<Keybuk> out of memory turns from a "damn, come back in a moment" problem to a fatal problem
<Keybuk> I disagree
<Keybuk> upstart handles every single malloc error
<Keybuk> and its code isn't huge as a result
<Keybuk> you either retry because it's important
<Keybuk> or you return a natural error progression that will abort the current operation
<Amaranth> how many times do you retry?
<Keybuk> you need that latter anyway since other things might go wrong
<Keybuk> always
<Keybuk> there are two solutions to out of memory:
<Keybuk> 1) block until there is memory
<Keybuk> 2) fail the current operation
<Keybuk> if you try and start a job in upstart, and it runs out of memory, it will return you an "Out of memory" error
<Keybuk> and the job will not be started
<Keybuk> and the state will remain clean
<Amaranth> that reminds me, whatever happened to the kernel sending a signal when memory is running low
<Keybuk> never heard of that one
<Amaranth> was thinking someone could setup a policy to stop certain services and throw out caches when that happens
<Amaranth> really?
<Amaranth> http://kerneltrap.org/Linux/Signaling_When_Out_of_Memory
<Amaranth> i only remember that because of SIGSEEDAMNITITOLDYOUSO
<Keybuk> heh
<Keybuk> never got implemented
<Amaranth> shame
<Amaranth> so is the malloc thing the reason why you have libnih?
<Keybuk> no
<ion_> Additionally, libnih doesnât have the general suckage glib has. :-)
<Keybuk> it's just the first of many, Many, MANY things I hate about glib
<Keybuk> ... gint
<Keybuk> the main loop has a well known race-condition which upstream refuse to fix
<Keybuk> the entire API is massively bulky and bloated
<Keybuk> g_very_long_function_names_since_nobody_cares_about_fitting_into_eighty_columns_these_days
<Amaranth> hehe
<Amaranth> i dunno, i use it from vala :)
<Keybuk> io channel support that assumes you always deal in streams
<Keybuk> inconsistent error reporting/handling
<Amaranth> but gobject
<Keybuk> random reimplementations of functions that are in libc (!!)
<Keybuk> gobject is pain
<Keybuk> gthread is so useless it's beyond a joke
<Amaranth> pain to write but gobject-introspection lets you do cool things
<Keybuk> gmobile is a bad wrapper around libltdl
<Keybuk> mobile?  
<Keybuk> gmodule!
<Keybuk> you don't *need* to do those cool things in C
<Keybuk> if you want that kind of thing, you should use C# or Python or some other high level language
<Amaranth> no, those cool things are "autogenerated bindings for every language"
<Keybuk> and how bad are those bindings normally? :)
<Keybuk> ever tried using, say, python-gtk ?
<Keybuk> Python's own help() function can crash Python!
<Amaranth> those aren't autogenerated :P
<Amaranth> all of the gnomey bindings in vala are autogenerated, seems to come out alright
<Amaranth> well, except glib, have to do that one by hand
<Keybuk> heh
<Keybuk> tbh, the main reason for libnih is just ... nih
<Keybuk> it's mostly cribbed from my "copy and paste" library of code, I just libraryfied it
<Keybuk> I like the nih_alloc pattern
<Keybuk> so it follows that I like a standard library of functions that follow the same general pattern
#upstart 2008-03-09
<Kamping_Kaiser>  /topic's answerd the question. thanks :)
<ion_> What? Someone reads topics?
#upstart 2009-03-02
<keesj> How do I get the right libnih for the 0.5 branch?
<keesj> *in bzr*
<Keybuk> bzr checkout -r tag:upstart-x.y.z libnih
<Keybuk> is 0.5.0 or 0.5.1, etc.
<keesj> thanks
<keesj> Keybuk: sorry I just subscribed you to my upstart branch and I don't know yet how to undo that
<sadmac> Keybuk: around?
#upstart 2009-03-03
<keesj> anybody having a 5.0+ system running
<keesj> 0.5
<sadmac> keesj: Keybuk might've had one
<sadmac> he had a boot chart for a mostly pure upstart system recently. forget which version it was
<keesj> I have something that kils mine http://www.paste-it.net/raw/public/l01613a/
<keesj> http://www.paste-it.net/public/kc01d79/ (result)
<Keybuk> traceback please
<keesj> somehow becasue of the respawn stanza things go wrong 
<keesj> Keybuk: I will work on that :p
<Keybuk> it should dump core from a child
<Keybuk> it'll be in /
<Keybuk> you may need to ulimit -c unlimited in the initramfs, of course
<keesj> I have a RO system 
<Keybuk> actually
<Keybuk> ignore the last bit, I patched upstart to always set ulimit to INFINITY :)
<sadmac> Keybuk: what are your thoughts on dealing with a system where multiple display managers are installed, and we want to run one of them?
<sadmac> (but never both)
<Keybuk> don't install two
<Keybuk> or use a system like alternatives
<sadmac> there's a pretty large chunk of Fedora users with full GNOME and KDE on the same system, so I'd like to get this right.
<Keybuk> how do you do it now?
<sadmac> we run a script called prefdm that checks for each of them and runs the first it finds.
<sadmac> and its ugly and bad and I hate it.
<Keybuk> you have alternatives in Fedora?
<sadmac> yeah. I don't know why we don't use it.
<sadmac> though I never understood how package managers worked with it.
<Keybuk> I don't think this is an upstart problem
<sadmac> Keybuk: what if each display manager wants different service management settings? (I wouldn't put it past the various desktop groups to collectively fail in this manner)
<keesj> http://www.paste-it.net/public/ge70991/ (without debugging symbols) but it's a raise 
<Keybuk> sadmac: alternatives handles all this already
<Keybuk> keesj: 6
<Keybuk> #1  0x4008c160 in abort () from /mnt/lib/libc.so.6
<Keybuk> Backtrace stopped: frame did not save the PC
<Keybuk> meh
<sadmac> Keybuk: from what I understand alternatives just changes the */bin symlink. it doesn't swap out configuration. especially not for other programs.
<Keybuk> it works today in Ubuntu
<Keybuk> if you install kdm and gdm, both have init scripts
<Keybuk> but only one of them runs
<sadmac> I'll look at that then.
<keesj> that part is not handled using the alternatives
<Keybuk> I thought it was handled by the file they write
<keesj> but generaly alternatives work pretty well , I can imagine the /etc/init.d/job.d/service_gdm is a symlink
<sadmac> my first thought was "well, Upstart has a way of reflecting the 'requires' relationship already. 'provides' and 'conflicts' seem like they'd follow."
<Keybuk> I think that overcomplicates things
<sadmac> depends. I'd want to see a complete 0.10 first
<sadmac> if its a fairly small change on top of that I'd say its worth having.
<Keybuk> I don't buy that argument
<Keybuk> we should only do things where it makes sense :p
<Keybuk> next you'll be asking for some kind of config handling in Upstart because your package manager sucks at managing /etc :p
<sadmac> alternatives pushes the concern into the packages. we have to modify the distributions (renaming binaries etc) and we have to do it in a very distro-specific way
<sadmac> a simple conflict solution in upstart means that this can come upstream in all the display managers.
<keesj> Keybuk: http://www.paste-it.net/raw/public/i0ad7ab/ better?
<Keybuk> hmm
<Keybuk> that looks like a different problem
<Keybuk> in fact, you might want to run "cont" there
<Keybuk> I assume that wasn't the core file?
<keesj> no that's the init
<Keybuk> how do you mean?
<keesj> I run gdbserver and attach to pid 1
<Keybuk> ah
<Keybuk> can you run "cont"
<Keybuk> SIGPIPE is peffectly normal
<keesj> I will do cont 
<Keybuk> sadmac: again, I don't buy that
<Keybuk> rah state changed from stopping to killed
<Keybuk> rah state changed from killed to post-stop
<Keybuk> rah post-stop process (32487)
<Keybuk> rah pre-stop process (32484) exited normally
<Keybuk> init:job_process.c:1103: Assertion failed in job_process_terminated: job->state == JOB_PRE_STOP
<Keybuk> zsh: abort (core dumped)  ./init
<Keybuk> eep
<Keybuk> 1103			nih_assert (job->state == JOB_PRE_STOP);
<Keybuk> (gdb) p job->state
<Keybuk> $1 = JOB_POST_STOP
<keesj> I need to go
<Keybuk> it left the running state when the main process ended
<Keybuk> while the pre-stop process was still running
<Keybuk> so when the pre-stop process died, it asserted
<Keybuk> keesj: please file a bug when you get back
<Keybuk> attach the job, and your output, etc.
<Keybuk> I think that the code in job_process_terminated that checks for post-start or pre-stop still running needs to be higher up before the "break" statements ;)
<Keybuk> but I'll need to make test cases and suchlike
<keesj> I will
<ion_> Thereâs a character in ST:TNG that looks just like MacGyver. http://heh.fi/tmp/tng-macgyver
<Keybuk> There's a character in Stargate SG-1 that looks just like MacGyver too
<ion_> :-D
#upstart 2009-03-04
 * keesj created two fresh bug reports this morning 
<keesj> me would like some feedback on https://bugs.launchpad.net/upstart/+bug/337665
<keesj> is is a bug or just and anoying feature
<Keybuk> keesj: it sounds like you're inferring ordering where none exists?
<keesj> Well not in the direct rules but clearly I think I defined that the services should be exclusive
<Keybuk> there's no such thing as an exclusive service though
<keesj> clearly :p
<Keybuk> you just defined two services that used each other's events to change their own state
<Keybuk> both can be running simultaneously
<Keybuk> if the event queue is paused, for example
<keesj> My understanding is that whenever service_b is started the service_b starting event is launched and therefore service_c will be stopped 
<keesj> but there is clearly a difference of interpretation between us
<Keybuk> that will happen, yes
<keesj> and why isn't service_b waiting for service_a to be stopped (or actlaly why doesn't service_a block the starting of service_b) ?
<Keybuk> whuh?
<Keybuk> let's break this down
<Keybuk> you have:
<Keybuk> A stop on starting service_b or starting service_c
<Keybuk> this means that A will be stopped should B be starting
<Keybuk> OR should C be starting
<Keybuk> --
<Keybuk> B start on starting service_c
<Keybuk> B stop on starting service_a
<Keybuk> this means that B will be started should C be starting
<Keybuk> and B will be stopped should A be starting
<Keybuk> --
<Keybuk> C nil
<Keybuk> this means that C is under full manual control
<sadmac2> Keybuk: where'd you get libnih's string hashing algo?
<Keybuk> keesj: so you do
<Keybuk> start A
<Keybuk> A is thus started
<Keybuk> B will be stopped, but is already at stop, so won't go anywhere
<Keybuk> start B
<Keybuk> B is thus started
<Keybuk> A will be stopped, as a result of the "starting B" event
<Keybuk> you now have
<Keybuk> A - stopping
<Keybuk> B - starting
<Keybuk> you then did
<Keybuk> start C
<Keybuk> there's two possible outcomes here
<Keybuk> actually, I think there's just one
<Keybuk> B will be started
<Keybuk> A will be started
<Keybuk> B is already running, so that's ok
<Keybuk> gnargh
<Keybuk> rewind
<Keybuk> sorry
<Keybuk> As and Bs confused
<Keybuk> you then did
<Keybuk> start C
<Keybuk> B will be stopped
<Keybuk> A will be started
<Keybuk> (result of starting C)
<Keybuk> B stopping will stop A
<Keybuk> so A will be stopped again
<Keybuk> I'd expect the result
<Keybuk> A stopped
<Keybuk> B stopped
<Keybuk> C running
<Keybuk> keesj: what do you see?
<Keybuk> ah
<Keybuk> sorry
<Keybuk> no ing
<Keybuk> start C
<Keybuk> A will be started
 * Keybuk gets all confused
<keesj> I see that B is started before A is stopped
<Keybuk> this is hard when you just use A and B and C as names
<Keybuk> keesj: don't use words like "before" or "after"
<Keybuk> Upstart has no concept
<Keybuk> what is the final result
<Keybuk> ie. if you sit down and leave it for five minutes
<Keybuk> what is the resultant system state
 * Keybuk retraces again
<Keybuk> start C
<Keybuk> starting C will start B, and stop A
<Keybuk> B is already running anyway
<Keybuk> A is already stopped anyway
<Keybuk> no?
<Keybuk> keesj: I'm sorry, but I'm completely confused as to what you're trying to demonstrate here
<sadmac2> Keybuk: will 0.10 still need to generate events for started/starting/stopping/stopped?
<Keybuk> sadmac2: eys
<Keybuk> sadmac2: the libnih string hash btw is FnV
<sadmac2> Keybuk: when do we need those events now?
<sadmac2> ah.
<Keybuk> keesj: just going back through this once more
<Keybuk> # start A
<keesj> now start B
<Keybuk> starting A -> stop B, but B is not running
<Keybuk> A is running
<Keybuk> # start B
<Keybuk> starting B -> stop A, so A will be stopped
<keesj> you will see that first A is stoppe and only after that b is started right?
<Keybuk> B is running
<Keybuk> A is stopped
<keesj> the after here is imporant
<Keybuk> right
<Keybuk> right, B starting is blocked on A stopping
<keesj> if you start a again you see the reverse happen first b is stopped and then only a is started right?
<Keybuk> right
<Keybuk> A starting is blocked on B stopping
<Keybuk> so we're in a state where B is running, A is stopped
<Keybuk> you start C
<Keybuk> starting C -> start B, but B is already running
<Keybuk> starting C -> stop A, but A is already stopped
<Keybuk> no?
<keesj> yes that is alright
<Keybuk> maybe you mean to do it the other way
<keesj> now start a
<Keybuk> we're in a state where A is running, B is stopped
<Keybuk> you start C
<Keybuk> starting C -> stop A
<Keybuk> starting C -> start B
<Keybuk> C will not start until A is stopped and B is started
<keesj> right
<keesj> but why doesn B also wait for a to be stopped, just like earlyer?
<Keybuk> why wouldn't it?
<Keybuk> B has nothing to do with A
<Keybuk> B was told to stop by C
<Keybuk> err told to start by C
<Keybuk> C will wait for B to start
<Keybuk> look at the chain
<keesj> and A was tols to stop by B right?
<keesj> told
<Keybuk> no
<Keybuk> A was told to stop by C
<Keybuk> starting C -> stop A
<Keybuk> starting C -> start B
<Keybuk> stopping A -> ...
<Keybuk> starting B -> stop A, but A is already being stopped
 * sadmac2 contemplates inventing Event Algebra
<Keybuk> it actually depends a bit which order it processes the events I think ;)
<Keybuk> oh, no it doesn't
<Keybuk> starting C -> start B
<Keybuk> starting C -> stop A
<Keybuk> starting B -> stop A, but A is already being stopped
<keesj> Indeed , there is already some code to first stop and after that start a job if it is stop and started
<Keybuk> stopping A -> ...
<keesj> right: starting B -> stop A, but A is already being stopped....
<keesj> this is where I would expect B to wait
<Keybuk> you want B to wait for A?
<Keybuk> but B wasn't told to stop by A
<Keybuk> start I mean
<Keybuk> B has no relationship with A in this scenario
<Keybuk> to do that
<Keybuk> stop on (starting service_b and starting service_c) or starting service_b or starting service_c
<Keybuk> (in A)
<Keybuk> hm
<Keybuk> no that won't work either
<Keybuk> stop on starting service_b and starting service_c
<Keybuk> is all that will do it
<Keybuk> but that won't give you your A/B flip-flop unless C is involved
<keesj> A was told to stop on starting B 
<Keybuk> no
<Keybuk> it wasn't
<Keybuk>  starting C -> stop A
<Keybuk>  starting C -> start B
<Keybuk>  stopping A -> ...
<Keybuk>  starting B -> stop A, but A is already being stopped
<Keybuk> A was told to stop on starting C
<Keybuk> so stop it did
<Keybuk> by the time B starting told it to stop, it was _already_ stopping
<Keybuk> you used "or"
<keesj> "stopping" is not enought 
<keesj> but what do you mean by senario?
<Keybuk> ?
<Keybuk> what do you mean by what do I mean? :p
<keesj> I don't understand . 
<keesj> you say < Keybuk> B has no relationship with A in this scenario
<keesj> but I am not aware of such a concept. In my understanding is that there is a state tree with events. B and A always have a relationship
<Keybuk> I think you're assuming a much more complicated system than exists ;)
<keesj> the bug IMHO is that A is already stopping b should wait .
<Keybuk> A just says it will be stopped if C starts *OR* B starts
<keesj> so I need to write a loop in service_b and wait until service_a is really stopped 
<Keybuk> I agree that such a feature would be desirable
<Keybuk> but it's impossible to implement given the way 0.5 works
<Keybuk> the problem is that stopping B just generates an event
<Keybuk> A is already stopping, so is no longer listening for stop events
<Keybuk> we shall have to make sure that "while not (B or C)" works
<keesj> hmm 
<keesj> Well I will try to find shorter term solution then :p
<sadmac2> Keybuk: fun problem for your 0.10 model:
<sadmac2> Keybuk: service A has "when not B; on q", service B has "when not A; on q". both services exist. q happens
<sadmac2> by exist I mean their dependencies have been found and a job struct has been created
<Keybuk> no problem there ;)
<sadmac2> Keybuk: which one starts would depend on the order of processing.
<sadmac2> if you start A, it precludes B. if you start B it precludes A
<sadmac2> Keybuk: care to elaborate?
#upstart 2009-03-05
<sadmac> Keybuk: ping
#upstart 2009-03-06
<maccam-sager> is any work being done on updating init-scripts? is the ubuntu branch going to be synced to 0.5.x in time for ubuntu jaunty?
#upstart 2009-03-08
<MarcWeber> Is there some logging support again or do I have to use script\n &> /var/log/foo \n end script ?
<keesj> in scripts?
<keesj> in 0.5.x upstart self tries to use syslog, for scripts it should be possible to lot to syslog but I have not seen that work
<keesj> the "easy" thing to do IMHO is to use the logger command
<MarcWeber> keesj: It's about reading error messages from startup scripts etc.
<MarcWeber> upstart-0.3 had its own (bitrotted) daemon to log stdout and stderr of the scripts into a file
<keesj> MarcWeber: how is this daemon called it that hte logd?
<MarcWeber> It was called logd
<MarcWeber> However using script &> file works fine in practise..
<keesj> Yes, , what I sometime do is a ( echo bla ; do this; echo bla ) | while read line ;do  echo "SCRIPT_NAME:" $line ; done
<geiseri_> hi, i have a even  that needs to wait for hal to be loaded, is there a way with the current upstart in Ubuntu intrepid to do this?
<pkt> perhaps you mean a service that needs to wait for hal ?
<geiseri_> well i want to start Xorg on boot for a live CD, but i guess the new Xorg wants to use hal to get input devices.
<geiseri_> i had an upstart event script in event.d in hardy, but when i upgraded to intrepid it stopped working
<geiseri_> diagnosis told me that it needed hal... so that is where i am stuck
<MarcWeber> I'm trying to add upstart-0.5.1 support to nixos now. init ist started then nothing happens. Probably the job files aren't found? Is there a simpler way to debug this than patching upstart to support running as pid2 and running strace?
<sadmac> MarcWeber: pass init=/sbin/init -v on the kernel command line
<damjan> Anybody here? I'm installing Upstart in ArchLinux, and on startup I get a "unable to set oom adjustment" so the first job is not started
<sadmac> damjan: your initrd needs to mount /proc
<damjan> it seems to me that upstart tries to write to /proc/xxx/oom_adj .. but /proc is not mounted when upstart 
<MarcWeber> sadmac :-) After starting udev before upstart I get some output as well now :-)
<damjan> sadmac: I'm not using a initrd
<MarcWeber> damjan: Mount proc before running upstart.
<sadmac> damjan: then it won't work right now (we don't like it either, it'll be fixed at some point. patches welcome)
<MarcWeber> damjan: Also make sure that your kernel supports it..
<MarcWeber> if it doesn't you can still patch upstart.
<damjan> MarcWeber: supports what?
<MarcWeber> oom
<damjan> it should, I see /proc/1/oom_adj
<damjan> why is that needed at all? how about completelly disableing that part of the code?
<sadmac> damjan: go for it
<damjan> what's the "But.." ? :)
<sadmac> you don't get OOM support, and there's no flag, so you're doing it on your own. In a text editor.
<geiseri_> what are the files called in the /etc/events.d directory?  are those events themselves?
<sadmac> geiseri_: those are jobs
<sadmac> geiseri_: its a poorly named folder
<geiseri_> okay, no problem
<geiseri_> so is there a list of events that i can start on and stop on somewhere?
<MarcWeber> geiseri_: initctl list will show them all
<sadmac> MarcWeber: those are jobs
<MarcWeber> oh. I've missed that. sry
<sadmac> geiseri_: there's an events manpage in fedora. think its on die.net too
<damjan> well ... ok, going to reboot to try this :)
<damjan> brb
<geiseri_> okay, ill check there
<geiseri_> im trying to start a job when hal is finished starting
<geiseri_> if that is even possible right now
<sadmac> start on started hal
 * geiseri_ checks what he had
<geiseri_> yeah i have that but it doesnt seem to be working
<geiseri_> im on ubuntu intrepid, is this not supported in that version?
<sadmac> are you starting on something else?
<MarcWeber> geiseri_: You can log events when jobs are started..
<geiseri_> im sorry im not parsing your question...  my line is "start of started hal" in my job in /etc/event.d/Xorg
<sadmac> geiseri_: on, not of
<geiseri_> MarcWeber: that is the --debug flag you can pass to the boot args?
<geiseri_> sadmac: im trying to launch Xorg right after hal is started successfuly 
<sadmac> geiseri_: then start on started hal
<MarcWeber> geiseri_: Try grep init /var/log/messages. Maybe it is all there..
<sadmac> geiseri_: not of started, on started
<geiseri_> sadmac: sorry i had a typo, that is what i have now... 
<sadmac> geiseri_: is the job that starts hal in fact named hal?
<geiseri_> that im not sure... how would i find that out for certain?
<sadmac> ls /etc/events.d
<geiseri_> ah, i dont have one in there, it seems ubuntu still uses the sysv init compat stuff
<geiseri_> so im assuming ill never get an event from there
<sadmac> probably not. Fedora has some kinda chintzy event emulation for that stuff, but I don't think ubuntu followed on
<geiseri_> ah okay
<geiseri_> so if i put an initctl event hal in the end of my rc.local, that might do it?
<sadmac> initctl emint
<sadmac> *emit
<sadmac> yes, that'd do it
<geiseri_> ah, right
<geiseri_> okay, let me give that a whirl
<geiseri_> sadmac okay that seems to have worked, thanks
<sadmac> cool
<MarcWeber> Can I syntax check job files somehow?
<geiseri_> sadmac: hrm... only one problem when i do the emit the rc.local blocks... should i be doing "initctl emit xorg &" so it starts in the background?
<sadmac> geiseri_: initctl emit --no-wait I think was the option
<geiseri_> ah
<geiseri_> okay
 * geiseri_ checks the man page
<geiseri_> that looks like it might do it
<MarcWeber> Can the default PATH be set to a sensible default?
<MarcWeber> Or do I have to use env PATH=... in all job files?
<sadmac_> define sensible?
<MarcWeber> containing corutils such as touch and upstart itself..
<sadmac_> don't think we have global environment. Might be a good RFE
<MarcWeber> I don't mind adding env PATH=.. everywhere either
<MarcWeber> It does'nt matter that much because nixos does already have some kind of abstraction. adding this myself is done very fast.
<MarcWeber> I think this differs from upstart-0.3 somehow
#upstart 2010-03-08
<kristofor> hi all, can somebody tell me how I would go about running a bash script as a specific user in upstart?
<sadmac2> kristofor: su
<Terces> I just created an upstart task in the /etc/event.d directory, but when I "sudo start taskname" it says "start: Unknown job:". A google search for "upstart start: Unknown job:" didn't turn up anything useful. Can anyone suggest how I would go about finding my problem (are there error logs, etc.)?
<ion> Itâs /etc/init, unless youâre running very old software.
<ion> Parse errors are logged to syslog.
<Terces> oh, thanks.
<Terces> trying to fix it now.
<Terces> that was it/
<Terces> I was using documentation I found online that must have been outdated.
<ion> man 5 init is a good starting point.
<Terces> thanks ion
#upstart 2010-03-09
<jonwood> Hello?
<Keybuk> Hello
<jonwood> Does anyone mind if I ask a few questions about Upstart's scope?
<Keybuk> sure
<Keybuk> ask away
<jonwood> I'm trying to work out where the init scripts in /etc/init.d fit into things.
<Keybuk> they're supported for compatibility with the LSB, and also to make migration easier for distributions
<Keybuk> the usual way it works is that you run the old "rc" script as an Upstart job
<Keybuk> just as the old sysvinit ran it from inittab
<Keybuk> where or how you run it, and at which point in the boot, etc. will depend on distro
<Keybuk> and the distro's own needs
<jonwood> Ok, so when creting init scripts for new things, the recomended way would be to create upstart scripts for them?
<Keybuk> e.g. a distro that hasn't migrated to Upstart fully might consider the /etc/init.d scripts still authorative and run Upstart jobs around/before/after them
<Keybuk> where a distro that's migrated the bulk of its boot to Upstart might consider them an afterthought
<Keybuk> a fully native embedded system might not support them at all
<jonwood> I'm talking specifically in the context of Ubuntu Karmic
<Keybuk> it depends
<Keybuk> Upstart is still very much in development, so the config file format is expected to change
<Keybuk> so it's ok to ship Upstart jobs, as long as you keep up with Upstart changes
<Keybuk> shipping an Upstart job that refers to "runlevels" is rarely correct of course
<jonwood> I'm only planning to distribute them internally anyway, so that's not a huge problem.
<JanC> in that case upstart scripts give you more power  âº
<jonwood> I'm also wondering how far it currently goes with process supervision. Should it be restarting services that get killed for example?
<JanC> you can specify whether or not it should do that
<Keybuk> jonwood: it has a basic support for process supervision, and can respawn processes if they die unexpectedly, along with telling it what exit codes and signals are expected
<jonwood> Where abouts can I find documentation on that?
<Keybuk> in the man pages, of course
<jonwood> Heh, I guess I asked for that :P
<JanC> init(5) mostly 
<jonwood> Thanks :)
<sadmac2> Keybuk: I've thought about making the task stanza an extension of the expect stanza
<sadmac2> Keybuk: "expect exit"
<Keybuk> it doesn't just change that though
<sadmac2> Keybuk: internally its a bit different. Trying to decide whether from a user perspective the metaphor makes sense
<sadmac2> Keybuk: was that a crash? did you catch everything?
<Keybuk> sadmac2: I can't tell whether I caught everything, can I? :p
<sadmac2> 12:06 < Keybuk> it doesn't just change that though
<sadmac2> 12:07 < sadmac2> Keybuk: internally its a bit different. Trying to decide whether from a user perspective the metaphor makes sense
<sadmac2> 12:10 -!- Keybuk [~scott@quest.netsplit.com] has quit [Quit: å¤ èå]
<Keybuk> wasn't a crash - updated IRC client to restore my notification icon patch
<sadmac2> oic
<Keybuk> I was thinking that task vs. service is fairly well expressed by whether the job uses "while" or "on"
<sadmac2> Keybuk: services with no dependencies would just use on
<Keybuk> no they won't
<sadmac2> Keybuk: it also might make sense for a task to have dependencies
<Keybuk> yes, but they'll just combine while and on ;)
<sadmac2> Keybuk: while postgres every 3 hours exec trivial-database-task
<Keybuk> that'd be a task
<Keybuk> "every" is kinda like "on"
<sadmac2> Keybuk: so you're saying a service will /never/ use on.
<Keybuk> I can't think of one
<wasabi> while system-running
<sadmac2> Keybuk: you may be right, but it takes a bit of thinking to ferret out. I'm not sure the principle of least surprise would encourage us figuring out task vs service automagically that way.
<wasabi> don't make the user need to know task/service as a distinction.
<wasabi> just instruct them to describe how they want the executable to be invoked.
<Keybuk> the primary distinction between a service and a task is how it affects the event it's run by
<wasabi> blocking it or not?
<Keybuk> blocking it from completing, right
<Keybuk> so a better way to look at it =>
<Keybuk>  - is the a reason that something run "on <event>" should not ordinarily block it from completing
<Keybuk>  - is there a reason that a service run "while" something should block that condition from ever being true
<Keybuk> (reading the latter should reveal it's a logical impossibility :p)
<sadmac2> yes, I prefere while/before to be a first-order implication style relationship
<sadmac2> prefere? In spanish apparently
<Keybuk> right
<sadmac2> Yo preferÃ© que durante/antes son implicaciÃ³nes del <<order> uno
<sadmac2> not so bad, and I never took discrete math in spanish, so
<sadmac2> except I mixed tenses.
<sadmac2> what were we talking about?
<Keybuk> task vs. service
<Keybuk> on vs. while
<sadmac2> surprised you answered that seriously... anyway I'm not seeing an approach here that has much real advantage over having a task stanza
<Keybuk> more DWIM
<sadmac2> Keybuk: I'm not sure people necessarily "mean" task when they imply "on". Just because I always use them together doesn't mean they're synonymous
<sadmac2> s/imply/say/
<Keybuk> so let's think of a few examples
<Keybuk>   on service pre-start
<Keybuk>   script
<Keybuk>     ...
<Keybuk>   end script
<Keybuk> would you ever not want that to block?
<sadmac2> Keybuk: true, but there's another question
<sadmac2> Keybuk: would I expect it to block anyway?
<sadmac2> Keybuk: its a strange argument I'm making here. Doing what the user expects is better even if its /not/ what they want.
<sadmac2> Keybuk: look at the example this way:
<sadmac2> on service event
<sadmac2> would I expect that to change the semantics of the job?
<Keybuk> since it always does in Upstart, yes :p
<sadmac2> poor choice of words
<Keybuk> or, another way
<Keybuk>   on shutdown
<Keybuk>   exec save-my-files
<Keybuk> would you expect it to wait until your files were saved before shutting down? :p
<sadmac2> that's a good point
<sadmac2> Keybuk: where does this leave from ... until ... ?
<Keybuk> dunno yet
<sadmac2> alright I'm sold
<sadmac2> Keybuk: I think we need from...until to turn events we get from outside into upstart states
<sadmac2> Keybuk: netdevice from udev-thingie until other-udev-thingie
<sadmac2> feeling articulate today
<sadmac2> also it would be nice to have a syntax like that somewhere where we could just define a whole bunch of states in a row
<Keybuk> yes, I think we need it
<Keybuk> I'm just not sure whether we consider it like-while or like-on
<Keybuk> hunch says like-while, but would need to think about it
<sadmac2> Keybuk: like on would mean from A until B would block A until B occurred?
<sadmac2> Keybuk: doesn't sound right
<wasabi> I don't think I'd expect shutdown to complete until the tasks associated with it completed
<wasabi> after all, if shutdown completes, the system is off.
<wasabi> heh
#upstart 2010-03-10
<schmelzs> hi
<schmelzs> is there a way to log the debug output of upstart to a file
<schmelzs> i tried to use a wrapper script to start the upstart init, but had problems cause upstart wasn't pid 1 anymore
<schmelzs> starting bootlogd didn't work either and the "normal" rsyslogd just get's the last messages
<sadmac2> schmelzs: the wrapper script should redirect its own stdout to a file, then exec init
<schmelzs> sadmac2: the wrapper script didn't work at all - it failed with some messages about wrong parameters ..
<schmelzs> i started it with  -v --debug $@
<sadmac2> hmm
<schmelzs> it looked like the init binary acts different if it hasn't pid 1
<sadmac2> schmelzs: yes. let it have pid one
<sadmac2> schmelzs: that's why I said /exec/ it
<schmelzs> ahh ok :)
<schmelzs> i'll try that - thanks
<sadmac2> exec 1>&-
<sadmac2> exec 2>&-
<sadmac2> exec 1>/tmp/file
<sadmac2> exec 2>/tmp/file
<Keybuk> use /dev/klog instead of /tmp/file ;-)
<Keybuk> then you can use netconsole
<sadmac2> exec /sbin/init -v --verbose
<Keybuk> err, /dev/kmsg
<schmelzs> netconsole looks nice :)
#upstart 2010-03-11
<tauren> i'm considering migrating an init.d script to upstart. I've looked through the files in /etc/init, but I don't really get what gets run when you stop a service.
<tauren> basically, my init.d script sets up a bunch of iptables rules, and when it is stopped, I want to remove them.
<tauren> i see some scripts don't have a script or exec, they only have pre-start and post-stop. Maybe that's how I need to do it.
<Keybuk> put them in a post-stop script
<Keybuk> yes
<Keybuk> then your job is "running" when the rules are in place
<tauren> Keybuk, ok, cool.
<Keybuk> even though there's no process associated
<tauren> that makes sense now.
<tauren> in my init.d script, I have another command that I can run:  service firewall report
<tauren> can I add new "commands" with upstart?
<tauren> Keybuk: basically, the report command just does:  iptables -nvx -t filter -L ACCOUNTING
<Keybuk> not yet
<Keybuk> it's planned
<tauren> Keybuk, ok, thanks
<tauren> Keybuk: any reason why I'm not getting any echo output?  I've got console output in my firewall.conf file and my pre-start script contains echo "Test", but doing start firewall doesn't respond with "Test"
<tauren> oh, I see. Including "console output" makes the output go to the console. duh. But when I remove that, I still don't see the echo output at the command line when I run "start firewall"
<Keybuk> removing that makes the output go to /dev/null
<tauren> Keybuk, is there a way to get echos to be output then? Besides to the console or /dev/null? 
<Keybuk> no
<tauren> i've got my upstart script working perfectly, and am currently doing:  echo "Informational message" >> /tmp/firewall.out
<tauren> but i would prefer the output to be on stdout.
<tauren> ok then. thanks anyway!
<Keybuk> right
<Keybuk> but which stdout? :p
<tauren> yeah, i see your point.  i mean if someone enters "start firewall" via an ssh session, they should see the output. but i wasn't thinking this would also be run at other times too.
<tauren> what's the best way to start a service running as a particular user?
<ion> su
<tauren> i mean, i will create a new file /etc/init/jetty.conf, but I want the script that starts jetty to run as a user on the system.
<tauren> Here is my upstart conf file: http://pastie.org/865735
<tauren> when I do a "start jetty", a java process gets started
<tauren> and it reports that it is started with a pid
<tauren> but "status jetty" says it isn't running
<tauren> and "stop jetty" doesn't work
<tauren> how can I make this script start jetty as a user, and then be able to stop it by running "/home/$username/jetty/stop.sh" as the user?
<Keybuk> "expect fork" or "expect daemon"
<tauren> Keybuk, thanks, i'll try that
#upstart 2010-03-12
<Caesar> Keybuk: dude, mountall...
<Keybuk> Caesar: what about it?
<Caesar> Total black box
<Keybuk> ?
<Caesar> So I see mountall: Filesystem could not be mounted: /net
<Caesar> So I figure that it tried to mount /net, an NFS mount, before the network was up
<Keybuk> it'll try again when another interface comes up
<Caesar> Sorry, I also see mount.nfs: DNS resolution failed for netkrb5.nfs: Name or service not known
<Caesar> That was the smoking gun
<Keybuk> right
<Caesar> But looking at mount-net.conf, it signals mountall the daemon
<Keybuk> yes?
<Caesar> But looking at mountall.conf, I get the impression the daemon exits at some point
<Keybuk> daemon exits once all mounts are mounted, yes
<Caesar> Hmm
<Caesar> So why did my NFS mount of /net fail?
<Keybuk> who knows
<Caesar> I'd have said it was because the network wasn't up...
<Keybuk> mount.nfs probably knows
<Keybuk> it may have even give you an error message
<Keybuk> oh, wait, it did
<Keybuk> *shock*
<Caesar> Yes :-)
<Caesar> Suggesting the network wasn't up :-p
<Keybuk> sure
<Keybuk> sounds reasonable
<Caesar> So I was wondering if mountall the daemon prematurely exited, and thus never got signalled by mountall-net
<Keybuk> probably not
<Keybuk> it won't exit until it's done
<Caesar> Next install I do, I'll go looking for logs
<Caesar> I have bigger fish to fry at the moment
<Keybuk> --debug
<Caesar> I presume Upstart is clever and looks for the existence of the thing it's supposed to exec before it execs it?
<Caesar> (topic change)
<Caesar> i.e. left around conffile upstart job definition, package has been removed
<Caesar> I also saw init: Failed to spawn rsyslog main process: unable to execute: No such file or directory
<Keybuk> no
<Keybuk> it just execs, and deals with the failure
<Caesar> Okay. Slightly ugly.
<Caesar> I believe Puppet can ensure => purged versus absent
<Caesar> We'll just explicitly purge rsyslog
<Keybuk> better behaviour is planned
#upstart 2010-03-13
<dyek> Hi! Is there any init script that reads /etc/init/tty?.conf? Or Upstart's init program reads the tty?.conf files directly?
<Keybuk> whuh?
<Keybuk> all /etc/init/*.conf files are configuration for the init daemon
<Keybuk> as you'd expect
<dyek> Keybuk: OK. Thanks!
#upstart 2011-03-08
<SpamapS> Hmm.. didn't somebody provide a workaround script for bug #406397 ?
<ion> http://heh.fi/tmp/workaround-upstart-snafu
<SpamapS> ion: ty
<apw> jhunt, yo ... i have a mad situation where gdm seems to start when its pre-dependancies have not been run (or at least logged as such) ... any suggestions on how to diagnose
<jhunt> apw: Adding, "set >> /tmp/gdm.log" in a script section might be useful. What scenario is it starting in where you would not expect it to?
<apw> jhunt, it is dependant on startup and (graphics device or stopped fallback-job)
<apw> jhunt, i have rm my drm modules and there are none of those events, and fallback-job also does not get logged at all
<jhunt> apw: If you use the "set" as above, you can see what the value of UPSTART_EVENTS was (ie what triggered the start on condition to become true).
<apw> so gdm should not have started ... ok will do
<ion> exec >/tmp/gdm.log 2>&1
<ion> set -x  # perhaps
<SpamapS> apw: sometimes the started event is fired before a service is actually ready unfortunately
<apw> SpamapS, hmm, but in this case the service never starts
<apw> its never even mentioned in --verbose output
<apw> jhunt, so what the heck does 'filesystem started stopped' in U_E tell me?
<apw> start on (filesystem
<apw>           and started dbus
<apw>           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
<apw>                or stopped fallback-framebuffer))
<jhunt> those were the events that triggered gdm to start: "filesystem + started (dbus) and stopped (fallback-framebuffer)"
<jhunt> looks like the fallback-framebuffer is your problem there.
<jhunt> did it ever start? You might need to use the technique I mentioned to you the other day.
<apw> jhunt, but fallback-frambuffer doesn't even appear in the --verbose output
<jhunt> right, it never started: hence it was stopped.
<apw> jhunt, that should not be correct... these are events not states
<apw> it would have to actually start and then stop to get a stopped event surely
<apw> jhunt, is there soem synthetic event at upstart init
<jhunt> apw: "startup" is what kicks the whole thing off
<apw> jhunt, no i think i am miss understanding
<apw> jhunt, how in an event based system is something which never run emitting a stopped event
<jhunt> I'm just looking to see how it is doing the matching...
<jhunt> apw: is there a "stop on" condition for this job?
<apw> jhunt, for gdm or fallback-*
<apw> jhunt, fallback-* not as it is a 'task'
<jhunt> apw: gdm. is it just runlevel?
<apw> stop on runlevel [016]
<apw> yep
<jhunt> apw: can you send me your *.conf files, along with your syslog + gdm.log?
<apw> jhunt, can do
<apw> jhunt, location in privmsg
<apw> jhunt, its pretty big :)
<apw> jhunt, this 'stopped udevtrigger' form is the one i followed here ... and it makes little sense if that can occur before it starts too
<apw> jhunt, that _may_ have been a 'few' off, very confusing
#upstart 2011-03-09
<codebeaker> hi all, I'm getting into upstart for the first time, and I wonder if I've missed somethingâ¦ I'm trying to use upstart to keep monit running
<codebeaker> hi all, I'm getting into upstart for the first time, and I wonder if I've missed somethingâ¦ I'm trying to use upstart to keep monit running (re-post, since I was D/C'ed)
<SpamapS> codebeaker: what do you think you're missing?
<codebeaker> if I kill monit, upstart doesn't bring it back
<codebeaker> which I gathered was the point of upstart
<codebeaker> ( in addition to actually starting it in the firstplace)
<SpamapS> did you put the word 'respawn' in your job file?
<SpamapS> no respawning isn't the only point of upstart.. its mostly just to be feature compatible w/ sysvinit
<SpamapS> Its just a little smarter about it than sysvinit. :)
<codebeaker> ok, I'll check - also what is the /correct/ place for upstart configs?
<codebeaker> on my ubuntu 10.4 system they appear to live in /etc/init/
<codebeaker> but I've seen lots of talk online about using /etc/event.d/
<SpamapS> they must be in /etc/init since Ubuntu 9.10
<codebeaker> ok, good to know - thanks :)
<codebeaker> *bow*
<SpamapS> You may want to submit your monit job as a feature-request bug against the package if it works out for you.
<codebeaker> not sure, it's 3 lines of code :)
<codebeaker> (well, four now :))
<codebeaker> SpamapS: what's your personal opinion on Monit's place in a modern hosting env
<codebeaker> I'm basically using monit to keep my services up, because I know it well enough
<SpamapS> Its quite suited for that, especially since it is capable of deeper monitoring than upstart's "is the process alive"
<codebeaker> ok, perfectâ¦ so upstart to keep the system running, and monit to keep things working at the application layer
<SpamapS> Yeah
<wraiden> does anyone know if upstart 1.0 ist compatible wrt utmp handling when i use agetty?
<wraiden> the teminal sessions aren't decremented in issue output anymore since i upgraded to 1.0
<wraiden> i'll try to switch to mingetty today to check it isn't an incompatibility with util-linux's agetty as mingetty was mentioned in some changelog...
<SpamapS> doesn't login handle utmp maintenance?
<wraiden> looks like it doesn't if i read the changes that went in from plautrbach correctly...
<wraiden> mybe i have a wrong tty.conf in /etc/init
<SpamapS> ahh I'm looking now.. ok.. utmp is indeed touched by init now
<SpamapS> I say now like I know it didn't before.. maybe it did before.. :p
<wraiden> the problem was that issue incremented the open tty session counters but doesnt decremented it after the loginsession was closed and upstart respawned the getty ...
<wraiden> this bug was in upstart from the start i think
<wraiden> don't know how sysv handled it
<plautrba> wraiden: can you paste somewhere 'utmpdump /var/run/utmp' ?
<SpamapS> right looks like now if a job process terminates upstart looks in utmp and fixes it
<plautrba> wraiden: afaik it should work regardless of used *getty
<wraiden> hello :) i'll open a session to the box an paste the things...
<wraiden> http://pastebin.com/LfDLA8hR
<wraiden> cant look at the issue output right now as i'm not in front of the box
<plautrba> this looks ok, what is concretely your problem?
<wraiden> if i login an a local tty the issue displays the logged in users ok but if i logout the logged in users stay the same and doesn't get decremented
<wraiden> this behavor war fixed in the first round of patches that you attached to the bugreport ...
<wraiden> i tested them and used them as patches against 0.6 but with the upgrade to version 1.0 i went back to the buggy behavior
<wraiden> i'll post another utmp dunp when i have access to the box again around 18:30 CET
<plautrba> in 1.0 is almost same patch
<plautrba> and utmp table says that there is 2 correctly restarted local tty session, 1 closed remote, and 1 active remote session
<wraiden> thats right
<plautrba> command 'w' should show one logged user 
<wraiden> i rebooted the box
<wraiden> kernel upgrade...
<wraiden> the wrong behavior was befor the reboot
<wraiden> i'll repro the wron output and post an updated dump
<wraiden> should i mail it or crate a bug report?
<plautrba> mail to mailling list or bug report are fine, or you can first try to ping me here
<wraiden> k, will look here first
<wraiden> anyway, thanks for your work about utmp handling, this one bugged me a long time :)
<plautrba> i've just setup my fedora rawhide box to use aggety and it works ok
<wraiden> exec /sbin/agetty -I '\033(K' tty1 38400
<wraiden> is what i use
<wraiden> maybe it's related to that
<plautrba> I use only /sbin/agetty /dev/tty6 38400  but -I should not affects that
<wraiden> i'll repro the problem tonight and post the details along the dump...
<atpa8a> hello!
<atpa8a> i'm binding slapd to an ip alias and it seems that aliases come up late on boot which causes slapd fail to start... can i start networking "syncronously" or something?
<Keybuk> no, but you can have slapd start after networking
<atpa8a> i think that's how it's configured...
<atpa8a> or should i create /etc/init/slapd.conf for that?
<Keybuk> you would need an /etc/init/slapd.conf or something in Upstart that starts slapd
<atpa8a> i don't have that right now
<atpa8a> just learning upstart
<atpa8a> thought it was related to insserv
<atpa8a> hmm
<atpa8a> so slapd is not an upstart job right now
<atpa8a> which means it's handled from /etc/init/rc.conf, right?
<mbiebl> no, /etc/init.d/slapd
<atpa8a> true :) i misspoke
<mbiebl> atpa8a: only indirectly via /etc/init/rc.conf
<atpa8a> right
<atpa8a> that's what i meant
<atpa8a> can i just add something like start on (net-device-up...) to /etc/init/rc.conf to make sure the networking is up before anything else?
<atpa8a> or change /etc/init/rc-sysinit.conf from 'start on filesystem and net-device-up IFACE=lo' to 'start on filesystem and net-device-up'
<atpa8a> basically i want *all* of the network up before slapd starts
<atpa8a> that didn't help
<atpa8a> any hints?
#upstart 2011-03-10
<atpa8a> so generally... how can i run sysv scripts only after *all* of the network is up?..
<Keybuk> change the "start on" line of /etc/init/rc-sysinit.conf
<Keybuk> if you want to just wedge something, you can do
<Keybuk> echo start on WHATEVERINDICATESNETWORKINGISUP and starting rc-sysinit
<Keybuk> that will wedge rc-sysinit from starting until "WHATEVERINDICATESNETWORKINGISUP" happens
<Keybuk> err
<Keybuk> echo start on WHATEVERINDICATESNETWORKINGISUP and starting rc-sysinit >> /etc/init/rc-sysinit-networking-wedge.conf
<Keybuk> obviously
<atpa8a> hello again
<atpa8a> need an insight... how can i make sysv scripts run only after all the networking is up?
<jab_doa> hi
<jab_doa> can i somehow start a job on two different conditions? i want to use the one or the other. eg on rc2 stopped or on a signal
<tohava> Question, when I tell upstart to restart a process, what exactly does it do?
<tohava> anyone?
<SpamapS> tohava: restart stops then starts the job, but does not reload its configuration (so any changes to the job file will not be recognized by a restart)
#upstart 2011-03-11
<twb> In lucid, I have an upstart task that runs "iptables-restore /etc/iptab".
<twb> If this fails, I want the system to freak out and disable all services -- say, switching to single-user mode.
<twb> How would I configure this?
<twb> Can I have two "pre-start exec" lines (instead of a pre-start script)?
<mbiebl> twb: no
<twb> Okey dokey
<atpa8a> hello
<atpa8a> any clues how i can enforce that the all of the network interfaces are up before sysvinit scripts run?..
<Keybuk> atpa8a: I've already answered your question three times
 * ion notices Keybuk isnât a Conan fan.
<Keybuk> Conan?
<atpa8a> Keybuk: sorry, must've missed
<Keybuk> atpa8a: to change the state in which sysvinit scripts are run, you edit the /etc/init/rc-sysinit.conf file
<ion> keybuk: http://www.youtube.com/watch?v=iNu3MW-lb6Y
<Keybuk> and change the "start on" kine
<Keybuk> as you can see, right now it says to start when the *loopback* network interface is up
<Keybuk> but no other
<Keybuk> if you alter that start on line, you can delay sysvinit scripts as long as you like
<Keybuk> e.g. until all network interfaces are up
<Keybuk> or until the cows come home
<atpa8a> Keybuk: i tried removing that IFACE= at all and tried making it IFACE=eth0 but nothing helped
<atpa8a> still slapd fails to start because the network is not up yet
<atpa8a> start on filesystem and net-device-up IFACE=eth0
<atpa8a> that's what i have there now
<atpa8a>  slapd[2826]: daemon: bind(9) failed errno=99 (Cannot assign
<atpa8a>  requested address)
<Keybuk> atpa8a: is eth0 the right interface?
<Keybuk> then it's likely that slapd is in fact waiting for something else
<atpa8a> yes
<atpa8a> well
<atpa8a> slapd needs eth0:0 really
<atpa8a> should i try that?
<Keybuk> aha! bridges
<atpa8a> aliases
<Keybuk> right
<Keybuk> so you need to add something like "and started networking"
<Keybuk> e.g.
<atpa8a> is there like... IFACE=all?
<Keybuk> start on filesystem and net-device-up IFACE=lo and started networking
<Keybuk> meaning filesystem ready, loopback device up, and all virtual devices
<Keybuk> no, because then you'd have to define "all"
<atpa8a> gotcha
<atpa8a> started networking should work
<Keybuk> e.g. on a laptop with a USB ethernet device, does "all" mean including that or not?
<Keybuk> and if it means including that, what if it's not plugged in?
<atpa8a> i see
<Keybuk> you may want
<Keybuk> start on filesystem \
<Keybuk>   and net-device-up IFACE=lo \
<Keybuk>   and net-device-up IFACE=eth0 \
<Keybuk>   and started networking
<Keybuk> because you'll want eth0 as well as the alises
<atpa8a> can't i just use 'and started networkin' without net-device-up?..
<SpamapS> started networking just means ifup -a returned
<atpa8a> ok... so that would supercede net-device-up, right?
<Keybuk> no
<Keybuk> they do different things
<SpamapS> nope.. ifup just starts the things that configure the ifaces
<Keybuk> physical network devices, for which you have hardware, are up when you get net-device-up
<Keybuk> non-physical network devices (virtual, bridges, aliases) are up on the ifup -a
<atpa8a> got it
<atpa8a> trying
<SpamapS> Tho it does mean all statically configured devices are up.. right?
<atpa8a> thanks a bunch
<atpa8a> hmm
<Keybuk> SpamapS: no, because at the point networking runs, the actual devices may not have modules loaded yet ;)
<Keybuk> SpamapS: so you can't guarantee that
<atpa8a> should i... just in case add eth1 as well?
<Keybuk> atpa8a: at some point it's worth filing a bug that slapd should use IP_FREEBIND
<SpamapS> Keybuk: so ifup -a may fork modprobes and such, even for   iface eth0 inet static ?
<Keybuk> but that's for another day ;)
<Keybuk> SpamapS: ifup doesn't fork modprobes unless you've stuck modprobe in a pre-up ;)
<atpa8a> Keybuk: thought about just filing a bug with ubuntu to fix rc-sysvinit.conf
<Keybuk> atpa8a: fix?
<Keybuk> atpa8a: this is not considered a bug in Ubuntu
<Keybuk> Ubuntu has *never* delayed starting services until after network interfaces are configured
<Keybuk> this is because the default out-of-the-box behaviour in Ubuntu isn't to configure network interfaces until *user login*
<Keybuk> services are supposed to work without a configured network interface
<SpamapS> Keybuk: so started networking should mean all statically configured, non transient hardware, has been configured. yes?
<Keybuk> thus the IP_FREEBIND
<Keybuk> SpamapS: yes
<Keybuk> SpamapS: assuming you have such a thing
<atpa8a> hmm
<SpamapS> Keybuk: thinking about servers mostly
<SpamapS> Is IP_FREEBIND POSIX or a linux innovation?
<atpa8a> so if my interfaces are all static, 'and started networking' should be enough?
<Keybuk> Linux I believe
<Keybuk> atpa8a: yes
<SpamapS> I could see it being a problem for some upstreams if its linux only.
<Keybuk> atpa8a: though see notes about modprobe above
<Keybuk> SpamapS: #ifdef is their friend
<SpamapS> Right, most will be fine w/ that
<atpa8a> Keybuk: sure, thanks a bunch
<SpamapS> some will be adamantly opposed.
<atpa8a> i've a feeling slapd might be one of those
<Keybuk> SpamapS: if you can find any upstream not using at least one Linux-specific API, I'd be impressed ;-)
<Keybuk> and that's why distros carry patches
<Keybuk> after all, as soon as you see setsockopt() or ioctl() or anything like that - you're in linux-specific-land
<SpamapS> Keybuk: I've recently proposed hanging rc-sysinit to start on filesystem and started networking rather than net-device-up IFACE=lo so that users can expect that any static interfaces will always be configured before runlevel 2.... given what we've talked about here.. I think that its still a good idea.
<SpamapS> s/hanging/changing/
<Keybuk> SpamapS: the trouble there is you run the risk of locking the boot
<Keybuk> because people use sysvinit to bring up the dependencies of static interfaces
<Keybuk> in theory though I have no problem with delaying rc-sysinit as long as you like
<Keybuk> because things should not be using rc-sysinit
<Keybuk> slapd should have its own .conf etc.
<SpamapS> Hanging it or failing a bunch of stuff.. I'll choose failing a bunch of stuff. But we need a generic solution.
<SpamapS> Keybuk: its own.conf that will 'start on runlevel [2345]' ? ;)
<Keybuk> we don't even *have* rc-sysinit on Chromium OS after all ;-)
<Keybuk> SpamapS: I thought you were introducing jobs to replace those? :)
<SpamapS> I am.. definitely. Haven't gotten much traction on those.
<Keybuk> I always take no traction as silent assent ;
<Keybuk> ;)
<SpamapS> Right.. my DMB app has been delayed twice unfortunately.
<atpa8a> upstart scrips for slapd and a few other services are nowhere to be found for ubuntu
<SpamapS> otherwise I might have uploaded network-services.conf and wait-for-state.conf already. :)
<atpa8a> i did consider making my own but... i'm not an experienced SA
<Keybuk> atpa8a: bug! :p
<atpa8a> don't know the intricacies
<atpa8a> Keybuk: there's a bug already but it's on hold
 * atpa8a is java dev
<atpa8a> SA is a hobby :P
<atpa8a> bb
<atpa8a> testing the script
<Keybuk> ion: you realise that killed my X server and I hate you, right? :-)
<ion> Eh :-D
<Keybuk> flash seems to hate dual-head non-twinview nvidia
<wraiden> hello, is anyone actively working on /proc/PID/oom_score_adj support? /proc/PID/oom_adj is deprecated and upstarts oom stanza uses this interface...
<Keybuk> wraiden: nobody is actively working on it
<wraiden> i ask because i don't want to do duplicated work on this if anyone has picked the issue up allreda
<wraiden> k
<Keybuk> so please feel free to pick it up
<wraiden> k
<Keybuk> I believe both APIs are still supported, right?
<wraiden> will take a similar aproach as udev
<wraiden> yes
<Keybuk> try and write to oom_score_adj
<wraiden> but it polutes dmesg with a warning
<Keybuk> if that fails with EEXIST, fall back to oom_adj ?
<wraiden> yes
<wraiden> and no
<wraiden> udev checks for filepointer lower than 0
<wraiden> so other errorcodes are picked up to
<wraiden> i think
<Keybuk> right, but you also want to check errno
<Keybuk> if you got EPERM from oom_score_adj you shouldn't fall back to oom_adj
<wraiden> i cook something up over the weekend
<Keybuk> because you'll just get the same error ;-)
<Keybuk> EEXIST should be the only reason to fallback
<Keybuk> but please do cook a patch up, and send it to the ML
<Keybuk> gratefully accepted
<wraiden> aye sir ;)
<wraiden> the only thing is that the score interface has grater values
<wraiden> so the off case must be -1000
<wraiden> the testsuite tests the values... could be problematic... as it will produce falsepositives on the offbound value checks
<Keybuk> that is why we have a test suite ;-)
<Keybuk> decide on appropriate behaviour, write tests for it, etc.
<wraiden> mhm
<atpa8a> hello again
<atpa8a> those changes seem to hange the boot...
<atpa8a> hang that is
<Keybuk> atpa8a: that implies to me that your network interfaces are (at least, in part) brought up by sysvinit scripts
<Keybuk> so your boot is:
<Keybuk>  - waiting for networking to start sysvinit
<Keybuk>  - unable to start networking because it's waiting for sysvinit
<atpa8a> ok...
<Keybuk> ie. deadlock
<Keybuk> so here's your next trick:
<Keybuk> remove the bits you added to rc-sysinit
<Keybuk> now create a new job
<Keybuk> /etc/init/slapd-interlock.conf
<Keybuk>   start on slapd-interlock and net-device-up IFACE=eth1 and started networking
<Keybuk> (that's it)
<Keybuk> and in /etc/init.d/slapd, in the start case, add
<Keybuk>   initctl emit slapd-interlock
<atpa8a> hmm
<Keybuk> you may need some protection here to make sure it only runs on actual boot, e.g. by checking $RUNLEVEL or some shit - I haven't fiddled with sysvinit scripts in a while to remember what that is
<Keybuk> what this will do is:
<Keybuk>   sysvinit scripts will start as normal
<Keybuk>   slapd will start
<Keybuk>   it will run "initctl emit slapd-interlock" and wait for that event to complete
<Keybuk> the .conf file in Upstart will pick up that event, and block it
<Keybuk> while it also waits for net-device-up IFACE=eth0 and started networking
<atpa8a> (i think) i'm following...
<Keybuk> and then when all three happen, that ".conf" is running, so the event is unblocked, so initctl emit finished, so slapd carries on
<atpa8a> let me try\
<atpa8a> thanks a bunch
<atpa8a> hmm
<atpa8a> seems like i cannot boot into single user mode either...
<wraiden> keybuk: is it ok if i change the tests for offbound values in the testsuite to values for the score interface? the will be offbound in booth cases then and we can avoid to check two interfaces with distinct test code...
<atpa8a> livecd ftw!
<Keybuk> atpa8a: single user mode is a sysvinit thing ;-)
<Keybuk> wraiden: you can change the tests, but be careful to not change the thing they're testing
<Keybuk> current job files should work unchanged
<atpa8a> hmm
<atpa8a> Keybuk: would you say... it'd be better to call it networking-interlock.conf?
<atpa8a> kinda a common thing for all services that face the same situation
<atpa8a> and emit networking-interlock as well?
<Keybuk> yes, but the first job would release the interlock
<Keybuk> the second would hang
<Keybuk> which is why it's specific to slapd
<atpa8a> i see
<atpa8a> can it be made generic?..
<Keybuk> not without converting slapd to upstart
<atpa8a> gotcha
<atpa8a> hmm
<atpa8a> just to confirm... i don't need 'start on filesystem' in slapd-interlock.conf, right?
<Keybuk> right
<atpa8a> thanks
<atpa8a> what would happen if i just do /etc/init.d/slapd restart when there's the emit in it?
<atpa8a> nothing happened...
<atpa8a> ok...
<atpa8a> trying booting now
<atpa8a> hmm
<atpa8a> something didn't work...
<atpa8a> heh
<atpa8a> typos :P
<atpa8a> ok
<atpa8a> now that i fixed it... it's not working when starting manually
<atpa8a> gotta do the emit conditionally...
<atpa8a> [ $RUNLEVEL ] && initctl emit slapd-interlock
<atpa8a> that should do it\
<atpa8a> testing
<wraiden> mhm, the changed valid range of values for the oom handling isn't easy to handle...
<wraiden> if i change it do accept 1000 to -1000 in the parser and change it by divide with 59 in the fallback (ugly hack, i know) we could get away wir
<wraiden> *with a string change for any supported locale...
<wraiden> another approach would be to check for the existence of /proc/self/oom_score_adj in init startup code, set a flag according to existence and use that to change behavior accordingly wich would eliminate ugly hacks to adapt the value in fallback case
<wraiden> but that would complicate the testcase...
<wraiden> btw: isn't EEXIST the error for "i want to crate a file but it exists" and not "file i want to open don't exist" ?
<wraiden> posix manpage for open (which fopen refers to) defines it as the fist rather than the second...
<wraiden> i'll take the flag oom_score_adj and check for the flag road...
<wraiden> +existence
<atpa8a> hmm
<atpa8a> something isn't working...
<atpa8a> http://pastie.org/1661174
<atpa8a> but it says initctl status slapd-interlock                            ~
<atpa8a> slapd-interlock start/running
<atpa8a> hmm
<atpa8a> fixed it by using 'net-device-up IFACE=eth0:3 \'
<atpa8a> working now
<atpa8a> thank you gents
<atpa8a> Keybuk: thank you much!
<Keybuk> oh cool
<wraiden> isn't networking enough to check for?
<Keybuk> I didn't even know you could do that :p
<atpa8a> wraiden: apparently not
<wraiden> y?
<atpa8a> http://pastie.org/1661174
<atpa8a> that was before i used IFACE=eth0:3 and it didn't work
<wraiden> y do you add the interface up events?
<atpa8a> hmm :P Keybuk recommended
<wraiden> arnt they prerequisites for networking?
<atpa8a> no
<wraiden> ah
<atpa8a> if you have a wiki i can drop this solution into, i'll document it
<atpa8a> putting it in my private wiki now
<atpa8a> thank you folkes
<atpa8a> very helpful
<wraiden> Keybuk: first compiletested only version without messing with the testsuite is here: http://pastie.org/1661386
<Keybuk> my concern about that approach is that it changes the behaviour of Upstart if you reboot into an older kernel
<Keybuk> suddenly jobs go from running to "parse error"
<wraiden> yes
<wraiden> problem here is that the interfaces arnt compatible with respect to value range ...
<Keybuk> one approach to that would be
<wraiden> a possible way out would be to accept the new range by default and
<Keybuk> oom NN = old range
<Keybuk> oom score NN = new range
<wraiden> divide the value
<Keybuk> and accept both
<Keybuk> accepting the new range only would change the behaviour of existing jobs
<Keybuk> (though I bet there are none out there using the score rather than just "never")
<wraiden> that was my thinking eighter...
<wraiden> a percent value would be nice
<wraiden> could be used as operator to calculate the right value for each interface
<wraiden> -operator + base
<Keybuk> that's no real difference than just sticking to the old vange
<Keybuk> range
<Keybuk> more fun, "oom less than <other job>" and let upstart pick the values? :P
<wraiden> that would by far overwehlm my rusty c skills *hehe*
<bigdata> how do I set an environment variable in a job file?
<wraiden> by reading: man 5 init
<wraiden> search foe env
<wraiden> *for
<wraiden> i'll go for the "oom score =" one i think ...
<Keybuk> well, no = in upstartyland but I think that makes the most sense
<wraiden> jepp
<wraiden> we need to support both interfaces, as noone upstream boundling conf files for upstart can predict which interface a user might have avaiable...
<wraiden> that leads to the question: is any upstream package shipping upstart definitions?
<wraiden> anyway a nice to have
<Keybuk> wraiden: there are definitely both upstreams and distributions shipping upstart config files
<Keybuk> so they must not be broken
<wraiden> what to do in a case where the new interface is usable  but only the old one has defined value?
<Keybuk> multiply it by sufficient numbers to turn it into the new value
<wraiden> + and the old one is not available (after its removal)
<Keybuk> the behaviours are the same, just the ranges have changed
<wraiden> k
<Keybuk> likewise if you only have new value in the .conf and only the old interface is available, you divide
<wraiden> will hack that together...
<Keybuk> (I'd multiply when parsing the old value so that the oom score in the job is always -1000..1000)
<Keybuk> then divide again when writing to the old interface
<wraiden> mhm
<Keybuk> I wonder just how many bugs on LP, at this point, are about pre-stop being fucking busted?
<wraiden> whats busted with it?
<wraiden> the multiplying and dividing isn't easily possible...
<Keybuk> why not easily possible?
<Keybuk> there's an operator for them in C and everything <g>
<wraiden> the values on the old interface are asyncronous reguarding positive and negative values
<Keybuk> normalise the base, adjust the scale
<wraiden> you cant get -16
<Keybuk> maths 101
<Keybuk> -16 is "the minimum" and -17 is "never" with +15 being "always"
<Keybuk> so I guess you make +15 be 1000, -17 be -1000
<wraiden> i would have used a simple * 62.5 
<Keybuk> optionally -16 is either -999 or -1000-1000/17
<Keybuk> look at what the kerneld oes
<Keybuk> ie. the code that deals with writing to the deprecated interface
<Keybuk> I'm sure it already has the exact algorithm to scale to the new one
<wraiden> if (task->signal->oom_adj == OOM_ADJUST_MAX)
<wraiden>                 task->signal->oom_score_adj = OOM_SCORE_ADJ_MAX;
<wraiden>         else
<wraiden>                 task->signal->oom_score_adj = (oom_adjust * OOM_SCORE_ADJ_MAX) /
<wraiden>                                                                 -OOM_DISABLE;
 * wraiden feeds his cats...
<bigdata> still trying to get the env setup up, I did read 'man 5 init', but the script being called does not see the PERL5LIB, any ideas http://pastebin.com/VDRdWM3V
<Keybuk> it should
<Keybuk> (though the "export PERL5LIB" there doesn't do what you think)
<Keybuk> keybuk /root#    
<Keybuk> keybuk /root# cat /etc/init/test.conf
<Keybuk> env DEMO=this:is:a:test
<Keybuk> exec echo $DEMO > /tmp/demo
<Keybuk> keybuk /root# start test
<Keybuk> test start/running, process 13507
<Keybuk> keybuk /root# cat /tmp/demo
<Keybuk> this:is:a:test
<wraiden> how about adding a oom_score_adj int to job_class so that we only need to calculate in the conf parsing case and just use what we have calculated?
<Keybuk> that's what I meant
<bigdata> your right, it did work
#upstart 2011-03-12
<bigdata> reading the wrong log file, now beating head on monitor with 'man 5 init' open
<wraiden1> http://pastie.org/1661386
<wraiden1> again compiletested only
<wraiden1> hope i got the config parsing right as i didn't looked at the nih docu
<wraiden1> i adapt the testsuite to check for the score syntax also
<wraiden> i'll go to bed now, i'll send the patch tomorrow when i have added some testcases and have tested the changes...
<wraiden> have fun, bye
<aaa> "sudo start doesrailswork" just says "stop/waiting" http://pastebin.com/raw.php?i=yhyQqGjj
<bigdata> so how does one run a job as non root user? is there a job conf property for that?
<bigdata> exec su - $RUN_AS_USER -c ~/bin/blah.sh #could be one way, but are there more "native" solution(s)?
<bigdata> well, off to bed, I'll check back in the AM ... faith, hope and charity
#upstart 2011-03-13
<eridu> is there any canonical reference for upstart?
<eridu> specifically, writing upstart jobs?
#upstart 2012-03-05
<marrusl> hey guys.  are user jobs still disabled by default in precise?
#upstart 2012-03-06
<FourAM> Hello all, I'm on a system with 1.3, and I was wondering if a script I trigger with cron can somehow see env vars of a running job; right now I'm `touch`ing files to use as flags (similar to an /etc/nologin) and I think it feels messy.
<FourAM> I know I can pass values with events/when starting and I can start on starting ENV_VAR='something' but when I trigger a job from cron i need to read the state of another job (to decide if i want the cron's job to continue)
<bradleyayers> FourAM: just use "status foo"
<Kiall> Heya, is there somewhere that upstart keeps some kind of state? Trying to write a job and it keeps stalling while starting .. So.. I deleted the job config, re-ran stop.. and is seems to still know about the job?
<SpamapS> Kiall: yes running jobs are kept in memory
<Kiall> SpamapS: aha, so what would I need to restart?
<Kiall> I was looking for how upstart itself was started, but havent found it yet
<SpamapS> Kiall: once you stop a job that has been removed, it should cease to exist
<SpamapS> Kiall: upstart is run as the init daemon of the system
<SpamapS> Kiall: so its started before *everything else*
<Kiall> "stop: Job has already been stopped: .."  yet, the /etc/init/.conf file as been removed. Is that normal?
<Kiall> I'm not sure if that means it still knows something about the job?
<SpamapS> Kiall: status 'job' will tell you what it knows about the job
<Kiall> SpamapS: yea, "graylog2-server stop/killed, process 15009" and "/etc/init/graylog2-server.conf: No such file or directory"
<Kiall> (the and part was me doing an ls..)
<SpamapS> Kiall: ok, so its waiting for the process, 15009, to die
<Kiall> Yea - I had thought that too, but 15009 doesnt exist
<SpamapS> Kiall: ahh, you may have used the wrong expect syntax, thats a known evil bug
<Kiall> 150* doesnt even exist
<Kiall> dooh 
<Kiall> Okay, any way to sort it without a reboot? :)
<SpamapS> there's a lame workaround
<SpamapS> Kiall: you have to get that pid to re-appear
<SpamapS> Kiall: so you can do it with a program that just exhausts the pid space
<SpamapS> Kiall: not exhausts, but, rolls it over
<Kiall> Lol - Any suggestions for a script/tool/etc to do what? or will a while true; do echo "."; done handle that?
<SpamapS> Kiall: bug 406397 has a link to a ruby script that does it
 * SpamapS is looking for a python version he wrote
<SpamapS> Kiall: echo is a bash builtin, so no ;)
<Kiall> but the "true" is /bin/true ;)
<Kiall> unless bash has that too -_-
<SpamapS> Kiall: yeah that might work
<Kiall> Found that ruby script anyway, it seems to stop at the right pid etc which is always handy :)
<SpamapS> Kiall: even better, just keep spawning status on your job and grepping it
<SpamapS> Kiall: while status foo | grep pid ; do : ; done
<Kiall> woot - "Unknown Job:" :)
<Kiall> and its all fixed+worked.. Thanks :)
<Kiall> This would have driven me nuts for hours!
<SpamapS> Kiall: yeah its a pretty confusing bug. :(
<Kiall> Thats for sure ;)
<Kiall> I was wondering why *nothing* i did in the job config would make it work.. Eventually (20-30 mins later) figured some sort of state was being kept ;_
#upstart 2012-03-07
<lcapriotti> hi, I'd like my upstart job to finish before another one runs, is "start on starting xyz" and "task"  enough?
#upstart 2012-03-08
<glenn___> evening
<glenn___> is it expected that "status <servicename>" returns 0 when its running or not running?
<SpamapS> glenn___: yes
<glenn___> does this mean a check if the service is running should see wether its 'stopped' or start/running?
<SpamapS> glenn___: parse the output if you need to know the status
<glenn___> ^^ ? :)
<glenn___> the command service is upstart specific too correct?
<glenn___> oh, its a wrapper i think
<glenn___> jodh :)
<glenn___> spamaps: i found an issue regarding upstart within puppet, so i figured id give them a heads up: http://projects.puppetlabs.com/issues/12773
<glenn___> hope thats ok
<glenn___> well I'm off, ciao
<JanC> glenn___: service is specified by LSB, I think?
<JanC> oh
<JanC> hm, apparently not
#upstart 2012-03-09
<axisys> why do I get stop/waiting for a process I just started using start 
<axisys> here it shows
<ion> See syslog.
<axisys>  http://dpaste.com/hold/713891/
<axisys> ion: that was to me?
<ion> yeah
<axisys> ion: /var/log/syslog shows nothing
<axisys> related to autossh
<ion> Strange
<axisys> let me stop and start again on one window while monitoring syslog on another window
<axisys> ion: i was wrong
<axisys> ion: i get all these when I start autossh
<axisys> ion: http://dpaste.com/713902/
<axisys> i guess i should not use autossh.. but just ssh
<axisys> autossh has i think a feature to respawn when ssh dies
<ion> Perhaps the problem is with the process 19509 using the port already.
<axisys> ion: it is not used already.. i checked.. before starting.. i think it is how it starts.. 
<axisys> /usr/bin/ssh -L 2000:127.0.0.1:2000 -R 2000:127.0.0.1:2001 -N -L 9025:smtp.example.com:25 192.168.1.210
<axisys> i need to find a better way to start..
<axisys> autossh converts to that command
<ion> Thereâs no longer a pid 19509 on the system?
<axisys> ion: no
<ion> If you run the âsu user -c â¦â command from the shell, does it start correctly and stay in the foreground?
<axisys> kind of..
<axisys> it does start.. but it also gives these messages
<axisys> keyctl_search: Required key not available
<axisys> Perhaps try the interactive 'ecryptfs-mount-private'
<axisys> keyctl_search: Required key not available
<axisys> Perhaps try the interactive 'ecryptfs-mount-private'
<axisys> i dont really need to start as root.. since I am picking a higher port
<axisys> can upstart process start as user? i guess not.. 
<axisys> if I start like this "autossh -f -M .. " as the user.. no issue
<axisys> as a matter of fact I dont really need to start it as user..
<ion> I looked up the man page of autossh, -f apparently should make it daemonize. Are you *sure* it stays in the foreground?
<axisys> so "su user -c .." is not needed to activate the port
<axisys> ion: it goes in the background.. 
<ion> Ok, that needs to be fixed.
<axisys> keyctl_search: Required key not available <-- this ?
<ion> No, the -f
<axisys> ok
<axisys> anything you want me to try?
<ion> dropping it
<ion> Iâve had better success with âsudoâ than âsuâ, too: exec sudo -H -u user -- autossh â¦
<axisys> for that I will need NOPASSWD 
<ion> sudo doesnât ask for a password from root.
<axisys> ion: how do you those cool double quotes ?
<axisys> ion: doh! right
<ion> US International (AltGr dead keys) layout; altgr-shift-[ and ]
<axisys> i know whats alt.. i guess i dont have altgr in my keyboard.. i am in VA
<axisys> anyways.. back to the issue.. let me try with sudo
<axisys> ok using sudo -H -u user -- autossh ... , same issue.. let me remove the -f
<axisys> I lied.. sudo -H -u user -- autossh not going to work for me if run as root
<axisys> Defaults        !root_sudo in sudoers
<ion> Remove that line; fixed. :-P
<axisys> ion: thanks for your help
<axisys> $ status autossh
<axisys> autossh start/running, process 11341
<axisys> and syslog looks good too
<axisys> no more -f
<axisys> now that it is supervised.. if i kill autossh .. it should restart?
<ion> yeah
<axisys> cool! worked.. awesome!
<axisys> ion: thanks a lot
<ion> np
<axisys> i have another nfs issue i like to resolve with upstart.. 
<axisys> mount /foo /bar && run_cmd does not always work
<axisys> if it is not mounted it is fine..
<axisys> but if it is already mounted.. mount still gives non zero exit code.. so run_cmd does not get called
<axisys> s/nfs/mount/
<axisys> it is a mount issue.. 
<axisys> start on mounted MOUNTPOINT=/bar
<axisys> run_cmd
<axisys> ^ this should work ?
<axisys> mounted seems like a better condition that looking at the exit code of mount
<axisys> is there some cookbook related to mount that I can look into for example?
<axisys> http://dpaste.com/hold/713910/ <-- this is what we are using.. but I am not confident about line 51
<axisys> plus looks ugly compare to "start on mounted MOUNTPOINT=/bar" 
<axisys> wow.. tons of mount related upstart scripts under init/ doh!
<SpamapS> axisys: start on mounted MOUNTPOINT=/bar works fine if you want your job to only start right after that mountpoint is available.. it can be tough to make that useful in generic situations though
#upstart 2012-03-10
<nick_h> an app generated some upstart scripts for me, which i've installed. what might cause "sudo stop domain.com" to make upstart think that it was successful, but not actually stop the process?
<nick_h> the upstart scripts are: https://gist.github.com/bac84614e823361e2eb6
<JanC> first of all, they are configuration files, not scripts...
<JanC> and what process is still running?  does it fork & detach from its parent?
#upstart 2012-03-11
<nick_h> JanC: sorry for the late reply. the process that's still running is named "resque-1.19.0". how can i determine if it forks and detaches from its parent?
<till_> hi
<till_> was wondering if anyone could give me a hand debugging in here
<till_> my error messages range from 'unknown job' to a message that my service started
<till_> but it really didn't
<till_> add to that
<till_> i wanted to symlink my job.conf to /etc/init
<till_> and it seems like upstart doesn't like that at all
<till_> i strace'd the process, it seems to stop with 'resource unavailable' somewhere
<till_> even though the symlink is correct and i am executing with sudo
<till_> $ sudo initctl -vvvvvv start gearman-worker
<till_> gearman-worker start/running, process 17992
<till_> hehe
<till_> am i "screwed" on lucid with upstart 0.6.5?
<zykotick9> till_: big response.  good luck.
<till_> lol
#upstart 2013-03-04
<jodh> /topic Upstart 1.7 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
<jodh>  
<jodh>  
* jodh changed the topic of #upstart to: Upstart 1.7 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
 * xnox mission impossible theme tune
<xnox> upstart one point seven
<xnox> tudodoon.
<ion> Congrats. /me reads whatâs new.
<herriojr> quick question: when I write the following script:startx.conf
<herriojr> rrr, let me pastebin
<herriojr> http://pastebin.com/n2LvMzpQ
<herriojr> when I write that script, it doesn't appear to be sending off the startx-started message to initctl so other upstart scripts reliant on it never get executed
<herriojr> and for testing, I'm executing it by doing: sudo initctl start startx
<phroddon> herriojr: did you try with the -n argument (initctl -n emit ...) ?
<phroddon> s/argument/option/
<herriojr> -n meaning no-wait?  I don't see it in the man pages
<herriojr> oh and I eventually got it working
<herriojr> so it's a solved issue at this point
<herriojr> thanks though
#upstart 2013-03-05
<rvgate> im creating a custom upstart script... when i say "service pentaho start" it tells me, job is already running... "service pentaho stop" hangs, and "initctl status pentaho" tells me pentaho is start/killed... what do i do now? :/
<rvgate> i want to be able to do a clean start/stop again
<SpamapS> rvgate: does 'status pentaho' show a pid that does not exist?
<rvgate> SpamapS, yes
<SpamapS> rvgate: ok, you have 'expect fork' set wrong
<SpamapS> rvgate: its a known bug, if you set it wrong then the pid will go missing
<SpamapS> rvgate: you have to exhaust pid space to release the job
<SpamapS> rvgate: (or reboot)
<rvgate> reboot it is
<rvgate> dev machine anyway :P
<SpamapS> https://bugs.launchpad.net/upstart/+bug/406397
<SpamapS> http://heh.fi/tmp/workaround-upstart-snafu
<SpamapS> has a script which does the pid space trick
<SpamapS> rvgate: make sure before you reboot that you disable the start on for the job or it won't help right? :)
<SpamapS> jodh: any progress on that bug btw?
<SpamapS> slangasek: ^^
<rvgate> i didnt even bother defining a start on yet, since i need to make sure it works first :P
<SpamapS> IIRC there was some thought that it would go away if we moved away from ptrace
<rvgate> SpamapS, while the machine reboots... could you explain the "exhaust pid space"... it went way over my head
<jodh> SpamapS: a little - watch this space...
<SpamapS> jodh: :)
<SpamapS> rvgate: so when you fork(), you get highestpid+1
<SpamapS> well.. actually its just a counter that goes up until you reach a free slot
<SpamapS> rvgate: anyway, that counter wraps at 65535 .. so.. you have to keep fork()'ing until the missing pid is re-tried.. then upstart will be able to see that pid, reattach to it, and then watch it die
<rvgate> haha
<rvgate> so basicly the pid used gets lost
<rvgate> unable to find it... unable to stop it.. and it hangs
<SpamapS> There are a bunch of ways I'd love to fix it, but jodh and slangasek have told me "don't bother" for a while.. 
<rvgate> got the script working now again, thanks for the help SpamapS 
<slangasek> SpamapS: I don't remember the "don't bother"... I remember saying we should fix it right instead of extending initctl with an "oops" interface
<SpamapS> slangasek: thats "don't bother" in my head anyway
<slangasek> heh, well, I wouldn't mind help fixing it right ;)
<SpamapS> jodh: If you're around.. was poking at the logging bits of upstart and wondering about what might happen if a system had way too many upstart processes actively logging....
<SpamapS> jodh: like, say, 50 active loggers producing > 8K/s
<SpamapS> slangasek: ^^ ?
<jodh> SpamapS: if upstart is unable to create a new pty to handle the logging, it emits a error, then degrades the job to "console none" automatically.
<SpamapS> jodh: pty's aren't the problem. Processes blocked on write() to stdout/stderr would be though.
<jodh> SpamapS: but if you're talking about lots of jobs producing a ton of output, then you might have issues, yeah.
<SpamapS> jodh: seems to me that the buffer size might need to be configurable.
<jodh> SpamapS: are you talking about specifying a buffer size limit?
<SpamapS> jodh: I'm talking about the buffer on the pty. Its just a default buffer size AFAICT.. and my brain says that is only 8K
<jodh> SpamapS: kernel code suggests it is 64k, but you might want to check with apw on that. init caches as required to minimise the possibility of jobs blocking on write so I don't think there is much else we can do. About to log off but if you can provoke bad behaviour, please let us know.
<SpamapS> 64k is much better than 8k
<SpamapS> well, 8x better anyway *
#upstart 2013-03-06
<cwillu_at_work> does upstart do its own permissions checking?
<cwillu_at_work> I think I've got /etc/dbus-1/system.d/Upstart.conf set to permit one more message through as a particular user to a particular service, but I'm getting a com.ubuntu.Upstart0_6.Error.PermissionDenied
<cwillu_at_work> (without the Upstart.conf change, I get a generic dbus error instead)
<cwillu_at_work> hmm, this appears to be something related to the (new?) session support
<cwillu_at_work> --no-session on the kernel command line makes it work right
<xnox> cwillu_at_work: interesting, what upstart version is that?
<slava_dp> hey everyone. in rhel6, what's the best way to switch uid and gid for a daemon?
<slava_dp> I'm writing an upstart job and setuid and setgid are not supported in rhel6
<maveas> Hi guys. Does upstart emit events when a sysvinit script successfully starts? I am asking because I am about to write an upstart script for openerp and I need it to start on running postgres but I am quite new with init, both sysvinit and upstart..
<maveas> And I don't think it does but I'm not sure
<maveas> I am thinking upstart is watching for a exit 0 but that doesn't really tell if the job is running ?
<maveas> Been reading a lot of documentation and from what I can understand this is how it works. Am I right? So as I need to control for a running postgres instance I could either do some pre-start code in my upstart script for OpenERP or I could create an upstart script for postgres so my OpenERP upstart script start when upstart emit that postgres is running.
<maveas> Never mind guys. Just realised that I can do a initctl emit postgres-running from the postgres sysvinit script. :)
<jodh> maveas: yes, that is the best method. However, you'll need to ensure you only emit that event when postgresl is actually *ready* (not necessarily the same time as when it *starts*)
<maveas> Yeah, I'm still looking into that. :)
<maveas> Thanks
<SpamapS> jodh: Hey, just wanted to give you a "nicely done" on the way upstart handles logging.
<SpamapS> jodh: I contrived a "worst case" scenario yesterday and I couldn't break upstart.
<jodh> SpamapS: cool - good to hear ;-)
<SpamapS> jodh: I do believe it will break down on a *REALLY* big box with *lots* of processes (like, 64 CPU w/ 10000 processes writing)
<SpamapS> jodh: but with 1CPU, 50 processes writing as hard as they can, init was using about 20% of the CPU, with the other 80% going to the kernel handling buffer shuffling
<SpamapS> jodh: I was wondering if we could somehow turn that into a test actually
<pseudonymous> anyone feel like translating "service disable -my service-" and "service stop -my service-" to upstart-speak ? In ubuntu I have two services, whoopsie and cron that NEED to be dead for the purposes of a benchmark, but quick as I kill them, they reappear
<SpamapS> pseudonymous: disable is rough, but 'service stop -my-service-' works fine
<SpamapS> pseudonymous: don't kill them, 'service cron stop' them
<SpamapS> pseudonymous: disable would be for reboots. For that you can 'echo manual >> /etc/init/whoopsie.override'
<pseudonymous> SpamapS: thanks so very much, I was really losing my temper with this stuff :D
<xnox> pseudonymous: see http://upstart.ubuntu.com/cookbook/  it actually tells one how to do that ;-)
<maveas> You guys behind Upstart. I just want to say thank you and to hug you.. As you may have noticed I started exploring Upstart today and I love it! :)
<maveas> It really makes a lot of sence and I hope it will become de facto on most systems. <3 :b
<maveas> Kudos
<pseudonymous> maveas: I couldn't disagree more </3 systemD forever and ever and ever and ever and ever.. :)  And with that, good night ! But thanks still for the effort
<SpamapS> pseudonymous: I invite you to read the code of systemd and of upstart, and then re-assert what you are saying.
<SpamapS> pseudonymous: I know systemd has a ton of user-sugar .. but.. buyer beware. Its got a lot of easy, not much simple.
<maveas> There's a lot of fuss around Upstart but I think it's because people just don't understand it yet (and won't try to)..
<maveas> He'll come around some day ^
<SpamapS> maveas: unfortunately, the rest of the Linux world got tired of waiting for Upstart to fix their problems, and so they invented systemd.
<SpamapS> maveas: it may take years for that to fail.. or systemd may become "the one true thing"
<xnox> SpamapS: i wonder if you failed the double negative there. </3 is "do not love" where as <3 "do love", thus pseudonymous is on the upstart side.
<cwillu> xnox, whatever's in precise
<cwillu> 1.5-0ubuntu5
<SpamapS> xnox: I'm not sure I understand what you're saying.
<cwillu> SpamapS, </3 is a broken heart
<SpamapS> I think pseudonymous meant <3 .. since pseudonymous was disagreeing with maveas hoping that it will become de facto on most systems
<magicrobotmonkey> I've got a stop/killed <pid> job I can't get rid of. What should I do?
<SpamapS> magicrobotmonkey: https://bugs.launchpad.net/upstart/+bug/406397
#upstart 2013-03-07
<marrusl> magicrobotmonkey, if you want to restart it without rebooting, you can rename the job file and start that job name.
<magicrobotmonkey> lets say you've got this daemon that, according to strace, forks 5 times
<SpamapS> magicrobotmonkey: "this daemon" is doing it wrong
<magicrobotmonkey> i know
<SpamapS> magicrobotmonkey: do you have any control over the daemon?
<SpamapS> magicrobotmonkey: like, can you change its code or pass options to run it in the foreground?
<magicrobotmonkey> yea i can probably get in there and hack around a bit
<magicrobotmonkey> https://gist.github.com/acdha/1506392
<magicrobotmonkey> im also not sure that it actually is forking 5 times
<SpamapS> its a shell script?
<SpamapS> unless the shell script uses 'exec', thats one fork
<magicrobotmonkey> no its a shell script that calls a python script that does it's own daemonizing
<SpamapS> ah
<SpamapS> graphite is made by pretty sane people, I bet it can run in the foreground
<magicrobotmonkey> yea i agree, i'll keep hacking around, thanks
<magicrobotmonkey> hey what happens if your script has a prestart but no script/exec, like this: https://github.com/gosquared/graphite-cookbook/blob/master/templates/default/carbon-cache.upstart.erb
<jY> is there anyway to fix the hang on start/stop without a reboot or rename the conf in /etc/init
<SpamapS> jY: yes, you can loop the pid space to re-create the dead pid
<jY> SpamapS: but i need to do that for all services
<jY> or just run it once?
<SpamapS> all?
<SpamapS> jY: you have one stuck job right?
<jY> yes
<SpamapS> jY: just once
<jY> whats a command to do that
<SpamapS> jY: there's a ruby script that does it linked in the bug
<jY> thanks
<magicrobotmonkey> there's a bash script on it too
<jY> ok i'll try to find the bug
<SpamapS> https://bugs.launchpad.net/upstart/+bug/406397
<jY> i take it i use the ruby script to hit the pid of the hung start/stop?
<magicrobotmonkey> yup
<jY> thanks guys
#upstart 2013-03-08
<ebel> OK, this is weird. I have an upstart job that starts a SSH tunnel to a host. But I can't stop it!
<ebel> it was running, and when I "stop JOBNAME" it, the ssh process is still running.
<xnox> ebel: probably tracking wrong pid.
<xnox> ebel: compare ps output with `status yourjobname`. Do the pids match?
<ebel> http://pastebin.com/9XghsZFu FYI this is the /etc/init/JOBNAME.conf
<ebel> xnox: ah, yeah, different pids...
<ebel> I should use "expect" here
<ebel> I read that part of manual, but I thought ssh would stay in foreground....
<ebel> after I 'stop JOBNAME' it, the process is still running. But if I kill the PID, then a new one starts up again
<SpamapS> ebel: you should not need expect
<SpamapS> ebel: you don't need to use sudo
<SpamapS> ebel: setuid svn_ssh is all you need there
<SpamapS> ebel: a whole raft of things wrong with that upstart job.
<SpamapS> ebel: 1: start on startup means you will start before networking, before filesystems are mounted, before EVERYTHING
<SpamapS> ebel: you want 'start on runlevel [2345]'
<ebel> this is my first attempt at an upstart job...
<SpamapS> ebel: oh and two start ons means 'start on startup' isn't actually going to be used, so 'started network-services' will be used
<SpamapS> ebel: I have almost the exact same thing... I use keep-one-running to keep mine up though, because upstart is too eager to give up with respawn
<ebel> gah, i've stopped the upstart job, and the ssh process is still there. i keep trying to kill it but something is respawning it....
<SpamapS> http://paste.ubuntu.com/5596412/
<SpamapS> ebel: thats what I use to keep a tunnel up (changed to use some of your values ;)
<SpamapS> ebel: note that I have vmstat 30 doing my alive interval ;)
<SpamapS> hm, I guess -TN would have been better :)
<SpamapS> ebel: anyway, I've been using that job for a couple of years now
<ebel> thanks
<ebel> gah, now it says "unknown job" when I try to start it...
<ebel> anyway to do a syntax check or something?
<SpamapS> ebel: init-checkconf
<ebel> don't have that command
<ebel> ubuntu 10.04 server
<SpamapS> ebel: oohhh
<SpamapS> ebel: then you do need sudo :-P
<SpamapS> ebel: you know.. 12.04 released almost a year ago.. :)
<ebel> ;)
<ebel> is there anyway to see if it's upstart that's restarting/respawning this ssh process?Â is there logs or something?
<SpamapS> ebel: initctl log-priority info
<SpamapS> ebel: though I think default logging priority would show upstart messages on respawn
<ebel> where are the logs?
<ebel> restarting the server is maybe an option, but don't want to have to
<ebel> ah syslog
<ebel> feck it, rebooting server
<ebel> hit it with a big hammer
#upstart 2013-03-09
<tartar> I have a pair of conf files, one for a service SERVICE.conf and another for a task blocking its dependants from starting earlier, SERVICE-block-dependants.conf.
<tartar> How do I block the pre-start of SERVICE.conf until mounted MOUNTPOINT=/ ?
<tartar> Currently I wait for a writeable directory the service needs in its pre-start and absence of *fsck* processes.
<tartar> This worked around the scenario when the dependants start early in /sbin/init, running "start SERVICE".  At that point / still mounts in memory and an mountall runs fsck for the root disk partition.  That fsck process may take a minute or more on exceeding the maximum count.
<tartar>     while ! test -w /var || killall -0 --regexp fsck ; do
<tartar>          sleep 1
<tartar>      done > /dev/null 2>&1
<tartar> But this still suffers from a timing window between the exit of fsck and the mount of /.
<tartar> I would rather depend on "mounted MOUNTPOINT=/", but I find difficult to inject this hook into the pair.
<tartar> It does not matter how long fsck runs, the timing window would present the same probability for SERVICE to use the fake /var.
<tartar> If that happens, mountall's mounting / against the real disk partition causes the loss of file entries the service created in the fake /var.
<tartar> I could use the output of "df /var" to tell if /var belongs in a disk, but this does not look as nice as "mounted MOUNTPOINT=/".
<tartar> It would be nice if I could use a conjunction "and" against a set of "or" hook events in SERVICE-block-dependants.conf, but I heard this suffered from a bug and I am stuck with Lucid for now.
<tartar> Using "and" in SERVICE-block-dependants.conf would mix up the existing hook events for SERVICE's dependants with the new hook event for SERVICE's requisite.  This would complicate reasoning for the SERVICE-block-dependants.conf.
<tartar>  
<tartar> To sum up, I need to wait for a hook or pass if the hook already went by.
<tartar> Can initctl do that?
<tartar> Alternatively, I would love to "initctl emit wait-for-mountall MOUNTPOINT=/" if mountall could receive upstart events.
<tartar> I guess some mountall-watch.conf could "start on wait-for-mountall MOUNTPOINT=/ and mounted MOUNTPOINT=/"?  Will Lucid's upstart wait for 2 hook events in any succession before returning control to the above "initctl emit"?
<tartar> I do not need MOUNTPOINT=/ in wait-for-mountall.
<tartar> To shorten that, I do not need to send a hook, I could just "start on starting SERVICE and mounted MOUNTPOINT=/" in some root-block-SERVICE.conf.
<keshav89> Hello everyone
<keshav89> I am a newbee in upstart
<keshav89> Just got to know about upstart
<keshav89> as I was searching for a process management tool
<keshav89> Requirement was running my flask app forever
<keshav89> Basically I have ubuntu VM to which I ssh and run my "python flaskapp.py" - which starts a dev server
<keshav89> but if ssh connection breaks that server comes down
<keshav89> came to know about gunicorn and then upstart 
<keshav89> read the doc of upstart a bit
<keshav89> Here is what I understand:
<keshav89> 1. I need to write one simple myflask.conf
<keshav89> 2. Plcae it under /etc/init/
<keshav89> *Place
<keshav89> 3. in that script I will write something like : "pre-script chdir <flask_dir> end script exec python flaskapp.py"
<keshav89> Am I correct?
<keshav89> with script i meant myflask.conf which will be placed under /etc/init/
<keshav89> Any help or assistance appreciated
<keshav89> oh I should also have this line in the .conf file : "start on startup" right?
<keshav89> anybody?
<keshav89> :-[
<keshav89> I have a small conf file under /etc/init/
<keshav89> Which I am trying to run
<keshav89> with initctl
<keshav89> start on startup
<keshav89> pre-start script
<keshav89> # Changing directory to flask app
<keshav89>    chdir /usr/src/test/ans/
<keshav89> end script
<keshav89> script
<keshav89>    gunicorn -b 0.0.0.0:1234 testflask:app
<keshav89>    console output
<keshav89> end script
<keshav89> Basically I am trying to keep flask server running
<keshav89> Am I doing something wrong?
<keshav89> I am trying initctl start myflask.conf
<keshav89> Anyone?
<keshav89> http://paste.ubuntu.com/5598674/
<xnox> tartar: http://upstart.ubuntu.com/cookbook/ see "how to block another job"
<xnox> you can create a job which will block your main one, until complete. I think that will work for you.
<xnox> keshav89: http://upstart.ubuntu.com/cookbook/#chdir stanza?
<jamescarr> SpamapS: this is a shot in the dark, but your name came up when I was frantically googling for libmysqlclient-dev help on ubuntu :)
<jamescarr> SpamapS: do you know where I might find one of the maintainers on irc? Or at least someone familiar with it?
<jamescarr> SpamapS: never mind, I see you're one of them
<SpamapS> jamescarr: I'm a maintainer yes. Want to chat in #ubuntu-devel ?
<jamescarr> sure
<preyalone> I like to start little web servers on boot. I've been using upstart, but often my scripts fail, causing important services like sshd to fail to start. What's a safer way to do this?
<jamescarr> preyalone: I've never seen sshd not get started, are you fooling with the maintainer provided upstart scripts?
<preyalone> jamescarr: I haven't fooled with anything. I recently upgraded my hardware (I use Gandi VPS hosting), and the sysadmin helping me with the upgrade mentioned that when my upstart scripts fail, it can cause things like sshd to not start up.
<SpamapS> preyalone: thats b.s.
<jamescarr> yah what SpamapS said
<preyalone> Understood.
<SpamapS> preyalone: can you share your upstart job that sometimes fail?
<jamescarr> just because an upstart script fail doesn't keep others from running
<SpamapS> preyalone: I'd bet that you're starting things too early
<preyalone> In any case, I've noticed that my upstart scripts DO fail a lot, so when my server restarts, I'll notice that a service isn't running at all. Example: https://github.com/mcandre/node-ios7crypt/blob/master/upstart.conf
<SpamapS> jamescarr: well, a failing job could certainly have also somehow cancelled another one. But.. yeah
<SpamapS> yep
<SpamapS> preyalone: man upstart-events
<SpamapS> preyalone: startup is *WAY* too early
<SpamapS> preyalone: no network, no disks, nothing
<SpamapS> preyalone: its only by a miracle that 'start on startup' ever works.
<SpamapS> preyalone: you want 'start on runlevel [2345]'
<preyalone> SpamapS: Thanks. :P
<SpamapS> preyalone: also, 'shutdown' is not an event. So you want 'stop on runlevel [016]'
<SpamapS> man
<SpamapS> there are a few examples that use those two events
<SpamapS> and they are like *weeds*
<SpamapS> kill 1, 5 more pop up
<preyalone> Can upstart scripts use hard tabs, soft, or what?
<SpamapS> preyalone: doesn't matter
<SpamapS> preyalone: they are not whitespace sensitive
<preyalone> Is that standard for .conf files, or just upstart .conf files?
<SpamapS> upstart
<SpamapS> .conf means nothing
<SpamapS> /etc/init/*.conf == upstart
<preyalone> SpamapS: Thanks for the info. I'm just thinking about configuring indentation in my text editor.
<preyalone> My Rails app works when I start it manually. But when I try to call the same command via upstart, my server doesn't start up. https://github.com/mcandre/doesrailswork/blob/master/upstart.conf
<xnox> preyalone: no need to use script, the exec and chdir are top level stanzas just like "start on"
<preyalone> xnox: Thanks, but that doesn't alter the behavior.
<xnox> there is no command line executable "chdir" so that's where the script fails.
<xnox> as the whole script is executed as if it's shell, with set -e
<preyalone> "rails server" needs to be executed in a specific current directory. What's the best way to do this in upstart?
<preyalone> xnox: I tried moving chdir and exec outside of script, but the problem still exists: the Rails app isn't running after I do "sudo start doesrailswork".
#upstart 2014-03-03
<hydoskee> is there a way to set a "display" environment variable in an upstart service?
<jodh> hydoskee: http://upstart.ubuntu.com/cookbook/#run-a-gui-application
#upstart 2014-03-05
<lolzadam> Getting "failed to execute /opt/upstart/sbin/init (error -2)" at boot
<lolzadam> After looking up error 2, I see that's "no such file or directory"
<lolzadam> The file definitely exists and I have confirmed the correct root partition is mounting without errors. Any ideas?
<JanC> -2 != 2
#upstart 2014-03-06
<lolzadam> JanC:  yes, but I couldn't find a -2 so i assumed. Any clue what -2 is then?
<cypherpunks> Question about upstart start conditions: are events instantaneous never-to-be-repeated things, or long-lasting conditions?  If the former, how do "and" start conditions work?  IF the latter, how to get a list of the current conditions?  (I'm trying to figure out why a job isn't starting.)
<cypherpunks> Ping?
<cypherpunks> Ping?
<cypherpunks> Sigh, it's quiet.
<cypherpunks> Anyone actually here?
<ion> They are instantaneous. Upstart was supposed to gain support for states (which would have made âandâ much better) but development has been kind of slow and now even Ubuntu is going to switch to systemd.
<cypherpunks> ion: Wow, thanks!  So if I have an and condition, like the one in stock Ubuntu tty2: "start on runlevel [23] and (not-container or container CONTAINER=lxc or container CONTAINER=lxc-libvirt)", it might not ever start because I can have the "runlevel" and "not-container" events both trigger, just not simultaneously?
<cypherpunks> I wish the cookbook was a little clearer on this point.  I have a mostly 12.04 system that refuses to start any console login process (getty or lightdm) until I ssh in and do it manually.  Very annoying.
<ion> IIRC the job keeps track of the events and when both conditions have been triggered itâll get started. The problem with events (compared to states) is that if the job is stopped by an event, i think both events may need to happen again for it to start again, even though you never left the state whose start one of the events represents.
<cypherpunks> Ah, so an event *can* be pending, but it's kept in the job's condition parse tree?  And there's no way to see them?
<cypherpunks> (I'm just trying to figure out "why the @#$$@$# is this not running", and it's a real bother to reboot, but I guess "--debug" is the only way.)
<cypherpunks> (to reboot this particular machine, FWIW.  There's a second bug I'm tying to debug where the kernel isn't finding the root file system, requiring manual intervention at the initrd shell prompt.)
<ion> Someone who has paid more attention to the and/or condition handling code than me can probably give more definite answers.
<cypherpunks> But thanks.  That does help clarify things.
<bingsucks> JanC: FYI I dug through the kernel source last night and error codes are negated before returned. The -2 I got is in fact equal to 2, which if you take a look at include/uapi/asm-generic/error-base.h, corresponds to ENOENT. I assume that means no inode entry for that file, because it is commented as no such file or directory.
<bingsucks> However I do need to look again to see if ENOENT is assigned to another constant.
<lolzadam> cypherpunks: if nothing else, have each event trigger a task job that sets an env var. Change that and to an or and just make the job check both vars
<jodh> xnox: Hi - could you review https://code.launchpad.net/~jamesodhunt/upstart/bug-1288243/+merge/209693 (and maybe knock off https://code.launchpad.net/~jamesodhunt/upstart/restrict-debug-stanza/+merge/204363 too?)
<xnox> jodh: i'm confused about the debug stanza =))) hence i didn't review it =)))
<xnox> jodh: aha, so re-exec didn't keep the name. Maybe re-exec should keep the name?
<jodh> xnox: that 2nd branch simply makes the debug stanza a NOP unless you boot with --debug.
<xnox> jodh: such that e.g. if i booted /sbin/init.dima it would stay init.dima after re-exec?
<xnox> jodh: and is the same binary re-execed?
<jodh> xnox: yes, it always re-execs its original argv[0].
<jodh> xnox: hence the problem in the test env :)
<xnox> jodh: hm, create test_init symlink?! =))))
<jodh> xnox: nooooooooo....!
<xnox> ok. =)
<lolzadam> On a kernel + busybox setup, I compiled upstart with an Arch disc. Used the /opt/upstart prefix, changed kernel line to include upstart init location. Now getting kernel panic "Failed to execute /opt/upstart/sbin/init (error -2)"
<lolzadam> Error -2 is commented in the kernel source as no such file. I have verified the rootfs is mounting successfully, and the old init on the same partition still works. Any ideas?
<lolzadam> BTW also verified the file is there and size is non zero
<jodh> lolzadam: boot using init=/bin/sh then after checking the file exists and ldd is happy with it, 'exec /opt/upstart/sbin/init --debug </dev/console >/dev/console 2>&1
<jodh> lolzadam: ' :-)
<lolzadam> Lol thanks.
<lolzadam> Haven't tried ldd, but did try 'exec <path> --verbose' per troubleshooting info on website and got 'init must be PID 1' erroe
<jodh> xnox: thanks for the reviews. The final https://code.launchpad.net/~jamesodhunt/upstart/bug-1258098/+merge/202458 should now complete the tests successfully.
<lolzadam> I will give that a shot though
<lolzadam> BTW is the upstart project going to be dropped after Ubuntu switches to systemd?
<lolzadam> systemd is too heavy and over complicated. Great for desktop, not so much for server OS imho
<xnox> lolzadam: systemd software collection is about ~30 daemons. /all/ of them are two heavy, but just the init is actually ok for a server.
<jodh> lolzadam: huh? when you boot with init=/bin/sh, you should be pid 1 ("echo $$")
<xnox> s/two/too/
<lolzadam> xnox: ah makes sense. So any predictions/insight on continued upstart development?
<jodh> lolzadam: regarding the upstart project - yes Ubuntu are switching to systemd, but we have not yet decided *when*. Also, even after we switch we still have years of support for releases containing upstart. After that, "I don't know" I'm afraid.
<lolzadam> jodh: I'll check, hang on
<lolzadam> Hmmm
<lolzadam> 158
<xnox> lolzadam: for the next 5-7 years, upstart will still be developed. Which is long enough for anything to happen.
<jodh> lolzadam: um, if that's a pid, that's your problem :)
<lolzadam> Lol sorry, wrong VM o.O
<lolzadam> Aha... ldd reveals some missing libs. Guess those wouldn't have been copied to the mounted partition with make install
<lolzadam> Doh! Lol
<lolzadam> Will it build and run right with --enable-static
<xnox> jodh: so, upstart bugfix release will be happening this week, right? i'm thinking to use inet6 socket activation =)
#upstart 2014-03-08
<lolzadam> When I try to run '/opt/upstart/sbin/init --debug </dev/console >/dev/console' I get 'init: Not being executed as init'
<lolzadam> Ah... Forgot the 'exec' in front of that. OK so I compiled this with a live CD and with the root fs mounted. The config directory is reflecting the mount point.
<lolzadam> How can I change the main config directory?
#upstart 2014-03-09
<trippeh> Can a upstart job be made to start after a sysvinit one?
<JanC> trippeh: sysvinit services can trigger upstart events
<JanC> (assuming you mean sysvinit services running on upstarts sysvinit compatibility layer, of course)
<trippeh> JanC: yes. What about depending on the Provides: from sysvinit script?
<trippeh> say on started or starting
<trippeh> thinking about its probably the wrong thing in my case, as the database could be external anyway ;)
<trippeh> still curious
<JanC> if this is an existing sysvinit script, you would have to change it to emit upstart events
<JanC> or you could probably change the sysvinit compatibility layer to do that
#upstart 2015-03-05
<paulm--> Is there a way to permit service reloading by non-root users?
<paulm--> I would like to be able to set a specific service to be reloadable by any user 
#upstart 2015-03-06
<paulm-> Is there a way to permit service reloading by non-root users?
#upstart 2015-03-07
<ceres> Hello. Is this a right place for a question regarding upstart?
<ceres> wohoo nevermind, figured it out. :)
#upstart 2016-03-08
<kurt11> When I try to stop a job I wrote, why would I get this: stop: Rejected send message, 1 matched rules; type="method_call", sender=":1.15" (uid=1000 pid=1588 comm="stop kafka ") interface="com.ubuntu.Upstart0_6.Job" member="Stop" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init ")
#upstart 2017-03-06
<rkulagow> good afternoon. trying to put together some upstart scripts that handle SQS queues at amazon. the scripts that i have work when i launch them at the command line using systemctl, but not if just reboot.
#upstart 2017-03-07
<rkulagow> hi - does anyone use this chatroom for upstart related issues? if not, where's the best place to ask?
<JanC> you could also try the mailing list or askubuntu (or some similar site)
#upstart 2018-03-09
<bn_work> hi, I know upstart has kinda been abandoned but does anyone know of a good guide that talks about how to migrate an older SysV style init script to Upstart?  I have looked at the official docs (http://upstart.ubuntu.com/cookbook/) and random blog posts (ex: https://coderwall.com/p/rt0qmg/upstart-a-builtin-alternative-to-god-and-monit , https://nnc3.com/mags/LM10/Magazine/Archive/2007/76/062-068_upstart/article.html)
<bn_work> but haven't seen any real good documentation on how to "translate" to the "new model"
<bn_work> (note, this is on a Ubuntu 14.04 LTS box which I'm not too keen on upgrading yet)
<hallyn> shouldn't 14.04 already be upstart?
<hallyn> the cookbook is the best guide i know of, i'm afraid
<hallyn> but it shouldn't be hard.  upstart scripts were easy to write
<bn_work> hallyn: it  is already upstart but I have software on it that only provides a SysV init script
<hallyn> ok yeah, just look atthe existing scripts, shoudl be pretty clear how to convert.
<bn_work> hallyn: there is http://upstart.ubuntu.com/cookbook/#migration-from-system-v-initialization-scripts but it talks nothing about migration
<bn_work> uh... not really?
<hallyn> <shrug>
<hallyn> whch part is causing trouble?
<bn_work> I was hoping there some kind of table showing how to map the concepts from one to the other?
<bn_work> an upstart (.conf?) file (job?) isn't a shell script anymore, correct?
<hallyn> right
<hallyn> it has 'start on / stop on' for ordering, 'pre-start script' 'script' etc which can be shellscripts  (inline) for running,
<bn_work> I mean honestly the vendor should be doing this but they have no clue, so I'm trying to kinda point them to the right resources
<hallyn> and the 'expect daemon' or whatever for tracking init
<hallyn> it doesn't really map bc waht you'd be mapping from is kind of free-form :)
<bn_work> `expect daemon`?
<hallyn> http://upstart.ubuntu.com/cookbook/#expect
<bn_work> yeah, but most init scripts have a basic structure in terms of supporting params like start/stop/status/restart
<hallyn> best is if  you can run the software sothat it just runs in the foreground,
<hallyn> anyway let's see, maybe someone else here knows of a better guide along the lines of what you want
<bn_work> ok, just read the entry on `expect [fork|daemon|stop]`
<bn_work> if it's of any help, the source script I'm trying to adapt is at http://www.reprisesoftware.com/RLM_Enduser.html (under "Starting the rlm server at system boot time on Unix systems")
<bn_work> seems it supports start/stop
