#upstart 2007-04-30
<mbiebl> Md: Did you have any problem with switching to upstart?
<Md> mbiebl: actually I have not rebooted yet :-)
<mbiebl> Ah, ok. I've been hacking a bit on native upstart jobs over the weekend.
<mbiebl> The results are pretty promising: http://debs.michaelbiebl.de/upstart/bootchart.png
<mbiebl> Works pretty good so far.
<Md> the next obvious step should be running fsck/mount asyncronously from udev
<Amaranth> mbiebl: 19 seconds from grub to X?
<mbiebl> Amaranth: Yes, including initramfs
<mbiebl> It's a 3 year old laptop. 
<Amaranth> _damn_
<Amaranth> i'm sitting at 35 seconds for my laptop and it's less than a year old :)
<Amaranth> I think I need to do some trimming
<mbiebl> I have to admit, if I switch to gdm instead of entranced, it adds another 8 secs. (gdm is just so slow...)
<Amaranth> heh
<ion_> entranced, huh? Hadnt heard of that one.
<ion_> % apt-cache search entrance
<mbiebl> e17 login manager
<ion_> % 
<ion_> Ah.
<Amaranth> gdm is a key part of a couple nice gnome features
<mbiebl> Still, I think gdm needs some serious profiling ;-)
<mbiebl> Even kdm is a lot faster.
<Amaranth> either way if with gdm you can get a 27 second boot i should be able to get 13 seconds or something :)
<mbiebl> Which fs do you use for / ?
<mbiebl> Reiser3 can take 3-4 secs just for mounting.
<Amaranth> ext3
<Amaranth> i'm plain and boring :)
<mbiebl> (depending on the size of the partition)
<Amaranth> but i've got a core duo and the fastest laptop HD in existence so... :)
<wasabi_> I had no idea people still worked on e17
<ion_> My boot time probably decreased by a half when i switched from a 5400 RPM HDD with less than  MiB of cache to a 7200 RPM one with a 8 MiB cache. :-)
<mbiebl> wasabi_: they have a pretty complete Debian repo at deb http://edevelop.org/debian/ unstable main
<wasabi_> That stuff usable
<wasabi_> ?
<Amaranth> ion_: yeah, i've got one of those two
<wasabi_> Or is it still just tech demos?
<Amaranth> is yours hitachi?
<ion_> Samsung
<Amaranth> wasabi_: I imagine the login manager, window manager, etc is usable but the rest is still at tech demo level
<ion_> The older one was an IBM Deahtstar.
<mbiebl> wasabi_: It's definitely usable, but e17 won't become my main desktop though.
<Amaranth> ion_: ah
<ion_> Death even.
<Amaranth> ion_: sata?
<ion_> Plain PATA.
<Amaranth> oh
<Amaranth> suppose it doesn't make too much of a difference with these laptop drives
<Amaranth> mbiebl: wow, you disabled most everything to get that time :)
<mbiebl> Amaranth: Really? 
<Amaranth> well i've got junk for bluetooth and such here
<Amaranth> looks like all you did was essential "this has to run for my system to boot" stuff plus dbus and X
<mbiebl> Well, not quite: I run syslog-ng, acpid, anacron, cron, dbus, hal, NEtworkManager, dhcdbd, console-kit
<mbiebl> Pretty complete I'd say.
<Amaranth> oh, you made upstart scripts for hal, networkmanager, and dhcdbd?
<Amaranth> because otherwise dbus will start those with it's own init system
<mbiebl> That's actually not true anymore in Debian.
<Amaranth> oh?
<mbiebl> I made all the Dbus init scripts regular sysv init scripts the last week.
<Amaranth> cool
* Amaranth should start working on making his boot faster
<mbiebl> /etc/dbus-1/event.d/ will soon be gone.
<Amaranth> if i can get it below 20 seconds it's faster than hibernating :)
<wasabi_> Are we suspecting that upstart will in fact replace dbus' init system?
<mbiebl> wasabi_: sure
<wasabi_> including activation, or has nobody brought it up?
<mbiebl> Ah, Service activation is a different topic.
<Amaranth> activation is not something upstart should manage
<wasabi_> Why?
<Amaranth> i know i don't really want upstart managing my rhythmbox ;)
<Amaranth> although i suppose it doesn't matter
<mbiebl> But dhcdbd, network-manager, hal, avahi etc are all native jobs which run as soon dbus is started.
<wasabi_> Hmm.
<wasabi_> I'm not sure how I feel about that either. I think I don't like the idea of DBUs launching UI apps etiher.
<wasabi_> Heh.
<Amaranth> upstart seems a bit heavyweight for something as simple as 'dbus path doesn't exist, $app provides it, launch $app'
<wasabi_> I think a few people have brought up the idea of using upstart for desktop sessions.
<wasabi_> I'd like to think about it someday. :0
<wasabi_> Basically a non-PID 1 upstart copy.
#upstart 2007-05-01
<mbiebl> similar to the system and session bus concept from d-bus?
<wasabi_> Yeah.
<wasabi_> Basically, just using upstart as a process for managing parallel starts based on event emission.
<wasabi_> Which is all it is.
<wasabi_> One code base which is efficient at managing child processes and stuff, instead of many.
<mbiebl> Well, imo there are more important issues than that atm though.
<wasabi_> dbus could use it to do activation.
<wasabi_> the system bus could do activation on the system upstart, the session bus could do activation on the session upstart.
<mbiebl> complex-event-config being one ;-)
<wasabi_> yeah.
<mbiebl> pid file support is another.
<mbiebl> There are still daemons out there which can't be run in the fg.
<cyberix> Does upstart automagically react to changes in inittab?
<AlexExtreme> no
<cyberix> How can I tell it to react?
<wasabi_> upstart doesn't use inittab, does it? heh
<wasabi_> So that would be a "you can't."
<cyberix> It has a similar configuration file?
<wasabi_> /etc/event.d
<wasabi_> It's quite different, so no.
<cyberix> ok
<cyberix> Thanks
<mbiebl> wasabi_: The sysv compat layer in Debian/Ubuntu reads /etc/inittab (if existent) to determine the default runlevel.
<mbiebl> Otherwise /etc/inittab is not used.
<wasabi_> Ahh, but that's not upstart itself as much as one of the job files
<mbiebl> Right, It's the rc-default job file.
#upstart 2007-05-03
<blackmogu> got a quick question about initctl and upstart
<blackmogu> is it possible to get output from a job on a pty without resorting to silly hacks ?
<sadleder> mbiebl: hi, what's going on on the upstart-for-debian front?
<Md> sadleder: crap. some people are proposing to create a huge infrastructure to support every existing init daemon
<sadleder> Md: oh boy
<sadleder> Md: i read some posts on p.d.o
<sadleder> Md: could you point me to planning pages?
<Md> no pages, subscribe to the initscripts-ng-devel@lists.alioth.debian.org list
<mbiebl> I also think that this idea is crap and will not work.
<nenolod> seems a bit silly
<Md> yes, but right now I am the only person saying it's stupid... please subscribe
<mbiebl> Md: Yeah, I'll add my 2 soon.
<sadleder> i sencond this
<sadleder> second*
<sadleder> mbiebl: are you running a fully upstartified system now?
<mbiebl> Yes. The mounting and network stuff is still serial though.
<sadleder> mbiebl: and it's not yet packaged, right?
<mbiebl> There are still some missing pieces where I haven't decided yet, how I'm going to handle it.
<mbiebl> So, no. No "official" packages yet.
<sadleder> mbiebl: ok. just let me know, I'm available for trying them early
<sadleder> ;-)
<cort> what problem can't be solved by the addition of a new layer of indirection?
<ion_> cort: Some problems need a perl oneliner and a regexp in addition to that.
<Julius> hi
<Julius> Md are u there ?
<ion_> julius: Im sure others can answer your Upstart-related questions as well.
<Julius> ion_, well actually i wanted to get my nickname dropped but some1 did it, thanks :)
<ion_> I fail to see how thats on-topic for #upstart.
<AlexExtreme> Julius, if you want freenode issues solving you should msg a staff member
<Julius> AlexExtreme, that's what i did, thanks ! Md is one of them, that's why i tried to speak to him
<Julius> cya guys :)
* AlexExtreme sighs
<cyberix> How does one set up serial login with upstart?
<cyberix> After a serial driver loaded signal somehow?
<Md> what?
<Md> you just take the event configuration for a console getty, copy it and write ttyS0 there
<ion_> For a system without the sysvrc compatibility layer, perhaps just add a modprobe command to pre-start. An alternative would be making udev emit an event when it loads the module, and 'start on' that event.
<ion_> If you have the compatibility layer, you can pretty much assume the module has been loaded.
<ion_> (i think)
<cyberix> Thanks
<Md> the serial driver will be loaded automatically by udev
* AlexExtreme ponders: I have a udev job which runs udevd, and a udevtrigger job doing udevtrigger && udevsettle with 'start on started udev'. the udev job has the respawn stanza
<AlexExtreme> so
<AlexExtreme> if I stop and restart udev, or udevd dies and gets respawned
<AlexExtreme> udevtrigger will be re-run
<AlexExtreme> and thus all the jobs with start on stopped udevtrigger ok will get run
<AlexExtreme> and the whole boot sequence will be run again
<AlexExtreme> which is not good
* AlexExtreme wonders how to get around that
<mbiebl> This only happens for jobs which start on stopped udevtrigger, which aren't stateful, right?
<mbiebl> In your case, that would be fsck and swap I guess.
<mbiebl> Actually, swap is stateful.
<mbiebl> So it wouldn't start again (as the job is already running)
<mbiebl> AlexExtreme: You could create a state "system-mounted" (better name to be chosen) which run on started udevtrigger
<mbiebl> Argh, I meant "system-fscked"
<Md> actions on file systems like fsck and swap should happen as a result of the block devices appearing, either as udev rules or upstart events
<Md> there is no need to serialize everything on udevtrigger
<mbiebl> Md: If udev dies and is respawned, would udevtrigger see the block devices as newly added
<mbiebl> or not.
<Md> if udev is respawned for any reason (e.g. upgrade) it is wrong to run again udevtrigger
<Md> udevtrigger must be run exactly once (at boot time) and never again
<mbiebl>  Then either the udevtrigger has to create some kind of lock file on startup (in /var/run) and when invoked a second time it simply does nothing when this file exists
<mbiebl> Or we would need something like a "once" keyword in upstart.
<Md> I think it should be possible to create some condition to run an event only once
<Md> udevtrigger cannot do anything by itself because it's usually run at a time where / is mounted ro, so if there is some rw fs available it's a distro-specific issue
<mbiebl> One problem on running the mounting/fscking asynchronously is, that it might actually be slower than running it sequentially.
<ion_> I dont see how.
<ion_> And if there are multiple HDDs, it would be faster.
<mbiebl> Disk thrashing.
<ion_> That would naturally be prevented by locking the fsck instances based on the physical device.
<mbiebl> (which means, we serialize them again ;-) )
<ion_> Only if there is just a single HDD.
<ion_> http://johan.kiviniemi.name/blag/2007/03/19/upstart-and-mounting-partitions-part-2/
<mbiebl> Right. I agree with you though, that this is probably the way to go.
<mbiebl> It might get a bit tricky for lvm on raid and stuff like that.
<ion_> Why is that?
<mbiebl> Have you already worked on the tools to give you the physical device?
<ion_> I did a functional prototype in sh, but i havent done the final C implementation.
<mbiebl> Ok: what about the following scenario:
<mbiebl> You have two disks: 40 GB and 80 GB
<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 sdb/sdb1; do foo "$f" | xargs echo "$f":; done
<ion_> dm-0: sda sdb
<ion_> md1: sda sdb
<ion_> sda: sda
<ion_> sdb/sdb1: sdb
<mbiebl> One 40 GB pv on the first, a second pv on the second disk, and the remaining 40 GB on disk 2 are a regular partition.
<ion_> It causes no problem at all.
<mbiebl> You then create a lv out of pv1 and pv2
<mbiebl> When you fsck the lv, will you lock disk1 and disk2?
<ion_> Yes.
<mbiebl> So, this means the second hard disk has to wait, event when it could check the second partition hdb2.
<ion_> How can you be sure it could check hdb2, unless you hack fsck itself to handle the parallelization and make it compute which physical devices certain subsections of a partition reside on?
<mbiebl> Yeah, what if I make hdb1 1GB and hdb2 79 GB.
<mbiebl> This would mean after fscking hda1 there would be two instances of fsck on hdb running in parallel
<ion_> It changes nothing. :-)
<mbiebl> (for 1 Gb)
<ion_> What do you mean?
<mbiebl> It would still be faster
<cort> surely you'd want to serialise the fscks anyway if the two disks were hda and hdb
<cort> since they would both be on the same ide channel ;)
<ion_> Say there are the partitions dm-0[hda1,hdb1]  and hdb2. fscking dm-0 would lock hda and hdb, fscking hdb2 would lock hdb. Why would there ever be two instances of fsck running on hdb?
<mbiebl> Well, what about hda and hdc then
<mbiebl> This is,  what I meant it get's a bit tricky to do it right.
<cort> so the actual decision of what to serialise requires some domain specific knowledge
<cort> gets tricky when you consider that with a recently kernel, hda and hdb show up as sda and sdb
<mbiebl> (if you use libata)
<ion_> What problems would fscking two HDDs in the same ATA channel cause?
<cort> it would be slow i think
<cort> afaik the two would compete for i/o, just as if you tried to fsck two partitions on hda at the same time
<ion_> I wouldnt expect it to be slower than serializing the checks. The problem in fscking two partitions on the same HDD is disk thrashing; any I/O waits are a consequence, not a cause.
<ion_> If the ATA bus is faster than one of the HDDs, it would definitely be faster than serializing the checks.
<mbiebl> ion_: you still have the scenario, where a small 1gb lvm partition on disk2 would block disk2 for a long time
<ion_> That is no worse than the current situation where nothing happens in parallel.
<ion_> I.e. even in that scenario, there is no regression.
<ion_> Getting rid of that problem would require some serious fsck hacking.
<mbiebl> Ok, off to bed now.
<mbiebl> G'night
#upstart 2007-05-04
<rawler> heya ppl.. where's the place to submit contributions to upstart in ubuntu?
<rawler> partially service-scripts, and partially event-triggers..
<rawler> should I submit to the respective package in launchpad, to upstart in launchpad, or simply start a forum-thread and post it there?
<rawler> to clarify a bit, I've written a couple of small triggers that sends events to upstart, notifying when network is enabled.. 
<rawler> when each route comes up, when each interface comes up and so on, an event is sent to upstart..
<rawler> on top of that, I've started writing a set of network-service-scripts that uses this info to determine service-status.. I think it might be useful for someone, but I'm not sure where to post?
<rawler> bbl
#upstart 2007-05-05
<jschmerge> hi guys
<jschmerge> is anyone here?
<jschmerge> ping?
#upstart 2007-05-06
<Tinix> is here Md
<AlexExtreme> if you want Md PM him
<Tinix> what lenguage use this channel
* ..[topic/#upstart:ion_] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo | The purpose of this channel is not to be a place to contact Freenode staff. Please keep that in mind, thank you.
<Tinix> ok
<Tinix> I am looking for aid of the staff of freenode 
<Tinix> I lost my password and I want to recover it 
<AlexExtreme> then don't ask here, simple
<AlexExtreme> type /stats p and PM one of the people in that list
<Tinix> I did it and the result is that "Md" belongs to the staff 
<Tinix> thus I ask in this channel for Md 
* ..[topic/#upstart:ion_] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo | The purpose of this channel is not to be a place to contact Freenode staff. Please keep that in mind. If uncertain, please see the definition of not from the dictionary. Have a nice day.
<Tinix> this clear\u2026 this subject 
<Tinix> this clear... this subject 
<Tinix> ok arrivederci stranzate ci vediamo pronto
* AlexExtreme sighs
<mbiebl> ;-)
<Md> sorry, I am implementing a workaround for this
<ion_> Its not your fault. :-)
* ..[topic/#upstart:Md] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo
<Md> now another channel will appear in /who
#upstart 2008-04-28
<RyanPrior> How can I use upstart to control things like apache? Right now I'm using invoke-rc.d but upstart seems like the direction Ubuntu is moving in.
 * rgl waves
<rgl> what is the best way to disable the tty?  edit  /etc/default/console-setup, remove /etc/event.d/tty*, anything else?
<Keybuk> that would work
<rgl> but what is *the way*? :D
<Keybuk> there isn't one yet
<Keybuk> you could edit it and comment out the "start on" line
<rgl> if I remove the tty* files, will htye be recreted after package update?
<Keybuk> no
<Keybuk> (assuming dpkg)
<rgl> ah;  so I'll remove them.  thx :)
<sadmac2> Keybuk: did you see my email?
<Keybuk> sadmac2: err?
<sadmac2> Keybuk: I sent you an email
<sadmac2> Keybuk: did it not make it?
<Keybuk> what was the subject?
<sadmac2> Keybuk: "States as Flags"
<Keybuk> oh, yes, I have that one
<Keybuk> haven't read it yet
<sadmac2> ah.
<wasabi> Keybuk: congrats on the awesomeness. good to see the stuff we talked about finally seeing the light of day
<Keybuk> wasabi: yeah, is good :p
<wasabi> i like how you refined the instance/job stuff.
<Keybuk> that stuff is working rather well now
<wasabi> i love it when ideas like that come together, and you know, if you look hard enough, it can be elegant... and then it is
<Keybuk> there's still a few bits that aren't quite perfect yet
<Keybuk> but I'm hoping they'll clean themselves up over time
<wasabi> im still curious about some of the problems we had with figuring out how to properly track large event sequences
<Keybuk> how do you mean?
<wasabi> oh, like, something that only should be active between the time the network interface is up and when it is about to go down.
<Keybuk> that bit's easy, no?
<Keybuk>   from interface-up
<Keybuk>   until interface-down $IFACE
<wasabi> it's easy, except for when the 'it is up' state can be forgotten, for instance, by manually restarting the event.
<Keybuk> ahh
<Keybuk> yeah, the whole forgotten thing
<wasabi> since it's a state machine that is independent from the system itself.
<wasabi> I have a hunch that it's going to lead to problems... but I'm not sure.
<Keybuk> me neither
<Keybuk> I guess whatever knows the network is up or down knows
<Keybuk> or maybe that doesn't either
<wasabi> So like, you have apache running, it is network-up to network-down.... network-up happens, so apache starts.... but eh user manually restarts apache. state machine is cleared.... now when the network goes down, apache doesn't.
<wasabi> unless the up/down part are independent.
<wasabi> which makes the whole state part not very useful or interesting.
<Keybuk> they're independant
<wasabi> from interface-up until interface-down    ?      that can trigger stop on interface-down without ever triggering interface-up before?
<Keybuk> a more interesting question is, if the sysadmin manually started apache, _should_ it be automatically stopped?
<Keybuk> at the moment, yeah
<wasabi> Yeah. I dunno. I think that in the specific case of apache relying on the network, yeah....
<Keybuk> states is a definite 0.5.x problem
<sadmac2> Keybuk: the email I sent is pertinent to this
<sadmac2> to states rather
<Keybuk> indeed
<sadmac2> and now its lunch time
 * sadmac2 goes for food
<Keybuk> wasabi: I'm pretty sure Upstart is almost as good a service and task manager as it can be now
<Keybuk> which was my goal for 0.5
<wasabi> Yeah. I think so too.
<Keybuk> the next job is to make sure we have the events/states/etc. stuff right
<Keybuk> the only bit I'm not 100% happy with is the blocking of commands
<Keybuk> it's not _quite_ right
<Keybuk> and it's because there's a wimp out
<Keybuk> when you do "start apache HTTPS=true", the HTTPS is not immediately stored in the job environment
<Keybuk> instead it's in the "next environment" which isn't copied over until the job is actually starting
<Keybuk> that way, if you do "stop --no-wait apache && start apache HTTPS=true" to restart with SSL enabled
<Keybuk> the pre-stop and post-stop scripts are run _without_ that variable
<Keybuk> so stop scripts always match start scripts
<Keybuk> _but_ there's only one blocking command
<Keybuk> so if you stop while starting, the start immediately cancels
<Keybuk> and I'm not happy with that
<Keybuk> if the blocking command was queued, that would feel right I think
<Keybuk> but need to think about it
<Keybuk> certainly, if the blocking command was queued, "watershed" jobs would be trivial to implement :p
<Keybuk> nih_list_add (job->next_blocking, &request->entry);
<Keybuk> job->restart = TRUE;
<Keybuk> :p
<wasabi> where's uds at this next time?
<wasabi> as part of my employeement contract i got the owner here to send me to two conferences a year, related or unrelated to what I do at work. =)
<Keybuk> Prague
<wasabi> Oooh.
<Keybuk> in three weeks
<wasabi> Oh. Darn.
<Keybuk> after that it's SF in the first week of December
<wasabi> Man, Prague would be awesome.
<wasabi> Hope ya'll have fun.
<Keybuk> I expect to be busy :(
<Keybuk> going to try and skate around the city though
<Keybuk> what should the D-Bus object path of the only instance of a non-instance job be?
<wasabi> what is it for an instance?
<Keybuk> the name of the instance
<wasabi> job/instance  ?
<wasabi> job
<Keybuk> /com/ubuntu/Upstart/jobs/getty/tty1
<Keybuk> for example
<wasabi> oh. Just leave off the last part of the path
<Keybuk> that's the job though
<wasabi> Oh. Hah.
<wasabi> "default" =)
<ion_> "instance"
<ion_> "amigarules"
<wasabi> i would make up a special name for it, so it's namespace is equiv to instances themselves.
<Keybuk> yeah, some special name
<wasabi> makes enumeration and stuff easier
 * Keybuk is having a very strange valgrind issue at the moment
<Keybuk> it's complaining about reachable data
<Keybuk> which doesn't make sense given the context
<Keybuk> the pointer is reachable by a *far* bigger block it's not complaining about
<Keybuk> \o/
<Keybuk> http://bioshock.netsplit.com/~scott/yay-dbus.png
<ion_> :-)
<ion_> Did you manage to resolve the valgrind issue?
<ion_> keybuk: Hilight
<Keybuk> ion_: no
<Keybuk> I just suppressed it
<Keybuk> it errors that the dbus path is still reachable
<Keybuk> (ie. not freed)
<Keybuk> but it's reachable by an even bigger object that's not freed
<Keybuk> which is reachable by the hash table of objects that aren't freed
<Keybuk> so I don't quite see why it's complaining about the bit at the bottom of the stack
<ion_> Heh
<ion_> It's understandable â it's not as if computers are deterministic machines. :-)
<Keybuk> if I change the "complicated" function call with nih_sprintf
<Keybuk> it's fine
<Keybuk> the only different that I can tell is that one uses malloc() and the other realloc()
<wasabi> So... does upstart have aspirations to be in other distros? Or is that a concern you don't care to think about?
<wasabi> Oh, guess it doesn't matter. We have com.redhat crap in there too
#upstart 2008-04-29
<ion_> It's just a namespace.
<Keybuk> right, it's just namespacing
<Keybuk> you might as well say that Fedora would never import com.sun.* in Java
<ion_> Well, i for one wouldn't. :-)
<Keybuk> you know what I mean ;)
<ion_> To be accurate, i wouldn't ever touch Java. ;-) </flame>
 * Keybuk idly considers refactoring
<Keybuk> http://bioshock.netsplit.com/~scott/codelinks.svg
<ion_> Hehe
<sadmac2> Keybuk: http://blueballfixed.ytmnd.com/
<Keybuk> heh
<sadmac2> Keybuk: Fedora 9 will be out on the 13th. Assuming we build upstart trunk on that date and start working with it, what do you expect we'll be getting?
<Keybuk> on that date, you _should_ be able to just build the 0.5.0 release
<sadmac2> cool. We're close then :)
<Keybuk> it'll be +/- a few days from that
<sadmac2> Very nice.
<sadmac2> it looks like over the summer I'll be employed full time to work on upstart
<sadmac2> :)
<ion_> Nice :-)
<Keybuk> cool :-)
<Keybuk> you should really beg RH to send you to Prague ;)
<Keybuk> or failing that, at least GUADEC
<ion_> Prague?
<Keybuk> ion_: UDS
<ion_> Ah
<sadmac2> Keybuk: I have been. The departments are playing a game of "my budget is tighter than yours" that it looks like everyone might win.
<sadmac2> :(
<sadmac2> If everyone still wanted US Dollars I'd probably be as good as there by now.
<sadmac2> stupid currency
<Keybuk> where abouts in the US are you OOI?
<sadmac2> Keybuk: I'm in Raleigh, NC (east coast). I go to NCSU, and Red Hat HQ is right here on campus.
<Keybuk> ah right
<Keybuk> that's a long way from Lexington, MA :)
<Keybuk> (thinking of places I can justify Canonical paying for me to fly to <g>)
<sadmac2> Keybuk: our currency's devaluation does not apply within our own borders. So US to US trips I might be able to get done.
<Keybuk> I'll certainly raise the possibility
<sadmac2> Keybuk: I am likely going to have to give a talk at FUDCon Boston this summer on Upstart. It'd be handy to have you there.
<sadmac2> Keybuk: its concurrent with the Red Hat Summit, so there's a lot of linux in that part of the world at that time.
<Keybuk> I may be able to justify that
<Keybuk> is it just that week?
<sadmac2> Keybuk: June 19-23
<Keybuk> ok
<sadmac2> make that 19-21
<sadmac2> (they're short)
<Keybuk> MA is relatively easy to justify since we have offices there
<Keybuk> so I can combine it with a visit
<Keybuk> TX is easy since I can swing by Dell, CA is easy since I can swing by Google, etc.
<sadmac2> cool
<sadmac2> and now I go take an exam
<Keybuk> good luck
<sadmac2> thanks
#upstart 2008-04-30
<Keybuk>  37 files changed, 6790 insertions(+), 6221 deletions(-)
<Keybuk> ..ooops..
<ion_> Heh
#upstart 2008-05-01
 * Keybuk makes the push from hell
<Keybuk> holy timing
<Keybuk> I pushed, then LP went away
<ion_> Itâs as if millions of voices suddenly cried out in terror and were suddenly silenced.
<mbiebl> hehe
<Keybuk> mmm, force
<Keybuk> </blue harvest>
<Keybuk> ion_: you may notice that the tree has moved around a bit if you pull ;)
<ion_> Heh, so it seems.
<wasabi> Keybuk: I'm still unhappy with the idea of nfs-server having content in portmaps' job file.
<wasabi> I just cann't imagine how packagers will deal with it.
 * cwillu_ feels the need to club an upstart developer, but prior experience has shown it's usually his own damn fault.
<cwillu_> so, is there any reason why 'start on started <other job name found in /etc/event.d>' doesn't do what I expect?
<cwillu_> I can start job1, but I can't seem to make job2 start when job1 is startedf
<cwillu_> (both are running as respawn; exec)
#upstart 2008-05-02
<sadmac2> Keybuk: how's the code?
<Keybuk> sadmac2: finished the refactoring
<Keybuk> just got to finish d-bus stuff
<sadmac2> very nice
<wasabi> <wasabi> Keybuk: I'm still unhappy with the idea of nfs-server having content in portmaps' job file.
<wasabi>  I just cann't imagine how packagers will deal with it.
<wasabi> Make my fears go away!
<ion_> Are they just additions or larger changes?
<Keybuk> well, it does anyway, since it needs to be in the portmap maps file
<Keybuk> portmap is _really_ the only example of this kind of job I can think of
<wasabi> It fails with more than one thing depending on portmap, doesn't it?
<ion_> Have update-portmap-job within the portmap package, which combines files from .../portmap/job.d/* to /etc/init/jobs.d/portmap?
<wasabi> You know. I guess it doesn't really matter. Mine as well just run portmap when portmap is installed, period.
<wasabi> And just rely on the package manager to enable/disable it.
<ion_> Or have upstart read /etc/init.d/jobs.d/portmap.d/* as a single job? :-)
<Keybuk> wasabi: why would it fail?
<Keybuk> there _is_ a much more entertaining way to do it
<Keybuk> /etc/init/jobs.d/nfs-server:
<Keybuk>     env REQUIRE_PORTMAP=1
<Keybuk>     export REQUIRE_PORTMAP
<Keybuk> /etc/init/jobs.d/portmap:
<Keybuk>     start on starting REQUIRE_PORTMAP=1
<Keybuk> you don't _have_ to match on the job name ;)
<wasabi> oh that's crazy
<wasabi> dude. that's slick.
<wasabi> though how do you make it stop? :0
<Keybuk> if there's really a large number of jobs that should behave like this, we can codify that
<Keybuk> ie. have a "depends portmap" type syntax
<Keybuk> which adds to the job event environment
<wasabi> oh you could also have portmap's job file keep a ref count.
<wasabi> or something
<Keybuk> yeah
<Keybuk> that'd work with states too
<Keybuk>   state portmap-dependency
<Keybuk>       from starting REQUIRE_PORTMAP=1
<wasabi> start could increment the count, and run the daemon. pre-stop could decrement it and only allow stopping when it hits 0
<Keybuk>       until stopped $JOB
<Keybuk>   end state
<Keybuk> then portmap would have
<Keybuk>   while portmap-dependency
<Keybuk> (theoretical)
<wasabi> that is intriguing. i have yet to read about states.
<Keybuk> I've yet to invent them properly
<Keybuk> you and I did the ground work back in SF
<wasabi> I remember that much
<Keybuk> over very hot thai
<wasabi> The next morning was not pleasant.
<Keybuk> when I realised that upstart's design allows it to do dependency-based init with _no_ special contortions, I knew we'd reached elegance
<Keybuk> events can be used to emulate them just fine
<wasabi> design nirvana.
<ion_> A bit like doing sequential code with side-effects using monads in a functional programming language. Good, clean architecture that doesn't restrict your choices when you need to have something the worse architecture does well. :-)
<sadmac2> Keybuk: get a chance to look at that email I sent?
<Keybuk> not yet
<Keybuk> this week is performance review week
<Keybuk> and UDS planning
<sadmac2> Ahh
<Keybuk> and I wanted to get 0.5.0 out before worrying too much about what comes after ;)
<Keybuk> I'm stuck in a hotel in london next week, so bar going out skating, I'll have plenty of time to code that and reply to mails :)
<sadmac2> sweet
<sadmac2> what's still loose in the dbus code?
<Keybuk> just the writing of the functions now
<Keybuk> it registers the objects on the bus
<Keybuk> and maintains a connection to the bus, dropping it and reopening when necessary
<Keybuk> so just need to write the actual methods ;)
<sadmac2> heh. cool
<ion_> So Upstart will be the first program ever not to crap itself when dbus goes for a short walk? :-)
<wasabi> You writing the dbus integrating in pid 1?
<Keybuk> wasabi: yeah
<wasabi> scary.
<wasabi> linking to libdbus?
<ion_> Scary?
<Keybuk> wasabi: yup
<wasabi> That sounds frightening for some reason.
<ion_> Frightening?
<wasabi> Uh huh. Just ot have that much complexity in pid 1.
<ion_> Well, for it to talk with other processes, there must be *some* implementation of *some* protocol anyway in pid 1. :-)
<Keybuk> wasabi: libdbus is nice enough
<Keybuk> having our own ipc implementation was scarier, since it's not as audited
<wasabi> It might scare people who don't want dbus on their systems (server installs)
<ion_> Do you mean dbus-the-protocol or dbus-the-daemon?
<wasabi> I have no practical claims. Only political claims.
<Keybuk> wasabi: those people won't get a choice?
<wasabi> Well, is libdbus.so required?
<Keybuk> yes
<AlexExtreme> libdbus.so? surely it would be safer to statically link /sbin/init to libdbus.a rather than use the shared library?
<Keybuk> why safer?
<Keybuk> shared libraries are safer since they can be updated for security updates
<AlexExtreme> Keybuk: libdbus upgrade, .so version changes (e.g. from .so.3 to .so.4), upstart package isn't upgraded, reboot, *won't boot because of missing lib*
<Keybuk> that's what we have package managers for
<Keybuk> upstart would depend on libdbus3 and so libdbus.so.3 would be still installed
<Keybuk> while libdbus4 containing libdbus.so.4 would be used by the other apps
<ion_> Yeah, soname bumps never break anything.
<AlexExtreme> but then again I'm speaking from my experience in a smaller distro where maintainers didn't get dependencies right and sometimes forgot to rebuild packages :)
<Keybuk> happily dbus isn't due for a soname change
<ion_> It's not their job to get the dependencies right, the packaging tools make the shlibdeps.
<Keybuk> and if it were, it's maintainers have very very carefully made sure it would not be a problem
<Keybuk> even the include files are parallel installable
<AlexExtreme> ion_: debian's packaging tools may do that, pacman's packaging tools don't
<ion_> alexextreme: Just copy the functionality from $other_distro. :-)
<AlexExtreme> hah
<sadmac2> that was interesting
<ion_> alexextreme: Well, nothing prevents you from linking statically, it's just safer the other way. :-)
<suihkulokki> the main worry of linking external libraries to process runnning pid 1, is that pid 1 should never ever crash
<suihkulokki> so one needs to be sure the libraries linked to are rock solid
<suihkulokki> and aren't built on assumptations like "it's ok to crash if malloc() fails"
<Keybuk> suihkulokki: see also, Why Keybuk Does Not Like GLib :)
<Keybuk> the only doofus assumption in libdbus was that it could call exit() if the connection to the bus was dropped
<Keybuk> and that was at least an option
<Keybuk> (but the code that set the option for bus connection was in the wrong place, which I had to fix)
<wasabi> I think limiting scope of exposure is important. If every libdbus version upgrade is vetted by a team of trained professionals before being deployed, so as not to break upstart, then it's good.
<wasabi> But I think in reality that does not happen, and it could break.
<wasabi> Hence you'd limit scope in order to reduce the maintenance burden on the maintainer. upstart is super critical.
<Keybuk> not so much
<Keybuk> if every Upstart upgrade was vetted by the team of trained professionals
<Keybuk> who carefully read through my IPC codfe
<Keybuk> then I might feel happy ;)
<Keybuk> since they don't, using a shared IPC protocol that has had more eyes over it is better
<ion_> ...or just switch to a language that simply won't have any buffer overflows or stuff like that. :-)
<Keybuk> then I'd have to put my faith into that language interpreter
<Keybuk> and they really don't tend to be great ;)
<ion_> :-)
<Keybuk> D-Bus over homebrew IPC is compelling for several reasons
<Keybuk> 1) security - D-Bus is used more widely and has had more people look at the code, including NSA verification, it's less likely to have extant security flaws than the homebrew
<Keybuk> 2) response to flaws when they are found - D-Bus has active maintainership, when flaws are found the response will be rapid and a matter of replacing the library
<Keybuk> 3) maintainability - homebrew IPC is a bitch to maintain, and touches lots of areas of UNIX that are unpleasant ;)
<Keybuk>    much better to let someone else worry about those issues
<Keybuk> 4) compatibility - there are already bindings for d-bus in most languages, and it's well known
<Keybuk>    means more people will write software that talks to upstart
<ion_> (I actually didn't mean an interpreted language, but the same of course applies to higher-level language compilers.)
<Keybuk> 5) authentication - D-Bus already solved the authentication issues for individual connections *and* for messages
<Keybuk> ion_: are there higher level compilers that remove the risk of buffer overflows?
<ion_> As i said, the same (what you mentioned) applies to them. :-)
<Keybuk> well, that and they don't exist? :p
<Keybuk> I'm not writing Upstart in Pascal <g>
<ion_> I've been trying to study Haskell recently with great interest, incidentally.
<ion_> The more bits and pieces about it i get into my blob of grey matter, the more awesome it seems. :-)
<ion_> Still, i have no idea whether the compiler (well, the glasgow compiler in this case, probably) contains bugs that could lead to security holes.
<Keybuk> hmm, Haskell
<Keybuk> that's basically writing in spreadsheets isn't it? :)
<ion_> Well, something like that. :-P
<Keybuk> I've yet to see someone implement something useful in Haskell that doesn't have very very scary end-of-the-universe problems
<ion_> end-of-the-universe? :-)
<Keybuk> as in, there's no point the program saying "Please wait"
<Keybuk> it won't be done before you are
<ion_> Sorry, i don't see what you mean.
<Keybuk> that it's easy to write programs that have very difficult upper bounds
<Keybuk> and can end up stuck resolving their next course of action
<Keybuk> they do complete
<Keybuk> but it can, in extreme cases, be calculated to require billions of years
<ion_> Oh, ok
<Amaranth> you could use ada :P
#upstart 2008-05-03
<Keybuk> Ajax is far too much fun
<ion_> keybuk: Yeah, as long as you abstract the annoyances away with something like prototype.js
<rgl> hi
<rgl> I'm running ubuntu 8.04 and want to create an apache upstart job;  but where should I put it?   inside /etc/event.d/ ?
<ion_> Well, yeah, but isn't the init script that comes with apache enough for now?
<rgl> I want to use upstart *G*
<rgl> and its much simplier that the one shipped with apache, take a look: http://dpaste.com/48108/
<rgl> is there a way to rename the child name that appears on top ?
#upstart 2010-05-03
<erUSUL> i've did not noticed before but someone asked in #ubuntu. does upstart save fsck logs ? is it its job to begin with ? 
<JanC> erUSUL: it's certainly not upstart's job to log any program's output, although in some cases upstart .conf files might contain the instructions for logging something (but that's up to who writes those scripts)
<erUSUL> JanC: i ask becouse /var/log/fsck/ seems to not be updated anymore in ubuntu
<erUSUL> just noticed today becouse someone asked
<erUSUL> -rw-r----- 1 root adm 195 2009-11-18 15:05 /var/log/fsck/checkroot
<JanC> erUSUL: so that would be an ubuntu-specific question then (also, maybe it's logged elsewhere?)
<erUSUL> well upstart is an ubuntu development/project ... that's why i'm asking here. but yes i coud do a bug report against ubuntu. thanks
<erUSUL> tyvm for your time
<JanC> erUSUL: it's just that I get the feeling that this channel is mostly used by upstart-developers, packagers, or other peopel who want to write their own upstart scripts
<erUSUL> fair enough
<JanC> erUSUL: I suppose that on Ubuntu fsck during boot is started by mountall (which might not be used by other distros)
<erUSUL> ohhh; thanks... then that's the thing i should complain about. much apreciated.
<erUSUL> FWIW it was already reported https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/513644
<erUSUL> thanks again JanC 
<JanC> erUSUL: see boot.log 
<JanC> in /var/log/
<erUSUL> i do not have that file 
#upstart 2010-05-04
<mgoetze> Keybuk: it seems like upstart on lucid brings up interfaces before udev has had a chance to rename them :(
<notting> Keybuk: you mentioned at one point you avoid busy inodes by re-execing upstart on shutdown. yet you removed the handler that accomplished that :)
<notting> how are you doing it now?
<conda> im getting this error when trying to manually run an upstart job:
<conda> start: Rejected send message, 1 matched rules; type="method_call", sender=":1.44" (uid=1000 pid=2632 comm="start) interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply=0 destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init"))
#upstart 2010-05-05
<iceage2098> I don't know why cron doesn't work after updating to ubuntu 10.04. I think there's a bug in upstart? anyone can help me? upstart version is 0.6.5-6
<lbt> hi... with upstart do you have to teach other services about your service? ..... eg autofs needs statd. statd says "start on (started portmap or mounting TYPE=nfs)" which I assume needs to go to "start on (started portmap or started autofs or mounting TYPE=nfs)"
<lbt> or is there a way to reverse that mapping into "autofs depends on statd"
<mgoetze> is there a way to get useful debug output from upstart-udev-bridge? (-v hasn't told me anything yet)
#upstart 2010-05-06
<markolya> Hi
<markolya> I have ubuntu 10.04 on a server and experience pretty strange upstart behaviour
<markolya> I have my own service config and it seems that whenever I do stop/start command just hangs until ctrl-c
<markolya> even if I copy/paste known-to-work config there, like cron
<markolya> moreover, if I save this service under different name it seems to work
<markolya> I wasn't able to find any references to such issue
<markolya> deleting service file doesn't help
<sadmac> markolya: man 5 init, look at the expect stanza
<markolya> thanks for the answer
<markolya> I actually did look at it
<sadmac> markolya: actually, that's not entirely consistent with the renaming thing..
<sadmac> markolya: hmm
<sadmac> markolya: what name?
<markolya> yes
<markolya> "kittens", if this matters
<sadmac> but it works with other names?
<markolya> basically I take contents of cron.conf, write it to kittens.conf and start kittens hangs
<markolya> if I write it to kittens1.conf it doesn't hang
<markolya> I mean start kittens1 doesn't hang
<sadmac> that's strange
<sadmac> in fact I have no explanation
<markolya> it actually wasn't like this when I started yesterday
<markolya> I think some of my changes to conf file brought it to such state...
<sadmac> markolya: have you tried rebooting? maybe upstart is retaining some sort of state around the name "kittens"
<sadmac> yeah
<markolya> I do not really want to reboot this machine
<markolya> it looks like that it is retaining some sort of state
<sadmac> yeah.
<sadmac> not a lot of ways to clear that unfortunately
<markolya> I was just thing that while I have this state I can provide some information to original author since it looks like a bug
<sadmac> its semi-well-known. The exact cause isn't certain but the preferred fix is a redesign of that portion of the code, so I don't think we need it much narrower
<markolya> hmm... ok... is there any bug on launchpad for this so I could see changes on it and try fixes when they are released?
<sadmac> not sure.
<markolya> sorry, I'm new here... are you Scott James Remnant?
<sadmac> markolya: no. Keybuk is. He's not on now
<markolya> oh, thanks
<markolya> I'll probably continue using rc.d for now, thanks for your help!
#upstart 2010-05-07
<tstone> hi, i have just added upstart to ptxdist. The problem is that dbus is running but not responing to any connection any more?! I only change the init method...
<pgmcgee> hey guys, im having issues with writing an upstart script for nginx, nginx starts up fine, but the pid upstart gets for nginx is wrong and so i can't stop or restart it
<soren> Did you try "expect daemon"?
<soren> pgmcgee: ^
<soren> pgmcgee: See the init(5) man page for details.
<soren> pgmcgee: Ah, make that "expect fork", apparantly:
<soren> http://cyruslopez.net/writing/upstart.html
<pgmcgee> soren: i did try expect fork... hmm
<soren> Try expect daemon then.
 * soren wanders off
<pgmcgee> soren: yep, trying that now
<pgmcgee> hmm.. on expect daemon, the start and stop commands just hang (don't give any output and don't exit) and nginx keeps running even on stop
<halfline> sadmac: if i have one thing that does "stop on starting runlevel" and one thing that does "start on runlevel"
<halfline> sadmac: the stop on starting runlevel job should be synchronously stopped before the start on runlevel job is run right?
<sadmac> halfline: runlevel is an event, not a job (in fedora's stack anyway) so there is no starting runlevel
<halfline> sadmac: oh, there's no way to trigger on the edge before the level? 
<sadmac> halfline: try working relative to the rc job rather than the runlevel event
<halfline> sadmac: basically i need prefdm.conf to finish completely before runlevel 5's rc scripts start shutting down
<sadmac> halfline: start on starting rc
<halfline> so you saying "stop on starting rc" ?
<sadmac> yeah
<halfline> sadmac: so if i do that
<halfline> sadmac: and then do "start on stopped prefdm" for a task
<halfline> will that task get run synchronously before rc is run?
<sadmac> halfline: don't think so. start on stopping prefdm would do that though, but you'd run before prefdm
<sadmac> before prefdm stopped
<halfline> is there a way to hook in after prefdm is stopped before rc is started?
<halfline> can i put in my stopping script some sort of barrier?
<halfline> initctl wait on prefdm stopped  or something?
<sadmac> halfline: start on starting rc and stopped prefdm
<sadmac> halfline: you are tapping into overwhelming evil with that line but it should technically work
<halfline> hmm i guess i need to filter that a bit though
<halfline> start on starting rc RUNLEVEL=0 or RUNLEVEL=6 and stopped prefdm ?
<sadmac> right
<sadmac> well, wrong
<halfline> i can just put an "or" like that?
<sadmac> start on starting rc RUNLEVEL=[06] and...
 * halfline tries
<halfline> hmm seems to just be sitting there instead of rebooting
<sadmac> hmm.
<halfline> http://fpaste.org/mmVo/
<halfline> so prefdm seems to be caught up on stop on startng rc RUNLEVEL=5
<halfline> ohh
<halfline> that should be stop on starting rc RUNLEVEL=[!5]
<sadmac> bingo
<halfline> seems to work
<halfline> thanks
<halfline> sadmac: hmm
<halfline> sadmac: so if i boot into runlevel 3 and type reboot things go awry
<halfline> it's just sitting there
<halfline> http://fpaste.org/SfYh/
<halfline> sadmac: could it be stop on starting rc RUNLEVEL=[!5] is cuasing problems if prefdm is already stopped?
<halfline> (that line is in prefdm.conf)
<sadmac> halfline: no, should be fine
<halfline> hmm if i do "start prefdm"
<halfline> and then type reboot again
<sadmac> its the and line thats creating the problem when prefdm is already stopped
<halfline> it reboots
<sadmac> halfline: I have to run out though. bbiab
<halfline> k
<JayT> Is hwclock startup script necessary for an Ubuntu system to boot? if my RTC is screwed (perhaps because of a dead CMOS battery), can I do 'update-rc.d -f hwclock remove' (and the same for hwclockfirst), install ntp, set it up, and reboot?
<JayT> on hardy that is
<JanC> JayT: that sounds like an Ubuntu question, and not an upstart question  ;)
#upstart 2011-05-02
<wraiden> any core upstart developer here?
<SpamapS> wraiden: you should just ask your question.. somebody smart enough to answer should be on sometime today. :)
<wraiden> i'll write an email to the list and are allready up to implement the things i wanted to get opinions on...
<wraiden> i need to set the signal that is uses to stop the exec job ...
<wraiden> for slapd (openldap)
<wraiden> it needs sigint and will eat the directory-database if it gets stopped by sigterm or sigkill...
<wraiden> i'll implement a stopsignal stanza ...
<wraiden> default value for it is term
<wraiden> but can get be set int, usr1 or usr2 also
<SpamapS> wraiden: right, in that case, pre-stop is needed
<wraiden> pre-stop ?
<SpamapS> no need for a new stanza
<SpamapS> send your sigint in pre-stop
<SpamapS> and wait for slapd to shutdown, then TERM will never be sent
<wraiden> ah
<wraiden> and upstart will supervise the slapd pid and will not respawn it?
<SpamapS> There is an open bug against upstart to provide custom actions, so that reload could be changed from HUP to USR1 or something like that
<wraiden> jepp
<SpamapS> yes, at that point, the job's goal will be "stop"
<SpamapS> so no respawn takes case
<wraiden> i plan to implement that also
<SpamapS> takes place
<wraiden> but that needs a change in initctl to hand over the actual signal sending to the job to upstart itself
<wraiden> initctl doesn't parse the job configs so there is no way to change the behavior without that...
<SpamapS> I'm not sure the best way to spin and wait for it to die.. its not pretty but just watching status would work I *think*
<wraiden> mhm
<wraiden> i'll go and test that ...
<wraiden> btw: the stopsignal stanza is a rally low hanging fruit
<wraiden> *really
<wraiden> ot: is the copyright / legal stuff still needed to contribute to upstart?
<SpamapS> wraiden: not OT at all, but its not clear either. ;)
<SpamapS> wraiden: stopsignal seems rather.. coarse. I'm thinking Keybuk will prefer something a bit more elegant. Like  'action stop signal INT' rather than 'stopsignal'
<wraiden> i've implemented "oom score value" support (patch is on mailinglist) so thats no problem as im familar with the stanza parsing now ... :)
<wraiden> an rfc mail for scott to read is also out to the mailinglist ... i'll wait until he has time to respond to it...
<wraiden> *reguarding the stopsignal stuff
<wraiden> anyway, time to go home for me now... bye
<wraiden> and thanks for your hint with the pre-stop hack for slapd :)
<wraiden> hello again...
<Keybuk> wraiden: hi
<JanC> wraiden: I think Keybuk doesn't require copyright/legal stuff since yesterday anymore, but best he answers that himself  ;)
<wraiden> @ keybuk: Mailinglist...
<JanC> ah, you asked there too
<Keybuk> wraiden: you have a question?
<wraiden> in the mail ...
<Keybuk> sorry, I don't have lots of this channel, so am missing context
 * wraiden == Marc
<Keybuk> ah, hi!
 * Keybuk = Scott
<wraiden> :)
<Keybuk> I did just reply to your mail
<Keybuk> wraiden: did you want to follow up on the copyright assignment bit? it seems there is a confusion there from JanC's comment
<wraiden> mhm, if it's not needed anymore...
<Keybuk> so let me clarify
<wraiden> JanC was in the channel before i made my way back home from work and i asked it here ...
<Keybuk> Canonical Ltd require Copyright Assignment for projects under their stewardship
<wraiden> so i think JanC yust wanted to let me know
<Keybuk> since I was employed by Canonical Ltd for the past seven years, that policy applied to Upstart too
<Keybuk> however I left Canonical in January, and now work for Google Inc, who do not require copyright assignment
<Keybuk> so the 1.0, 1.1 and 1.2 releases have contained patches for which copyright was not assigned by the authors
<Keybuk> including myself, and google
<wraiden> ah, ok, they allowed you to take the project with you?!
<Keybuk> they released the project under the GPL
<wraiden> german law is crazy about such things...
<wraiden> jeah
<wraiden> but the copyright...
<Keybuk> they don't need to have "allowed" me
<wraiden> ok
<wraiden> the GPL is clear on that
<wraiden> ok
<Keybuk> so I continue to maintain Upstart
<Keybuk> for the past six weeks, I was in discussions with Canonical about an appropriate way forward
<Keybuk> but we had agreed a time limit (end of April) for those, and that was reached without an agreement
<Keybuk> so things revert back to Upstart continues as a GPL project without any form of assignment
<Keybuk> (one of the options was a relicense to Apache 2.0 so Canonical could continue to release private versions)
<wraiden> good to hear that
<Keybuk> so yeah, don't worry about it ;-)
<wraiden> some of Lennarts FUD blogpost doesn't state the right information than...
<Keybuk> *shock*
<wraiden> pretty onesided function mentioning in his post as he doesn't looks out of his sandbox and just looks what of systemds functions were implemented in other inits...
<wraiden> *writing kill signal code*
<Keybuk> it's Lennart, I would expect nothing less
<wraiden> yeah
<wraiden> got that impression the day he introduced his audio stuff to gnome...
<JanC> pulseaudio is mostly useful (now)  âº
<wraiden> yeah, now...
<wraiden> first hack send to list now
<wraiden> got rid of the signal == 0 then send sigkill as its clearer to just send SIGKILL as param in system_send_signal...
<wraiden> *reading on xen-devel list*
<wraiden> testsuite errors on my system on this:
<wraiden> ...with error after modification of job
<wraiden> BAD: wrong value for file, expected (nil) got 0xeb2a10
<wraiden>         at tests/test_conf.c:709 (test_source_reload_job_dir).
<wraiden> FAIL: test_conf
<wraiden> expected?
<wraiden> it's totaly unrelated to my changes as i tested an upstream version and get the error there also...
 * wraiden goes and gets som sleep...
<wraiden> ... updated patch is out to the list now...
#upstart 2011-05-03
<twb> I told libvirtd that its sockets should be grouped by a group that comes from LDAP
<twb> Unfortunately, libvirtd fails to start now because "runlevel 2" triggers before DHCP has finished coming up, so LDAP isn't available.
<twb> What's the *right* way to tell libvirtd to wait until DHCP is done?
<twb> This is in ubuntu 10.04, if that matters.
 * twb guesses net-device-up IFACE!=lo is the filthy hack that everyone uses
<twb> Nope, that doesn't work.  It comes up on eth0's state being up, rather than DHCP finishing -- I think.
<SpamapS> twb: In Oneiric we'll be changing runlevel 2 to go after ifup -a has returned
<twb> Good, I guess
<SpamapS> twb: so I think if you change /etc/init/rc-sysinit.conf to 'start on filesystem and started networking' it should work.. or maybe 'stopped networking'
<twb> obviously dhclient will background itself if it takes too long, but I'm prepared to live with 'stuff breaks" in that case
<twb> SpamapS: I've spent an hour or two on this, so I'm giving up and just adding a dhclient exit hook that chgrps
<SpamapS> oh you need libvirt to go after dynamic interfaces..
<SpamapS> start on net-device-up IFACE=ethX
<twb> I tried net-device-up IFACE!=lo and it didn't work
<SpamapS> the only reason that shouldn't work is that you have multiple interfaces
<twb> It still tried to bring it up immediately before dhclient
<SpamapS> do you have a physical, static interface maybe?
<twb> Ah, you're right, I am still bringing up the second interface
<twb> But then why isn't it trying to bring libvirt-bin up AGAIN when the dhcp interface comes up?
<twb> http://paste.debian.net/115826/ <-- interfaces, FYI
<SpamapS> i want to add another event which is "all of the automatic interfaces are up" .. meaning all static, and all network-manager interfaces
<twb> FWIW this is a server, so no NM
<SpamapS> probably because it was in a goal of "start" but just thrashing, respawning
<twb> I will try specifying a specific iface
<SpamapS> even w/o nm you have dhclient backgrounding itself
<twb> SpamapS: nod
<twb> 15:46 <twb> obviously dhclient will background itself if it takes too long, but I'm prepared to live with 'stuff breaks" in that case
<SpamapS> The question of "what are all of the automatic interfaces that we know about?" can be answered very easily.. once thats known.. we can trigger something to emit an event whenever all of those are up.
<twb> I even tried "start on remote-filesystems", but that didn't work
<twb> I assumed it would because mountall would send that after it finished mounting NFS
<SpamapS> it most certainly does
<SpamapS> IIRC it sends it when there are no remote filesystems.
<twb> I do have NFS filesystems
<SpamapS> And sometimes NFS isn't a "remote" filesystem.
<twb> as a client, I mean, not a server
<twb> omega:/home    /home    nfs intr,bg
<twb> omega's a remote host, "omega" won't even resolve until DHCP is done
<twb> OK, net-device-up IFACE=br-unmanaged seemed to work
<twb> Thanks
<twb> And sorry for losing my temper
<SpamapS> Meh.. it does that. We need to put some fences around it.
<SpamapS> also to be fair, your temper did not bleed through into IRC.. which is amazing.. usually an oz. of real temper becomes several metric tons of flames in the brain->keyboard->internet conversion process
<twb> SpamapS: you aren't seeing the worst of it
<SpamapS> twb: well I'm nodding off quite a bit.. need to either get caffeine or a pillow. :)
<twb> No worries
<dcorbin_wk> I want to write an upstart script for my service.  It should only start after certain old-style (init.d) scripts have run.  Do have to manually modify them to trigger upstart events?
<SpamapS> dcorbin_wk: there are two ways to handle that..
<SpamapS> dcorbin_wk: the best way would be to port those init.d scripts to upstart as well
<SpamapS> dcorbin_wk: but if thats not possible, you can definitely add calls to 'initctl emit' to the init.d scripts that will help signal to your upstart job that its time to run
<JanC> some services also provide "hooks" of course
<Md> how can I debug why an ubuntu system with upstart hangs at boot? only plymouth and mountall are running
<mbiebl> Md: you can use the --debug boot option
<mbiebl> but I guess your problem is mountall related
<Md> I did, but it did not help
<Md> I have an open console and initctl list reports that plymouth and mountall are the only jobs running
<mbiebl> do you have a special setup, like lvm, cryptsetup or something like this?
<Md> no. actually this is the server of a customer
<Md> he fucked up something while upgrading and asked us to install the last backup. which now does not work
<Md> so for all I know the server could have been broken earlier, but I do not know where else to look
<Md> mountall is just sitting there
<mbiebl> I've seen something like that
<mbiebl> a partition was defined in fstab
<mbiebl> but the actual device was no longer attached to the server
<Md> indeed that was it
<Md> the swap partition now has a new uuid
<mbiebl> and mountall was just sitting there waititing for the device to turn up
<Md> this is fucking unbelievably stupid
<mbiebl> yeah, I lost a ec2 instance that way
<mbiebl> I cursed a whole day
<mbiebl> I hope you have (physical) access to fixup the fstab
<mbiebl> Md: that was some time ago, iirc a karmic installation. not sure if mountall is more clever nowadays and has timeouts 
<dcorbin_wk> SpamapS: thanks.  I'm the init.d scripts are part of common ubuntu packages.  Minimal changes are preferred.
<SpamapS> dcorbin_wk: on the contrary, we'd love to have things converted to upstart jobs. :)
<dcorbin_wk> SpamapS: well, of course.  but this is "old ubuntu", well off of 'head'
#upstart 2011-05-04
<karshan> hey
<karshan> i'm looking for a way to get an upstart script running on shutdown, the only way I can seem to do it is with a "start on runlevel 0"
<karshan> is there no analog event to startup in upstart ?
<JanC> karshan: I thin kthat currently there is none
<karshan> oh ok.. thanks. you know about any plans of removing the sysv legacy stuff like runlevels or is upstart gonna keep them
<JanC> karshan: technically, the runlevel stuff isn't part of upstart
<karshan> well i mean the runlevel events and the stuff in util/sysv.c etc.
<JanC> some people (especially in the embedded space) don't use any of that
<karshan> yeah I guess. I was just confused since all /sbin/shutdown does is set the runlevel to 0 and let out an event, it expects some sctript to run /sbin/halt on runlevel 0.
<JanC> 'shutdown' is part of the sysv compatibility tools IIRC  ;)
<karshan> ahh. yes ofcourse
<karshan> I still think there should be a shutdown event (not runlevel 0) though, so when something like reboot is executed all jobs are stopped etc.
<JanC> karshan: in general, upstart will just stop all jobs if you do that
<karshan> JanC: well what about tasks that need to be carried out like unmounting the filesystems
<JanC> karshan: you can use whatever event you want for that?
<JanC> the thing with upstart is that it's very generic
<karshan> but how do i get the event generated at shutdown
<JanC> which is an advantage and a disadvantage
<karshan> i.e. without putting an "inttctl emit shutdown" in the stop script of some random job
<JanC> karshan: that's exactly what you want to do  ;)
<JanC> actually, put it into the utility/script that starts shutdown
<karshan> yeah that makes more sense
<karshan> thats what I was saying though
<JanC> and whatever name you give it is your choice
<karshan> shutdown, or since thats sysv legacy, reboot should have something like that
<karshan> i mean in reboot.c, there should be some code to emit a shutdown event, since it seems pretty useful, most systems would have scripts running on shutdown no ?
<JanC> it might be useful to add an example reboot which does that
<karshan> yeah
<JanC> for those who want to set up a system without syv compatibility
<JanC> sysv
<JanC> (I'm not sure if one exists)
<karshan> mm hmm.. you think its worth posting the code to the mailing list, see if it gets included maybe
<JanC> Keybuk: ^^^
<JanC> karshan: in any case, aking on the ML doesn't hurt  ;)
<JanC> asking
<JanC> currently most people seem to thing upstart is only upstart + sysv-compatibility as used in Ubuntu
<karshan> yeah, so i've seen, it took me a while to find any scripts that had nothing to do with sysv compatibility
<JanC> I expect Google's Chrome OS uses it differently
<JanC> and the embedded users, but those might not always be public
<JanC> or more difficult to find
<karshan> yeah.. i'm building an lfs system, and i didnt want any sysv init stuff, so hopefully i'll have a nice set of upstart scripts legacy free by the end of it
<JanC> karshan: in that case you can offer them to the project
<karshan> yup :)
<JanC> even if only to put them into an "examples" or "contrib" directory
<Keybuk> hey was at the gym
<JanC> Keybuk: karshan thinks it would be nice to include examples for a non-sysv-compatible system
<Keybuk> JanC, karshan: right, the reason there's no non-SyS V shutdown event is because the people using Upstart without the SysV stuff are largely in the embedded space
<Keybuk> and for them "poweroff -f" is pretty close
<Keybuk> so it's not been a feature request someone's wanted enough to provide a patch
<dcorbin_wk> How should (can I?) configure certain upstart services to be controllable by non-root users?
<JanC> dcorbin_wk: configure sudo to allow them to execute the necessary commands?
<dcorbin_wk> JanC: the commands are "start" and "stop", right?  can you make sudo only allow certain arguments?
<JanC> yes, see sudoers(5)
<JanC> there are all sorts of examples in it
<dcorbin_wk> OK.  Thanks.
<marrusl> Anyone know...  can you change the shell that upstart uses for scripts without changing the /bin/sh -> dash link?
<SpamapS> marrusl: init/paths.h:#define SHELL "/bin/sh"
<SpamapS> marrusl: tho Keybuk might know another way. ;)
<marrusl> SpamapS, well THAT I'm not going to support.  :-)
<Keybuk> hmm?
<SpamapS> Keybuk: " < marrusl> Anyone know...  can you change the shell that upstart uses for scripts without changing the 
<SpamapS>                  /bin/sh -> dash link?"
<Keybuk> right
<Keybuk> or
<Keybuk> ./configure CPPFLAGS=-DSHELL=/bin/crush
<marrusl> heh.  well thanks SpamapS, Keybuk.  good to know,  it's a weird request.  I don't think they'll care enough to want to roll their own.  :)
<Keybuk> it's the kind of change that's best done at compile time
<marrusl> Keybuk, and they are free to change the link if they'd really like to.  Not that i'm suggesting they do.
<Keybuk> yeah, exactly
<Keybuk> and really, Why?
<marrusl> Keybuk, I'm curious, I didn't hear why yet.  I know they were working on a network startup issue (LP bug: 777193).  they probably added some debug statements that had a bashism in them.  probably wasn't anything more than that.
<radix> I'm trying to get ubuntu working in a vserver... I've got it configured to some extent, where upstart is services properly when it comes up, but after that any start/restart/stop commands I run just block while polling on the connection to init
<radix> is there something I should try to help figure out what's going wrong?
<JanC> radix: there are some instructions about upstart + vserver on the vserver wiki IIRC
<radix> JanC: yeah, and I followed them
<radix> I'm not convinced that whoever wrote them got it fully working, or maybe just some software has changed since then
<radix> they got me to the point that services were starting at boot, but I've always had this blocking problem
<JanC> I have seen people in here who got it working with those instructions
 * JanC has no experience with it though
<Keybuk> if those commands block, you haven't got upstart working in a vserver
<Keybuk> and are probably using some other daemon
<reiddraper> if I have a process that I manage with upstart, and it forks on `reload`, will upstart keep track of it?
<Keybuk> reiddraper: no
<radix> it's definitely upstart, I've straced both init and the commands
<radix> and seen them connecting on @/com/ubuntu/upstart
<reiddraper> Keybuk: is there a workaround?
<radix> could a misbehaving service specification possibly make one of those commands block? 
<JanC> radix: in some cases
<radix> 'strace -f restart cron': http://pastebin.ubuntu.com/603486/        'strace -f -p 1': http://pastebin.ubuntu.com/603487/
<radix> could this perhaps offer some clue about my problem?
<radix> it looks like the processes are at the very least communicating
<radix> and netstat does tell me that process 1 is listening on @/com/ubuntu/upstart, so I assume that means it is actually upstart :)
#upstart 2011-05-05
<radix> for what it's worth, 'stop cron' does actually kill the cron process (as does 'restart cron', though that one doesn't bring it back up)
<radix> so it's communicating enough that it can do its job, but then not cleaning up properly or continuing to further steps, I guess
<radix> for what it's worth, --verbose doesn't seem to write anything when running stop / restart at runtime, though I do see all the console output at first run
<radix> er, at boot
<radix> did anyone get around to looking at those strace outputs I pastebined yesterday?
<steffen_b> hi there
<steffen_b> searching for some helping hand of shutdown 
<steffen_b> with natty 
<steffen_b> + debugging 
<steffen_b> problem is that a handfull of services is not shutdown 
<JanC> define "not shutdown"
<steffen_b> its stopped on runlevel 
<steffen_b> 016
<steffen_b> and i can see until very late in shutdown process normal messages
<steffen_b> of the daemon 
<steffen_b> it doesnt do any shutdown messages 
<steffen_b> stopping plugins
<steffen_b> or anything 
<steffen_b> and late in the boot 
<steffen_b> i get stopped with status 1 
<steffen_b> i.e.
<steffen_b> openbox main process (1273) terminated with status 1
<JanC> I doubt openbox is handled by upstart?
<Keybuk> with that message, I'd say it is
<steffen_b> in my install it is
<steffen_b> i written the job ;) 
<JanC> if you are doing such a customized setup, why use runlevels?
<steffen_b> nice try ;) 
<steffen_b> stop on runlevel [016]
<steffen_b> is openbox also others which look the same
<steffen_b> the system is ubuntu natty , customized 
<JanC> heh
<steffen_b> i dont want to customize everything only the part which we care 
<steffen_b> thats why we base it on ubuntu 
<steffen_b> i put a test job in to see if the runlevel come 
<steffen_b> and that one is executed fine
<JanC> is X also started by upstart?
<steffen_b> the openbox job starts X 
<steffen_b> xinit openbox basically
<JanC> so it's probably X that exits with status 1 ?
<steffen_b> i dont debug that one job 
<steffen_b> its maybe 10 
<steffen_b> all show the same behaviour 
<steffen_b> all working fine on lucid
<JanC> did you check the PID is actually correct?
<steffen_b> believe me the jobs are working 
<steffen_b> May  5 19:12:47 vdr init: plymouth-stop pre-start process (1269) terminated with status 1
<steffen_b> May  5 19:12:47 vdr init: plymouth-splash main process (1328) terminated with status 1
<steffen_b> May  5 19:39:45 vdr init: vdr-frontend main process (1437) terminated with status 143
<steffen_b> May  5 19:39:45 vdr init: udisks-automounter main process (1594) terminated with status 143
<steffen_b> May  5 19:39:45 vdr init: plymouth-upstart-bridge main process (2186) terminated with status 1
<steffen_b> May  5 19:39:45 vdr init: irexec main process (2245) terminated with status 1
<steffen_b> this terminated with status 1 doesnt look normal 
<steffen_b> and is also not happening each boot 
<steffen_b> so something strange is happening in the shutdown 
<JanC> doesn't seem to happen on a "normal" natty system either?
<steffen_b> looks like something in the shutdown is killing the jobs while they are active 
<steffen_b> May  5 19:39:45 vdr init: irexec main process (2245) terminated with status 1
<steffen_b> May  5 19:39:45 vdr init: irexec main process (2246) terminated with status 1
<steffen_b> May  5 19:39:45 vdr init: irexec main process (2247) terminated with status 1
<steffen_b> if you look at this 
<steffen_b> i don't have a "normal" natty 
<steffen_b> but i can check that 
<steffen_b> i would rather debug whats happening 
<steffen_b> then trying empiric if it's my fault or ubuntus ;)
<JanC> wait, I'm seeing things like "Apr 28 13:47:16 saeko init: plymouth-stop pre-start process (3747) terminated with status 1" too here
<steffen_b> or maybe coming from the other side 
<steffen_b> if upstart is using dbus for handling the jobs, how can upstart shutdown dbus ?
<JanC> upstart only uses dbus for communication with dbus clients
<JanC> and it doesn't need the dbus daemon
<JanC> for communication with upstart clients I mean
<steffen_b> k , so initctl uses 
<JanC> things like initctl
<steffen_b> something else
<steffen_b> not dbus
<JanC> dbus is a wire protocol, you can use dbus without a dbus daemon  ;)
<steffen_b> well on lucid i tried to send signals in init.d scripts and they got plain ignored back then 
<JanC> using initctl?
<steffen_b> now it looks like runlevel [016] gets ignored 
<steffen_b> yes
<steffen_b> which one gets ignored seems to be random/depending on time 
<JanC> that's weird
<steffen_b> my requirement is to cleanly shutdown the daemon 
<steffen_b> nothing should kill it before it is finished
<JanC> you have a pre-stop script for that?
<steffen_b> no
<steffen_b> only post start 
<JanC> default way to stop a job is to send SIGTERM, then after some time-out send SIGKILL, so if shutdown of your service takes longer, you'll need a pre-stop to handle this gracefully I think?
<steffen_b> https://bugs.yavdr.com/projects/yavdr/repository/entry/trunk/base/yavdr-base/etc/init/vdr.conf
<steffen_b> but pre-stop would wait until this is finished 
<steffen_b> before actually stopping it 
<steffen_b> pre-stop ->  kill with SIGTERM vdr doesn't sound right to me  
<steffen_b> also it wouldnt help if something would kill it 
<steffen_b> from init.d
<steffen_b> i can not believe that natty shutdown is so fucked up or handcrafted for the 5 known use cases 
<steffen_b> sry 
<JanC> I don't know what exactly goes wrong with your setup, but when using pre-stop for a job you can tell it to shut down and wait until it's ready, after that upstart will see no SIGTERM/SIGKILL is needed for that job anymore
<JanC> but maybe you want to know what goes wrong first...
<steffen_b> there are 2 issues 
<steffen_b> first is that runlevel is not coming or sendsigs is coming to fast  
<steffen_b> second is waiting for the daemon to finish
<steffen_b> the pre-stop might be nice workaround 
<steffen_b> but worth nothing if rc and those sendsigs is killing the jobs
<akio> Hello, I have finally figured out how to handle a broken serial port and got console redirection working but I don't know where to put the fix.
<steffen_b> on the other hand that should ignore everything which is handled by upstart
<akio> I have a ttyS0.conf in /etc/init that starts it for me, but before it starts it needs to be manually configured with setserial.
<akio> I was wondering where to put the setserial command.
<steffen_b> create a setserial.conf 
<steffen_b> start on starting ttys0 
<steffen_b> ttyS0
<akio> Oh cool thanks.
<steffen_b> https://bugs.yavdr.com/projects/yavdr/repository/entry/trunk/base/yavdr-base/etc/init/setserial-minimal.conf
<akio> Man upstart really has made GNU\Linux better in a big way for me.
<akio> Too complicated for me to follow.
<steffen_b> its cool, but causing me headaches sometimes 
<akio> Makes boot super fast.
<steffen_b> if its just for you , just but the commands you need in the script section ;) 
<steffen_b> start on starting ttyS0 
<steffen_b> will make it wait until that is finished
<steffen_b> you might need to put task keyword also in 
<SpamapS> yes, otherwise it won't block properly
<SpamapS> task makes it block until the job has completed the whole lifecycle
<akio> where does task go?
<SpamapS> on its own line
<SpamapS> anywhere tho
<akio> http://pastebin.com/AHPTn0GW
<steffen_b> yes should work 
<akio> rebeaut!
<akio> steffen_b: Thank you. That worked like a charm.
<akio> Because charms work well.
<steffen_b> cool :) 
<akio> Had an issue last night and couldn't console because previous admin couldn't figure it out.
#upstart 2011-05-06
<hvgotcodes> is this channel logged?
<hvgotcodes> im looking for an answer i got last week
<soren> hvgotcodes: http://irclogs.ubuntu.com/
<hvgotcodes> soren: thanx
<soren> sure
<hvgotcodes> soren: i cant find it -- the question last week was basically how to read env variables out of /etc/environment and make them available for the process that upstart is managing.
<hvgotcodes> the upstart conf i had is here
<hvgotcodes> https://gist.github.com/ef3ff41c2928db636917
<hvgotcodes> i think i just need to add some script sections to read the environment
<hvgotcodes> soren: i found the pastebin with the answer i got on this forum -- problem is when i try it the git_repo variable is not seen from within the process
<hvgotcodes> http://paste.ubuntu.com/600007/
<JanC> hvgotcodes: sudo cleans up the environment, you'll need to add the -E option to sudo
<JanC> (I should say: it cleans up the environment with a default Ubuntu sudoers config)
<JanC> and you might also have to add an option in sudoers to allow this
<hvgotcodes> JanC: you are saying just add a -E?
<hvgotcodes> is there a better way to be doing this?
<JanC> I haven't tested if just -E is enough; maybe you'll need to change sudoers
<hvgotcodes> JanC: what do you mean by it 'cleans up the environment'?  I thought that /etc/environment was always available no matter what
<hvgotcodes> there is no -E option for sudo
<hvgotcodes> at least in the man page
<hvgotcodes> oh yeah it is there
<hvgotcodes> hmm why do i get stop: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory when i try to do service theservice stop?
<hvgotcodes> i wonder if it would be better to have a wrapper script to launch the process, and source the environment in there
<radix> would a post on the upstart-devel list about my vserver + blocking upstart problems be appropriate?
<radix> I'm not sure how strict the list is about separating user support from development
<JanC> radix: user questions are welcome AFAIK (there isn't that much traffic)
<radix> okie doke
#upstart 2012-05-01
<steffen_b> having trouble to understand instance handling 
<SpamapS> steffen_b: its fairly simple if you consider that all jobs start with an instance value of ""
<SpamapS> steffen_b: the instance keyword just expands that a bit so that there can be multiple instances of a job if need be, by introducing variables
<steffen_b> yes - but i can stop a single instance by "stop on " condition ?
<SpamapS> steffen_b: all instances will stop based on the stop on, though you can use the same variables in the stop on as you do in instance
<SpamapS> steffen_b: so if you have 'instance $FOO' and 'stop on stopping other-job FOO=$FOO' that works 
<steffen_b> yes - guess what i tried was just bad idea 
<steffen_b> i wanted to track 2 events and making instance for each 
<steffen_b> if both happened (state saved in instance) 
<SpamapS> steffen_b: for what purpose?
<steffen_b> i can start something else
<SpamapS> so like 'start on started something-state EVENT=foo and started something-state EVENT=bar' ?
<steffen_b> logically yes
<steffen_b> except upstart doesnt work like that 
<SpamapS> well, it might, I think we're far too abstract.
<SpamapS> can you be more concrete?
<steffen_b> i have Xorg (job called openbox) and i have vdr (job called vdr) 
<steffen_b> each emits an upstart event openbox-started vdr-started once really completed
<SpamapS> you know upstart does that for you
<SpamapS> right?
<steffen_b> maybe on paper
<SpamapS> no it does it, in code. :)
<steffen_b> not really believe me
<SpamapS> Somehow we've managed to get upstart to do that to boot Ubuntu :)
<SpamapS> now, perhaps you're not familiar with some of the idiosyncratic ways to control the timing of that event emission
<steffen_b> a daemon forking doesnt mean its ready to connect 
<SpamapS> *agreed 100%*
<SpamapS> thats why we have post-start
<SpamapS> 'started' is not emitted until post-start exits
<steffen_b> i only know from inside the daemon, once completed
<steffen_b> now tell me how i get this outside
<steffen_b> and use it in post start
<SpamapS> touch a file
<SpamapS> while ! [ -f $file ] ; do ... 
<steffen_b> and loop sleep 1 ?
<SpamapS> or open a socket
<SpamapS> or a fifo..
<SpamapS> lots of ways to do it
<steffen_b> except the famous while ... sleep ... there is still no way
<SpamapS> also you can use 'expect stop'
<SpamapS> and send yourself SIGSTOP
<SpamapS> upstart will send you SIGCONT and the emit started
<steffen_b> in post-start ?
<SpamapS> no you don't need a post-start if you use expect stop
<SpamapS> I don't know of any jobs that use that method right now btw
<SpamapS> looping or using a fifo in post-start is the only method I've seen really
<steffen_b> at the moment i have start on started vdr and in the client i loop until socket is availble 
<steffen_b> which is painfull since this adds up to plenty of loops waiting and still keep them sort of syncronized in different cases
<SpamapS> is that a local socket?
<SpamapS> because, if its ever intended to be over a network, you should probably just keep that strategy.. you can't coordinate events over the network ;)
<SpamapS> at least, not w/ upstart :p
<steffen_b> local network, local fd, dbus ...
<steffen_b> x
<steffen_b> sound
<SpamapS> steffen_b: yeah, post-start seems like the simplest way forward, but if you want to build in upstart support, use the 'expect stop' method described in 'man 5 init
<steffen_b> might be worth a try - allthough we just added something to emit an event from daemon 
<steffen_b> sounds like a way to keep it on one place 
<SpamapS> steffen_b: emitting an event is fine too, its actually pretty cool. :)
<SpamapS> steffen_b: also, I believe there is a new initiative to track exits, not just forks, so that daemons that do the right thing and keep the parent alive until the service is ready, will work fine
<steffen_b> well there is also some fight with emitting an event as well 
<steffen_b> daemon is running as user - upstart event is send from user over dbus
<steffen_b> since inclusion of user jobs this means you can not control system jobs from user (except you switch that off i guess)
<steffen_b> so migrating depending jobs to be user jobs 
<steffen_b> where this user jobs are jobs of a system user - doesnt really sound like something which should be handed to the user
<steffen_b> guess a step back and think again 
<SpamapS> steffen_b: sounds like another reason to think about expect stop
<steffen_b> yes
<SpamapS> steffen_b: does your daemon keep its parent alive until it is ready?
<steffen_b> it never forks i think 
<steffen_b> i have no expect currently and it works :)
<steffen_b> its tracing the right thing 
<steffen_b> to know when its ready we using a plugin to the daemon which signals us from the first loop after initializing
<steffen_b> so vdr and upstart dont like each other 
<SpamapS> ah ok
<SpamapS> I do kind of wish we could have something like 'expect socket /var/run/foo.sock'
<steffen_b> the systemd kind of handling it 
<steffen_b> yes
<steffen_b> noch socket activation but buffering 
<steffen_b> noch -> not
<steffen_b> that would simply the thing i try by 50%
<SpamapS> I don't like socket activatino
<SpamapS> it simplifies the thinking, but not necessarily the implementation
<steffen_b> there are few things which are cool in theory - but in reality you need to workaround more things than you like
<steffen_b> expect /dev/foo
<steffen_b> expect tcp://localhost:37890
<steffen_b> expect /tmp/foo 
<steffen_b> would for sure make things simpler
<steffen_b> if that expect is state-like 
<SpamapS> it doesn't need to be state based
<SpamapS> just treat the appearance of a file/socket/etc. as an event
<SpamapS> and then we can use a job to track its state
<steffen_b> states are more natural
<SpamapS> are they?
<steffen_b> 100%
<SpamapS> Also, upstart *is* state based
<JanC> states & events need each other, so one isn't natural without the other
<SpamapS> you can track states w/ jobs
<steffen_b> but you need inictl status <jobname> | grep -q "^jobname.*running" 
<steffen_b> in an upstart job 
<steffen_b> where are the states at this point ?
<steffen_b> anyway  - this is not  blaming or being negative - just sharing thougts hope you dont get it wrong :)
<SpamapS> steffen_b: that *is* the state :)
<steffen_b> :D
<SpamapS> if you look on a recent ubuntu system, you'll see the workaround for not having them built in.. /etc/init/wait-for-state.conf
<SpamapS> start wait-for-state WAITER=me WAIT_FOR=somejob
<SpamapS> that lets you use jobs like condition variables basically
<steffen_b> wasn't that the workaround for "starting ... or starting ..." second one did not wait anymore ?
<steffen_b> until job is started
<SpamapS> yeah, well, thats basically the same problem
<JanC> maybe what we really need is an init daemon that can be configured with low-level state/event instructions, and then write compilers that turn all sort of job/unit/initscripts/... in config for it  ;)
#upstart 2012-05-03
<warreng> how can i force upstart to forget about a PID and think it's truly stopped?  (the actual process is long gone but upstart just won't give it up)
<warreng> so far, rebooting seems to be the only way... and even then, it hangs during shutdown on the process and requires a power cycle
<innovmon> Hi, I am using upstart with the rails Foreman gem - https://gist.github.com/2582347 here is the error. Permission denied - /etc/init/my-app.conf (Errno::EACCES) 
<djszapi> hey
<djszapi> jodh: there ? How could I make sure if there is no upstart job running, then "stop" does not terminate my post install script ? Shall I just check for the return value of "stop" ?
<jodh> djszapi: I don't understand your question fully, but does this help: http://upstart.ubuntu.com/cookbook/#creating-a-systemv-service-that-communicates-with-upstart-ubuntu-specific
<djszapi> jodh: was talking about this: http://paste.kde.org/468068/
<jodh> djszapi: packages should generally call 'invoke-rc.d restart' which calls /lib/init/upstart-job and that "does the right thing" - only calls stop if the job is actually running.
<djszapi> jodh: I am currently achieving this: http://paste.kde.org/468074/
<djszapi> jodh: why can that postinst script fail ?
<djszapi> jodh: what should I write instead ?
<jodh> djszapi: it will immediately exit if 'stop' fails due to the '-e'. See your shells man page.
<djszapi> jodh: so what is the recommended way of doing this ?
<jodh> djszapi: http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
<djszapi> jodh: I should not use -e ?
<JanC> djszapi: upstart uses "sh -e", nothing you can do about that
<JanC> but that paragraph explains how to suppress errors
#upstart 2012-05-04
<mirth> hah!  no wonder....i put the room name as my nick, and the nick as the roomname....later!
<mirth> quit
#upstart 2012-05-05
<damian0815> hey #upstart, i am using dbus-launch in jobA.conf to get $DBUS_SESSION_BUS_ADDRESS and $DBUS_SESSION_BUS_PID, and i want to pass these two variables to jobB.conf. how do i do this?
#upstart 2013-04-29
<DanaG> Say, I'm having trouble writing an upstart rule/job/scriot (whatever you call it)... if I try to start it, the 'start' command hangs forever, and nothing happens.  There isn't even a logged failure in syslog, and the log with the upstart job's name doesn't exist.  I've stripped it down to a minimal test case, and even this fails:  http://pastebin.com/D8wEy8fW
<jY> sounds like a fork problem
<DanaG> hmm, I'll try adding 'expect fork', even though a simple '/usr/bin/env' (print environment variables) ought not to fork itself...
<DanaG> Last thing I see with initctl loglevel at debug: "asset-upnp goal changed from stop to start".... then nothing.
<DanaG> Okay, that didn't change anything.
<DanaG> hmm, is it possible for upstart itself to get stuck in a screwed-up state where it refuses to do things?  I can stop and start lightdm just fine, but not my own service.
<DanaG> gah, for now, I'm giving up, and starting the darn thing in rc.local.
#upstart 2013-04-30
<mmcd> Hi! Anyone use upstart for resque in here?
<jY> mmcd: yes
#upstart 2013-05-01
<nanvou> hello, I have a problem with upstart on Ubuntu 12.04
<nanvou> even though I submitted a "respaw" stanza, if the program terminate somehow, upstart won't reload it
<nanvou> there's no script and only one "exec" stanzas...
<nanvou> anyone ?
<SpamapS> nanvou: respawn only respawns on abnormal exit
<SpamapS> nanvou: make sure you read the respawn section carefully in 'man 5 init'
<nanvou> process exits with 139
<SpamapS> nanvou: nothing in syslog about it?
<nanvou> yes
<nanvou> it syslog says it segfault
<nanvou> which is normal
<SpamapS> nanvou: segfault is also a reason to respawn (SIGSEGV)
<nanvou> what isn't normal is that segfault is detected by system but upstart won't do anything about it and let the program stay stopped
<SpamapS> nanvou: it is not marked 'task' right? and there's no 'normal exit' stanza?
<nanvou> I ran the program manually. It does SEGFAUT with status code "139"
<nanvou> SpamapS, http://paste.ubuntu.com/5623801/
<SpamapS> nanvou: indeed, upstart should be respawning that on segfault
<SpamapS> nanvou: and syslog says, exactly?
<nanvou> "kernel: [4526394.732639] segfaultest[25199]: segfault at fffffff7 ip bf9e085c sp bf9e085c error 4
<nanvou> "
<SpamapS> thats kernel
<SpamapS> nanvou: upstart would log as init:
<SpamapS> nanvou: if the program is daemonizing before the segfault, you don't have 'expect fork', so upstart will lose track of it
<nanvou> in fact it doesn't daemonize at all
<SpamapS> nanvou: initctl log-priority info should show more of what init: is doing
<nanvou> where should I wait for logs ?
<SpamapS> syslog
<nanvou> SpamapS, http://paste.ubuntu.com/5623839/
<SpamapS> nanvou: hah, so it did respawn
<SpamapS> nanvou: eventually it gave up, respawning too fast
<nanvou> ah ok
<nanvou> so how do I imply some waiting time ?
<nanvou> can I use multiple exec statement N
<nanvou> *?
<nanvou> like "exec sleep 10" ?
<SpamapS> nanvou: respawn limit
<SpamapS> nanvou: man 5 init explains it
<nanvou> yes, but I don't want to limit the respawns themselves, more like the time between the respawns
<SpamapS> nanvou: ah, post-start I think can achieve that. What is the point tho?
<SpamapS> nanvou: if you have a program this unstable.... 
<nanvou> I'll make it better in the future
<SpamapS> yeah but upstart is not the answer
<nanvou> right now, I just need upstart to be able to respawn it not too fast
<SpamapS> nanvou: just make a wrapper that always respawns it
<nanvou> mmh
<SpamapS> the upstart respawning is for *unexpected* fail
<nanvou> yes, that sounds like a possibility
<nanvou> SpamapS, thanks for the help
<SpamapS> nanvou: any time
#upstart 2014-04-28
<qiyong> # status vsftpd
<qiyong> vsftpd start/running
<qiyong> is upstart's fault?
<qiyong> the process id isn't shown and actually vsftpd doesn't start.
<marianogg9> hi guys, does anyone know what this mean? "main process terminated with status 1" what does 1 mean?
<marianogg9> I knew state 127 means an error
<marianogg9> can anyone take a look at this script please? it'll exit with a 127 status https://gist.github.com/marianogg9/11371260
<marrusl> marianogg9, on ubuntu at least, default shell is dash and it doesn't support "source"
<marianogg9> marrusl: mine is centos
<marrusl> marianogg9, use the env or export stanzas for variables
<marrusl> still might not be bash
<marrusl> 127 is command not found so it makes sense
<marrusl> default system shell i should say, default user shell could be something else.
<marrusl> http://upstart.ubuntu.com/cookbook/#job-environment
<marianogg9> but..it does work typing it manually thougj
<marianogg9> *though
<marrusl> your shell is probably bash
<marrusl> upstart uses /bin/sh what is that pointing to?
<marianogg9> marrusl: bash
<marianogg9> anyway..env is (at least in the example) for particular var definitions like PATH=value..I need to export a whole file 
<marianogg9> marrusl: ^^
<marrusl> marianogg9, not sure.  although bash can behave differently when invoked as /bin/sh.  you might get the same command-not-found if you run it manually and explicitly with /bin/sh instead of just executing it
<marianogg9> marrusl: besides /bin/sh matter, do you know how to export a file.env?
<jodh> marianogg9: I explained to you how to do that last Thurday. Did you read the links I sent explaining how to debug a job that does not run as expected?
<marianogg9> jodh: oh..you're right, sorry
<marianogg9> jodh: "+ rvm 2.0 /dev/fd/11: line 4: rvm: command not found"
<marianogg9> looks like it cannot find "rvm" command?
<marianogg9> I used "exec > /tmp/my_service.log 2>&1 set -x" in my script and got that error
<jodh> marianogg9: in which case, you'll either need to specify the full path to that command, or add the directory to $PATH. The former is safer though.
<marianogg9> jodh: is there a limit for the amount of var i can env/export ?
<marianogg9> jodh: ^^
<mgw> Â  irc://irc.freenode.net:6667/#Â invoke salt-minion via su so that /etc/environment is read
<mgw> Â  exec su -c salt-minion
<mgw> does that trick work on Trusty?
#upstart 2014-04-29
<marianogg9> hi guys, is there any limit in the amount of env vars I can env/export? 
<xnox> there are no limits imposed by upstart, just normal limits imposed by the operating system. nothing is infinite.
<marianogg9> xnox: could you have a look at this please? https://gist.github.com/marianogg9/11399155
<xnox> marianogg9: it's invalid... all of it.
<xnox> marianogg9: chdir, env, export, exec stanzas are all stand-alone and cannot be inside a script stanza.
<xnox> marianogg9: you can't have multiple exec stanzas
<xnox> marianogg9: and "start on startup" will not have /usr/local mounted yet (not guaranteed)
<marianogg9> xnox: it's working now
<marianogg9> that was my error then
<xnox> added a comment on the gist.
<xnox> well, if it's working now, all is good =)
<marianogg9> xnox: added the startup on runlevels, thanks!!!
<stgraber> 
<stgraber> oops
#upstart 2014-04-30
<SpamapS> hm
<SpamapS> did trusty switch to upstart in the initrd?
<xnox> no
<xnox> SpamapS: what's up?
<SpamapS> xnox: initrds going into graphics mode
<SpamapS> xnox: thought maybe upstart was involved
<SpamapS> makes ILO sad on my HP servers. :-/
<xnox> SpamapS: initrd would go into graphics mode if plymouth is pulled into the initramfs for any reason, e.g. encrypted root would pull it in, or..... ( i hope not) cloud-overlayfs.
<xnox> SpamapS: stuff.
<xnox> SpamapS: "overlayroot" package.
<SpamapS> xnox: I'll look into that. It is _REALLY_ frustrating.. I'm now passing all of this on the kernel command line:
<SpamapS> pxe_append_params=nofb nomodeset vga=normal video=vesafb:off text
#upstart 2014-05-01
<cariaso> when sshed in 'start varnish' works great, but on bootup it has no effect. This is on an amazon ec2 node. This minimal one seems like it should be sufficient
<cariaso> http://pastebin.com/aSh1E9EX
<cariaso> I'd be grateful for any thoughts on what's going wrong here
<cariaso> this more ambitious one shows various hacks I've tried based on possible problems I've seen from googling http://pastebin.com/6NDV3kXe . It still does not work any better
<adiabatic> This runs a small Go program that nginx connects to. Trouble is, when I do `initctl start bog`, it just spits out `bog stop/waiting`. Any ideas on how to fix this? https://gist.github.com/adiabatic/af3915cf1972fb69c0d2
#upstart 2014-05-02
<raydeo> so anyone know why upstart (consistently) gets into unfixable states for me? specifically "start nginx" <hang> "status nginx" <start/starting> "stop nginx" <hang> "status nginx" <stop/starting>
<raydeo> I have other scripts with this behavior, and I cannot find any workaround to even get out of this state.. if I copy nginx.conf to nginx2.conf and start that, it works fine
<raydeo> the only way to fix the nginx state appears to be to reboot
<raydeo> but more importantly why does it keep breaking
#upstart 2014-05-03
<KimStacks> hi there
<KimStacks> ever since i upgraded to 14.04 ubuntu my /etc/init scripts are not executed by upstart i believe.
<KimStacks> These are the details
<KimStacks> http://askubuntu.com/questions/459961/etc-init-script-not-running-in-14-04
<KimStacks> Anyone has good advice for me to troubleshoot?
<KimStacks> problem solved. Thanks all :)
#upstart 2015-04-29
<philm88> Hi all. I've created a service that's started via upstart. It logs to /var/log/upstart/service.conf, like other upstart services do. Ubuntu specifies a logrotate rule that acts on all upstart log files and rotates them. After log rotation, I need my service to be restarted so that it starts a new log file - but there doesn't seem to be a way to specify a postrotate command on a per-service basis - it's done for upstart as a who
<philm88> Also, not sure if this is a question for here or #ubuntu
#upstart 2015-04-30
<b4tm4n> how can i make an upstart script run on boot?
<b4tm4n> and, is it better to use init scripts or upstart?
#upstart 2016-05-02
<[diablo]> Good morning #upstart ... guys we have reason to believe that Upstart may well be killing a process... so we'd like to have detailed logs from upstart... sadly we're running RHEL6 so it's version 0.6.5
<[diablo]> does anyone know how the hell we can enable this please? I see on man init that there's --verbose on the boot line, but this does not give us any info that we can see
<chras> [diablo]: iirc its --debug
<chras> but you can also do initctl log-priority debug after the system is already running
<chras> but that will just be upstart debug, not neccecerily your event/jobs debug
<lll7> hi!
<lll7> https://github.com/KristinaEtc/go-nominatim/tree/master/daemons i wroted daemons for upstart, but when i run it in console (nsqd, for example) it's not closing correctly, just processing. why it could be so?
<chras> are you sure that your daemon is only a single fork ?
<chras> might need expect daemon instead
<lll7> :0 oh, i'm not sure. thank you for answer! starting search in google your words
<chras> imo
<chras> if you're controlling your own code, id suggest adding in some sort of --foreground option
<chras> then you wouldnt need an expect at all
<lll7> chras, like this? https://askubuntu.com/questions/52091/upstart-script-for-a-transmission-daemon-executed-as-a-normal-user
<lll7> (my english and programming skills are not good. need to ask that)
<chras> sec, reading
<chras> yeah sorta like that
<chras> if your program had a --foreground option then you wouldnt need any sort of 'expect' handling in upstart, as it would have direct control over the process's console
<lll7> thank you, tomorrow i'll check it 
<lll7> c:
<chras> the expect fork / expect daemon is kinda kludgey
<chras> expect fork expects that you do -exactly- 1 single fork
<chras> expect daemon expects exactly 2
<chras> depending what you wrote your software in, it could be either
<lll7> saved your words in file
<lll7> going to sleep
<lll7> thank you, thank you very much
<lll7> good night :)
<chras> good luck
#upstart 2016-05-03
<lll7> good morning again :c
<lll7> I DID IT
<chras> lll7: worked as intended?
<lll7> chras: YESYESYES
<chras> great
<lll7> i make out that it was beautiful
#upstart 2016-05-04
<frew> hey guys
<frew> I'm using post-start to block until a service is ready
<frew> I was under the impression that if a post-start script exits non-zero the service will then stop
<frew> but I guess that's not documented to be the case, and maybe it just isn't
<frew> thoughts?
<chras> frew: dont you want that in pre-start?
<frew> uh
<frew> no I don't see how that would make sense
<frew> I want to run the main script, and then block till it's ready
<chras> maybe im confused whatyou're trying to do
<frew> yeah sorry
<frew> so like
<frew> imagine you have a web server
<frew> and it takes like, 10s before it actually listens on port 80
<chras> becuase you have some sort of ruby , or whatnot that takes time to do the initial compile?
<frew> you can add a post-start that wget's port 80 over and over till it gets an actual return
<frew> right exactly
<frew> the problem is
<frew> I'd like the post-start script, if it takes to long, to give up and mark the whole thing as failed
<chras> does something else trigger off of this event?
<frew> well
<frew> if you do start $foo
<frew> it will block until post-start completes
<frew> so naive scripts do indeed
<chras> frew: i just tested, and an exit code of 1 in a post-stop doesnt kill the already-running process
<chras> but
<frew> yeah I know; I just want it to :)
<chras> if you manually check
<chras> and issue a 'stop' inside your post-start
<chras> then it will shut it down
<frew> I thought I tried that
<frew> how do you do that?  I tried literally stop $svcname
<chras> so in my test i did this
<chras> post-start script echo "sysrqd: this is a post start the next line is a stop" | $ILOG stop
<chras> oop, formatting is wrong
<chras> ill pastebin it
<chras> https://pastebin.mozilla.org/8869640
<frew> ok just a single stop.
<frew> huh
<chras> yeah
<frew> any idea if that will make start exit non-zero?
<frew> not a huge deal but that would be nice
<chras> i think it just sends a term to the process
<chras> at least, thats what it appears to do
<frew> right.
#upstart 2016-05-05
<martinkl_> hello
<martinkl_> I'm trying to understand why the env vars I'm setting don't reach my java process: https://gist.github.com/martinklepsch/087d1a36d5361386f1b5ff722f7e58ef
<martinkl_> I saw that this might be related to running as root but I do have a `setuid` stanza
<martinkl_> hm, seems it all works, I used initctl restart which apparently didn't pick up changes in this file?
<chras> martinkl_: your events are cached 
<chras> so that makes sense
<chras> you can do an initctl reload-configuration
<chras> to re-read your events
<martinkl_> I'm confused by the concept of events with regards to configuration but I also haven't taken the time yet to understand I guess chras 
<chras> well i can try to answer questions you have
<martinkl_> chras if I have updated my init script, is there one command to restart & reload configuration?
<chras> no, just stop, reload-configuration , starty
<martinkl_> chras are you familiar with ansible by any chance?
<martinkl_> chras it's unclear to me what exactly the `reloaded` state will do
<chras> martinkl_: a little bit
<chras> martinkl_: iirc a 'reload' just sends a hup to your daemon
#upstart 2016-05-06
<ll7> good morning
<ll7> ...
<ll7> how can i print a message from daemon to console?
<ll7> k@yurijbook3:/etc/init$ sudo service go-nsqd start
<ll7> start: Job failed to start
<ll7> like this
<chras> ll7: afaik there is no way to do this
<chras> we just log to syslog, or use 'console log' and check upstarts logs
<ll7> chras, ok, thank you c:
#upstart 2017-05-04
<xnox> I regret to inform you that upstart has been removed from Ubuntu Artful release due in 17.10, a follow up announcement about project EOL will follow shortly.
