#upstart 2006-11-20
<archis> Hi, anybody there to help me understand a few things about upstart etc?
<archis> hmm, so my situation is basically identical to use case 'Fabian' on upstart's Edgy spec page, https://wiki.ubuntu.com/ReplacementInit
<archis> 'Fabian is a power user who wishes to use a USB disk for part of his filesystem. This currently frequently fails because the USB disk sometimes takes longer to initialise than the boot process takes to get to the point where it mounts the filesystem. He would rather the boot process was robust, and the disk was mounted when initialised.'
<archis> whereby I should add that I am using the USB disk for swap as well.
<archis> My 5.10 Breezy fstab had them all enunciated, and it just worked that way. link: http://paste.ubuntu-nl.org/32913/
<archis> keybuk told me that this was because there was enough unexpected delay in the system to allow the USB disk to initialize
<archis> That didn't work any more with the much faster boot-up of Dapper. The system complained and I had to take the USB disk volumes out of my fstab. link: http://paste.ubuntu-nl.org/32914/
<archis> Now that Edgy has added UUIDs to each volume in my fstab. link: http://paste.ubuntu-nl.org/32915/
<archis> I haven't added the USB volumes back to fstab yet - is that all I need to do now?
<archis> Also, I continue to have problems with the swap located on the USB drive - it doesn't come online automatically even though it is in my fstab and I have to enable it manually.
<archis> Any suggestions?
<archis> ...
<archis> Hi Keybuk ..
<Keybuk> heyhey
<archis> Do you have a minute?
<Keybuk> sure
<Keybuk> sure
<Keybuk> what's up?
<archis> I have a few questions wrt upstart - I just wrote it all down here a little earlier - can you
<archis> get this or do you want to repeat it?
<Keybuk> repeat it :)
<Keybuk> I'm just getting everything back online at home after two weeks in SF
<archis> hehe..
<archis> so my situation is basically identical to use case 'Fabian' on upstart's Edgy spec page, https://wiki.ubuntu.com/ReplacementInit
<archis> 'Fabian is a power user who wishes to use a USB disk for part of his filesystem. This currently frequently fails because the USB disk sometimes takes longer to initialise than the boot process takes to get to the point where it mounts the filesystem. He would rather the boot process was robust, and the disk was mounted when initialised.'
<Keybuk> ok
<archis> whereby I should add that I am using the USB disk for swap as well.
<archis> My 5.10 Breezy fstab had them all enunciated, and it just worked that way. link: http://paste.ubuntu-nl.org/32913/
<archis> you  told me that this was because there was enough unexpected delay in the system to allow the USB disk to initialize
<archis>  That didn't work any more with the much faster boot-up of Dapper. The system complained and I had to take the USB disk volumes out of my fstab. link: http://paste.ubuntu-nl.org/32914/
<Keybuk> actually, Breezy it was more likely due to the fact breezy used hotplug
<archis>  Now Edgy has added UUIDs to each volume in my fstab. link: http://paste.ubuntu-nl.org/32915/
<Keybuk> whereas since Dapper, we've used udev
<archis> aha
<archis>  I haven't added the USB volumes back to fstab yet - is that all I need to do now?
<archis> Also, I continue to have problems with the swap located on the USB drive - it doesn't come online automatically even though it is in my fstab and I have to enable it manually.
<archis> That was my rant.. :)
<Keybuk> no, it hasn't been fixed yet
<archis> ah ok
<Keybuk> edgy is largely identical to dapper, except that we changed /sbin/init from sysvinit to upstart
<Keybuk> it's still driving the System V boot process though
<Keybuk> feisty is the release where we intend to have an event-driven boot
<archis> ok i see.
<archis> so I'd just leave things as they are for now
<archis> actually yeah i remember you were telling me about a udev race
<archis> condition being the probable cause
<archis> on dapper
<archis> :)
<Keybuk> *nods*
<archis> ok thanks
<wasabi> Keybuk: pong
<Keybuk> wasabi: buggered if I can remember ;)
<wasabi> hah
<Keybuk> probably something to do with the wiki
<Keybuk> or maybe a spec I was trying to write
<_ion> Can someone translate those quit messages? :-)
<thom> i believe scott's is a firefly quote
#upstart 2006-11-21
<AlexExtreme> will logd ever have the functionality to replace sysklogd?
<Keybuk> that's not the plan
<Keybuk> I'd rather sysklogd grew the functionality to replace logd ;)
<AlexExtreme> heh, ok
<thom> can we bin both and use syslog-ng? :-)
<Md> looks like a good plan
<AlexExtreme> yeah, syslog-ng is better ;)
<Keybuk> thom: if it's better, sure
* AlexExtreme wonders what would be needed to add logd's functionality to syslog-ng
<AlexExtreme> i'll look around at it when i get home
<AlexExtreme> anyway
<AlexExtreme> bbl, got a few lessons now
<Keybuk> AlexExtreme: not much, I suspect
<Keybuk> it needs to cope with /var/log not being writable, and buffer into memory if not
<Keybuk> and needs to have some mechanism to log things to a particular "job name"
<thom> the latter is probably easy
<thom> dunno about the former
<Keybuk> I must admit, I've not looked at syslog-ng
<Keybuk> I'd hope it has more than LOG_LOCAL0 thru 7, though
<Keybuk> some nice way for apache to be apache, not LOCAL4 :p
<Keybuk> briefly looking over the FAQ, I'd guess one would just need to write an upstart source
<thom> yeah, that was the conclusion i was reaching
<AlexExtreme> yawn
<AlexExtreme> let's take a look at syslog-ng then
<AlexExtreme> Keybuk: have you had time to take a look at the patches i submitted on launchpad? or are you still busy with other stuff?
#upstart 2006-11-22
<AlexExtreme> Keybuk: have you had time to look at my upstart patches that i submitted on launchpad?
<Keybuk> AlexExtreme: none
<Keybuk> what do they cover?
<AlexExtreme> there's one for what i think is a typo fix for using "console none" in job files
<AlexExtreme> another one as a response to a report to add an inittab man page saying that inittab is deprecated
<AlexExtreme> and one to fix the initctl (list|status) output
<Keybuk> thanks
<Keybuk> will look at those today if I get the chance
<AlexExtreme> ok
<Keybuk> assuming the patches are "trivial", it should be no problem, though to be on the safe side, could you read over http://upstart.ubuntu.com/wiki/CopyrightAssignment
<AlexExtreme> sounds ok
<Keybuk> we'd obviously like to keep the code under one licence, especially with the imminent GPLv2 vs. GPLv3 war <g>
<AlexExtreme> yeah
<AlexExtreme> i'm really not fussy about what license it's under or who it's copyrighted to
<Keybuk> *nods*
<Keybuk> I do make sure all contributors are listed in ChangeLog :)
<AlexExtreme> good ;)
#upstart 2006-11-23
<AlexExtreme> woah
<AlexExtreme> launchpad's design totally doesn't work in internet explorer ;)
<Keybuk> which lp design?
<AlexExtreme> i mean
<AlexExtreme> the page layout
<AlexExtreme> the CSS
<AlexExtreme> on launchpad.net
<Keybuk> really?  intersting
<Keybuk> I would have thought they tested that
<Keybuk> what's broken about it?
<AlexExtreme> umm
<AlexExtreme> in the menu at the top left
<AlexExtreme> when you move your mouse over it, it drops down, but there's spaces between all the menu items
<AlexExtreme> also some things appear misaligned
<Keybuk> heh
<AlexExtreme> should i file a launchpad bug report?
<Keybuk> there's a new UI coming soon anyway
<AlexExtreme> oh ok
<AlexExtreme> maybe file an IE bug instead ;)
<AlexExtreme> bbl
* CTCP BWAHAHA reply from Keybuk: 
<AlexExtreme> Keybuk: one comment about the graph on the ReplacementInitscripts wiki page - shouldn't the line from "logging daemon" come from started rather than stopped?
<AlexExtreme> bbl again
<mbiebl> AlexExtreme: what about syslog-ng, did you investigate it any further if it could replace logd?
<AlexExtreme> nah, i haven't had the chance - school work's been getting in the way and of course it's more important
<mbiebl> np
<mbiebl> When you mentioned it, I gave it a quick try and defined a new source like unix-stream("/com/ubuntu/upstart/logd");
<mbiebl> But that didn't work out.
<mbiebl> syslog-ng seems to expect a real file there.
<AlexExtreme> ok
<AlexExtreme> i'll take a look later once i've done homework
<Keybuk> mbiebl: you forget the \0 on the front
<Keybuk> the socket is in the abstract namespace, so it's \0/com/ubuntu/upstart/logd
<AlexExtreme> mbiebl: could you test that then? I mean if it works then great, we have a logd replacement ;)
<yankees26> sorry (accidental cmd+q)
<Keybuk> you'd need to cope with the additional bit of logd protocol
<Keybuk> SOCKET PROTOCOL
<Keybuk>        logd listens on a unix(7) stream  socket  in  the  abstract  namespace,
<Keybuk>        bound to /com/ubuntu/upstart/logd.
<Keybuk>        init(8) opens a new connection for each job that is to be logged, bind
<Keybuk>        ing the socket to the standard input, output and error file descriptors
<Keybuk>        for the job.
<Keybuk>        Before  running the job, it sends the job name on the socket so that it
<Keybuk>        can be logged along with the messages.  This is sent as a  size_t  that
<Keybuk>        contains  the length of the name to read, followed by that many charac
<Keybuk>        ter bytes.  The NULL terminator is not sent as part of the protocol, it
<Keybuk>        is up to the receiver to add that if required.
<Keybuk>        Further  information  about  the  job,  such as its description, can be
<Keybuk>        obtained by opening an ordinary connection to the  init(8)  daemon  and
<Keybuk>        querying it using the name received.
<Keybuk> --
<Keybuk> (yes, it has a man page, don't look shocked <g>)
<AlexExtreme> saying "have a look at man <whatever>" would have been simpler ;)
<yankees26> hehe
<Keybuk> it's only in 0.3.0, which isn't packaged yet
<AlexExtreme> good point
<AlexExtreme> btw did you see my comment about the graph on the ReplacementInitscripts wiki page?
<Keybuk> I did
<Keybuk> you're right
<Keybuk> there's lots of bugs in that actually
<Keybuk> it was just a brain dump to at least write something :)
<AlexExtreme> like that empty oval in the middle of nowhere :)
<Keybuk> that's deliberate
<Keybuk> it meant something
<Keybuk> unfortunately I did the graph before upstart got the ability (in my mind) to track states
<AlexExtreme> ah
<AlexExtreme> ok
<Keybuk> so I have no idea how I'd redraw it now, dotty isn't good at those
<yankees26> sorry once again
<AlexExtreme> last question: there are a lot of things pointing to "multiuser". that's an event, right? if so, how do you have events generated once several things have been done?
<mbiebl> Keybuk: I tried with @, \0 and nothing on the front.
<mbiebl> The error is always: Error binding socket; addr='AF_UNIX(0/com/ubuntu/upstart/logd)', error='No such file or directory (2)'
<Keybuk> probably needs doing inside the code then
<Keybuk> abstract namespace unix sockets are a bit ... interesting :p
<Keybuk> plus Linux specific afaik
<Keybuk> AlexExtreme: it was in that draft (which is old)
<AlexExtreme> AF_UNIX(0/com/ubuntu/upstart/logd) << that looks wrong, it seems to ignore the \
<Keybuk> in reality, it'll just be a flag and we'll make all the jobs parallel again
<AlexExtreme> ok, cool
<Keybuk> but I've not even written the spec for flags yet
<Keybuk> or, in fact, states
<Keybuk> I AM TEH SUCK
<AlexExtreme> lol
<Keybuk> http://upstart.ubuntu.com/wiki/EventStructure
<Keybuk> http://upstart.ubuntu.com/wiki/GoalChangeEvent
<Keybuk> ^ so far
<AlexExtreme> makes sense
<Keybuk> I will try and write more tomorrow
<Keybuk> this week has not been good for me :-/  too much jet lag and conf exhaustion
<wasabi__> #
<wasabi__> #
<wasabi__> The arguments are not appended to binaries the job executes directly, scripts must be used for that.
<Keybuk> I really need to get the stuff wasabi_ and I discussed over very hot thai down
<wasabi__> ^ Except for special "exec $1" syntax?
<Keybuk> wasabi_: sssh :)  we decided not to tell anyone about that trick <g>
<wasabi__> that thai was fucking hot. holy shit.
<thom> heh. yeah
<AlexExtreme> lol
<AlexExtreme> btw, what could be done about having the ability to enable/disable services? i mean, currently, if a file is in event.d, it will be used
<yankees26> you could have a simple conf file somewhere (or something like that)
<yankees26> kinda like a blacklist file
<AlexExtreme> mbiebl: try putting \\0 at the start to see if that makes syslog-ng actually realise that the \ is there
<wasabi__> We did some talking about white/blacklist files, for profile stuff. Probably need to talk about that more.
<wasabi__> ya know, single-user mode, etc.
<AlexExtreme> yeah
<mbiebl> AlexExtreme: doesn't help :-/
<AlexExtreme> still exactly the same error?
<mbiebl> yep
<AlexExtreme> then i'll write in something hardcoded to be able to specify an upstart source
<AlexExtreme> gimme a few mins
<yankees26> or in the actual file in event.d you have something like disable on startup
<mbiebl> yankees26: this wouldn't be good from a package maintainer pov.
<AlexExtreme> yeah
<mbiebl> Having to mangle files is fragile
<AlexExtreme> basically, modifying the event file is not an option
<Keybuk> AlexExtreme: you probably want that anyway, to get the job name
<wasabi__> It is an option.
<wasabi__> Three way merge. Etc.
<wasabi__> dish time!
<AlexExtreme> because if the package providing the job file is upgraded, it would be overwritten
<yankees26> mbiebl: true
<Keybuk> AlexExtreme: three way merge
<AlexExtreme> hmm well, the problem there: frugalware for example doesn't have any sort of capability for merging files
<Keybuk> ucs, etc.
<AlexExtreme> or am i talking BS? :)
<Keybuk> the thought was to ship a standard upstart tool that would merge config files
<wasabi__> I suspect if we go down the "profile" path, we'll have to do this too.
<wasabi__> And it'll take care of it.
<AlexExtreme> so, in a package's upgrade scriptlet you could run an upstart-provided tool that would merge them?
<Keybuk> right
<Keybuk> packages could install to /usr/share/upstart/... or something, and just run "update-event.d"
<wasabi__> [default] \n*=on\ndisableme=off
<AlexExtreme> k, sound's good
<wasabi__> [single-user] *=off\nsvc1=on
<mbiebl> So, update-event.d would create a link to /etc/event.d/?
<wasabi__> That being a fairly easy file to update, compared to job files.
<Keybuk> mbiebl: maybe.  or copy it
<Keybuk> I have a mild allergy to symlinks
<AlexExtreme> why's that?
<Keybuk> I try and edit them
<Keybuk> and end up editing non-config-files
<Keybuk> or you end up with the hideous apache style configuration, where the editable config file is in one directory, symlinked to another right alongside
<Keybuk> or worse, the Debian udev style, where the config files are just one level up
<mbiebl> Maybe doesn't look nice, but it has it's pros
<Keybuk> such as?
<mbiebl> E.g. if you want to disable a udev rule, you can remove the symlink
<mbiebl> I guess in Ubuntu you have to move the *.rules files somewhere else.
<Keybuk> rm /etc/udev/rules.d/...
<Keybuk> same command ;)
<mbiebl> And if you want it back?
<Keybuk> get it out of the package again
<mbiebl> Not that easy.
<Keybuk> why not?
<mbiebl> apt-get install --reinstall will not get the file back.
<mbiebl> You'd have to download the deb and extract the file
<Keybuk> dpkg --force-confmiss --install ...
<yankees26> what about a custom .rules?
<Keybuk> you could also just edit the file and comment bits out
<AlexExtreme> bleh, i can't think right now. i'll look at syslog-ng some other time
<yankees26> turkey clogging your brain?
<mbiebl> Keybuk: Imho both approaches have pros and cons, it's basically a matter of taste ;-)
<Keybuk> indeed
<mbiebl> And we know that it is hard to argue about that ;-)
<Keybuk> my favourite phrase during UDS was "it's my bikeshed!"
<AlexExtreme> mbiebl: want to try metalog? that can handle sockets AFAIK
<AlexExtreme> http://metalog.sourceforge.net
<thom> Keybuk: GREEN!
<AlexExtreme> the only problem with it is that it seems to be unmaintained - the last change was 22 months ago
<Keybuk> the truth is that I haven't put more than minimal thought into the config file problem yet
<Keybuk> we briefly discussed it at UDS
<yankees26> ugh, you guys are making me wanna look through upstart code (and in other words, hurt my brain)
<Keybuk> the upstart code is nice
<mbiebl> AlexExtreme: never tried metalog
<yankees26> it'd still hurt my brain Keybuk :P
<AlexExtreme> yankees26: it's better than this syslog-ng code *shudder*
<yankees26> i start doing header file searches for functions and thats when it gets painful :P
<yankees26> AlexExtreme: never looked at syslog-ng code
<yankees26> (nor do i plan to :P)
<AlexExtreme> the indentation in it is absolutely disgusting, it's completely unreadable
<yankees26> i care a lot about indentatio
<yankees26> n
<Keybuk> indentation is easy, one TAB per indent ;)
<yankees26> i spent like 5 minutes reindenting one of my nirvana perl modules
<AlexExtreme> Keybuk: exactly how i like it :)
<yankees26> i have it set for 4 spaces but it acts like a normal tab (set softtabstop=4 ftw)
<mbiebl> And spaces for alignment ;-)
<yankees26> alignment of what (i've never really fiddled with .vimrc)
<Keybuk> spaces for alignment is ... irritatingly hard to get right in an editor
* Keybuk usually doesn't bother
<yankees26> TO GOOGLE FOR ALIGNMENT! ('cause im dumb and confused ;P)
<mbiebl> yankees26: e.g. function arguments, that span over multiple lines.
<mbiebl> They should be indented by spaces
<Keybuk> yeah, ideally you'd have
<yankees26> ah like: int my_extremely_painful_function( int a, string  adfadsfasdfasdf,
<Keybuk> ^I^Isome_function (arg1,
<Keybuk> ^I^I               arg2);
<Keybuk> whereas most editors (including emacs) will do:
<yankees26> ah
<Keybuk> ^I^Isome_function (arg1,
<Keybuk> ^I^I^I     arg2);
<yankees26> ya
<yankees26> (my example was too long :P thanks for typing that ;P)
<Keybuk> it's almost certainly possible to get emacs to do that with some lithp
<Keybuk> but my lithp-fu is not strong
<yankees26> im gonna find out how in vim
<yankees26> (hopefully)
<AlexExtreme> hmm. "At the time we started, it was common for a Linux distribution to boot in a mere two or three minutes." Frugalware starts in 40 seconds! </boasting-session>
<AlexExtreme> sorry, i had to say that ;)
<yankees26> arch takes me 26 :P
<yankees26> ;)
<yankees26> seconds that is :P
<AlexExtreme> arch?!
* AlexExtreme doesn't like arch ;)
<yankees26> dont act like you dont know where pacman came from :P
<Keybuk> edgy is around 35s
<mbiebl> Depends on what services you start and how much sanity checking they do.
* AlexExtreme drags out some old bootcharts
<AlexExtreme> http://frugalware.org/~alex/bootchart-sysvinit.png - i was wrong, it's 30 seconds ;)
<mbiebl> Tried initng some time ago and was able to reduce my boot time to 18 sec.
<yankees26> i still win ;)
<yankees26> ok i lose now
<mbiebl> Still it took quite some time until gdm was up.
<AlexExtreme> yeah, the reason for that is that because things start in parallel there's more disk access and cpu usage going on which makes it a little slower
<mbiebl> But to be honest, bootup time is not so important for me.
<AlexExtreme> i found that with Runit, i had the services starting in parallel yet gdm still took the same amount of time to start
<mbiebl> Service supervision is much more important e.g.
<yankees26> off the top of my head i start: syslog-ng, network, hal, dbus, portmap, fam, alsa, mpd, crond, and then gdm goes
<yankees26> i should try that bootchard thing
<AlexExtreme> mbiebl: yes, but faster boot time is always nicer ;)
<Keybuk> AlexExtreme: on a processor like that, it should be faster than 30 :p
<mbiebl> AlexExtreme: but suspend to disk is getting more and more reliable
<yankees26> this is why i wanna try upstart when i do lfs
<Keybuk> AlexExtreme: you've got a few dead spots
<AlexExtreme> yeah i know
<mbiebl> You can't beat s2disk ;-)
<AlexExtreme> heh
<wasabi__> When I think of "profiles" I think of :
<wasabi__> http://upstart.ubuntu.com/wiki/Profiles
<AlexExtreme> Keybuk: well, this machine is limited in speed because of the hard disk, really. it's about 3 years old. i need to upgrade to SATA II sometime
<AlexExtreme> ah well
<AlexExtreme> http://frugalware.org/~alex/bootchart-runit.png << runit got 2 seconds improvement
<AlexExtreme> anyway, i've gotta go
<AlexExtreme> dinner's ready :)
<AlexExtreme> btw wasabi__, looks good. quite easy to understand for the average user in my opinion
<yankees26> 'cause im unaware of most upstart syntax
<yankees26> what are the *=y do?
<mbiebl> I guess it means, all available jobs are "activated"
<yankees26> ok
<wasabi__> the "current profile" is something that is simply set once, and the bits on the job that track whether they are enabled or disabled are just set when switched to it.
<wasabi__> so you can pass "default" on the kernel command line, and it just applies those rules to enabled/disable jobs
<mbiebl> wasabi_: What about creating directories in /etc/even.t/profiles/(default|single|foo)
<wasabi__> And the file is distributed basically exactly as shown. Two levels.
<mbiebl> and linking the to be activated jobs in there.
<wasabi__> no linking. =(
<mbiebl> Why not?
<mbiebl> Would be more fool-prof
<mbiebl> If the one profiles get's corrupted: bad
<mbiebl> If the editor makes a syntax error: bad
<mbiebl> Besides, it's harder to manage from withing package maintainer scripts.
<wasabi__> i'd hope no package maintainer script would ever touch it
<wasabi__> I'm a bit tired of symlink farms.
<wasabi__> Also they can't represent *
<mbiebl> That's surely is true
<wasabi__> We also had an idea of "flags"... some arbitrary strings you could pass to init on boot... to disable things. I'm not sure where we went with that. It was between bofs.
<wasabi__> Keybuk: ?
<Keybuk> "corridor bof"
<Keybuk> I quite liked the flags idea
<wasabi__> i seem to have forgotten it
<Keybuk> just a bunch of "on" or "off" values, jobs could elect to only run if a flag was on or off
<Keybuk> so you could have "if networking" in a network-device-added task
<wasabi__> ahh.
<Keybuk> if you turn the networking flag off, that doesn't happen
<wasabi__> So, on a kernel line, you could have networking=off, and they wouldn't run.   But what would turn networking on in the common case?
<wasabi__> or would you call the flag no-networking
<Keybuk> something like that
<wasabi__> "if not no-networking"
<Keybuk> it got fused in my head with the jobs-can-be-states idea, and I need to write that down first
<Keybuk> I did at least write all my notes down this time
<Keybuk> I just have pages of them
<mbiebl> wasabi_:  Should we add the idea with the profile directories + symlinks as alternative proposal to the wiki?
<Keybuk> sure, it's a wiki, fill it :)
<mbiebl> IIRC it's basically what gentoo uses today.
<Keybuk> you need to register to be able to edit pages, as usual
<mbiebl> Another one is borrowed from initng.
<yankees26> ugh, bootchart's dependency of java annoys me :(
<AlexExtreme> yankees26: well
<AlexExtreme> the actual script doesn't need java
<mbiebl> There, a single file represents a profile.
<yankees26> i run a java free system
<yankees26> and yes, that is how much i hate java
<Keybuk> right, off for dinner, l8r
<mbiebl> And you can include files
<yankees26> have fun eating Keybuk
<AlexExtreme> just download it and run the log it creates through the chart creatorr on bootchart's site
<AlexExtreme> Keybuk: have fun
<yankees26> AlexExtreme: so java is what takes the log and creates the chart
<yankees26> so really i dont need java, hmmm....
<AlexExtreme> yeah
<AlexExtreme> just download the script from bootchart's site, stick it in /sbin, run the log through the generator on their site
<yankees26> will do
<mbiebl> AlexExtreme: I thought java was only needed to generate the graph from the log file.
<yankees26> hence i can do it from the website
<yankees26> not java :D
<yankees26> and keep my java free system
<AlexExtreme> mbiebl: i know, that's what i'm saying
<mbiebl> AlexExtreme: I'm a bit slow atm ;-)
<AlexExtreme> heh
<AlexExtreme> woah
<AlexExtreme> i just found a gawping security hole in cherokee (it's a webserver)
<mbiebl> bbl
<AlexExtreme> it's htpasswd validation is totally broken - i put in a username that isn't listed in the passwd file and no password, it let me in
<AlexExtreme> cya mbiebl
<yankees26> bye mbiebl
<yankees26> AlexExtreme: do i only need a certain script from the src tarball?
<yankees26> thats prebuilt?
<AlexExtreme> wait, let me find it
<yankees26> ok, thanks
<AlexExtreme> get the source tarball
<AlexExtreme> copy the bootchartd script from the script dir to /sbin and chmod 755 it
<yankees26> ok
<AlexExtreme> and copy the bootchartd.conf file from the script dir to /etc and chmod 644 it
<yankees26> ok
<yankees26> then at boot i set init to init=/sbin/bootchartd, right?
<AlexExtreme> yep
<yankees26> where is the log file afterwards?
<AlexExtreme> /var/log
<yankees26> bootchart.tgz?
<AlexExtreme> yep
<yankees26> 24 seconds :D
<yankees26> http://fhatsoft.googlepages.com/bootchart.png
<yankees26> have fun admiring :P
<AlexExtreme> heh
<AlexExtreme> brb
<yankees26> ok
<AlexExtreme> back
<yankees26> welcome back
<yankees26> one more seinfeld disc left before i've finished season 7 ;D
<yankees26> brb: i'm gonna get some lunch
<yankees26> brb
#upstart 2006-11-24
<Keybuk> *yawns*
* AlexExtreme yawns too
<Keybuk> thankfully, it is Friday today
<AlexExtreme> yup
<AlexExtreme> is anyone free to add specs for upstart on launchpad?
<Keybuk> yeah
<Keybuk> that's why I've moved the specs to the upstart product, and got our own wiki
<Keybuk> so brain storming doesn't get in the way of ubuntu releases
<AlexExtreme> ok
<AlexExtreme> i'll write a spec about profiles later if i get time
<AlexExtreme> Keybuk: does this look ok to you? http://upstart.ubuntu.com/wiki/Profiles
<AlexExtreme> if so i'll add it on launchpad
<Keybuk> AlexExtreme: you should probably indicate where the profiles are actually defined
<Keybuk> and how they're chosen
<Keybuk> also you need to register the LP entry for it :)
<AlexExtreme> ok
<AlexExtreme> i've got a pretty good idea about that
<AlexExtreme> eww
<AlexExtreme> "Sorry, something just went wrong in Launchpad"
<AlexExtreme> hmm.
<AlexExtreme> works now
<Keybuk> cool
<Keybuk> (note: we're not using the "release goal" feature)
<AlexExtreme> oh
<Keybuk> it's not really useful LP thing at the moment, milestones work better
<AlexExtreme> ok
<AlexExtreme> ok, i've added more stuff to the design section
<Keybuk> http://upstart.ubuntu.com/wiki/JobsAsStates
<AlexExtreme> looks good
<AlexExtreme> btw, could you set a priority for the profiles spec? lp won't let me
<Keybuk> I'd like someone to write the competing "Flags" spec as well
<Keybuk> as there needs to be a decision about which route to follow
<AlexExtreme> k
<AlexExtreme> damn, the weather in this country sucks. there's nothing like a good old rain shower to make you feel even better when doing boring coursework.
<wasabi_> Jobs as states doesn't appear to differ in anyway from how it works currently: implicite start/stop events for a job
<wasabi_> also: good morning
<AlexExtreme> morning wasabi_
<AlexExtreme> wasabi_: jobs as states means that you can have a job without a exec/respawn/script
<wasabi_> Keybuk: Are you going to be writing down our thai conversation? If not I might be able to get some time this afternoon to put it down.
<wasabi_> AlexExtreme: Oh, missed that one little word "without"
<AlexExtreme> :)
<wasabi_> still need the basic state machine syntax put down in writing then
<Keybuk> yeah, plan to do that in a bit
<Keybuk> http://upstart.ubuntu.com/wiki/JobStates
<Keybuk> ^ does that read about right?
<Keybuk> (the unwritten intent being, obviously, that post-start is run in the "starting" state and pre-stop run in the "stop" state
<AlexExtreme> it sounds ok to me
<yankees26> that was odd (i couldn't reconnect)
<AlexExtreme> just one comment on this: http://upstart.ubuntu.com/wiki/JobsAsStates - shouldn't it say "A job without either an exec, script or respawn" rather than "A job without either an exec or script" ? (yes, i'm being picky :P)
<yankees26> was my question answered while i was gone?
<AlexExtreme> yankees26: which question?
<Keybuk> AlexExtreme: respawn is syntatic sugar.  I tend to ignore it
<AlexExtreme> ah ok
<yankees26> the return N_("stop") over return "stop"
<Keybuk> respawn ... just means respawn\nexec ...
<yankees26> 'cause N_ would just return "stop"
<AlexExtreme> yankees26: you lagged out so we probably didn't get it
<yankees26> ah
<yankees26> well in job.c in const char* functions, it returns N_("the string");
<yankees26> and N_ is just a macro that returns "the string" so why not just do return "the string";
<AlexExtreme> weno
<AlexExtreme> *no
<AlexExtreme> N_ performs localization
<yankees26> really?
<AlexExtreme> afaik, yes
<yankees26> 'cause i just see #define N_(_str) (_str)
<Keybuk> N marks it for localisation
<Keybuk> e.g.
<Keybuk> foo () {
<Keybuk>    return N_("the string");
<Keybuk> }
<Keybuk> char *a = foo():
<Keybuk> printf ("%s\n", _(a));
<Keybuk> it marks the string as likely to be translated
<Keybuk> where the _(a) actually translates it
<yankees26> oh, is this a natural compiler thing?
<Keybuk> it's a gettext thing
<yankees26> or is it 'cause libintl.h and locale.h are included?
<yankees26> ah ok
<yankees26> upstart can completely replace sysvinit right? (like sysvinit doesnt even need to be installed)
<Md> right
<Md> that's the point
<AlexExtreme> well, you need some utilities from sysvinit if you wish to use the sysvinit compat stuff, but to run a fully upstartized system, you don't need it
<yankees26> ah
<yankees26> what would be missed from using fully upstartized system? (arent shutdown and reboot apps from the sysvinit compat)
<AlexExtreme> no, upstart provides it's own
<yankees26> ah
<Keybuk> pidof, killall5, sulogin, last, mesg
<Keybuk> those are the binaries we still use from sysvinit atm
<yankees26> ah
<yankees26> well pidof i can mimic easily
<yankees26> ps -e | grep app | awk {'print $1'}
<yankees26> ( i think thats how)
<yankees26> (of course it isnt as safe)
<yankees26> cause of grep
<Md> it would be nice if util-linux were actually maintained, so we could ask the maintainer to accept them there...
<yankees26> is efty fully upstartized"?
<AlexExtreme> no
<AlexExtreme> feisty will be
<yankees26> ah
<yankees26> well hopefully i
<yankees26> 'll have nirvana done sometime in december and i can actually get to doing LFS with upstart
<Keybuk> https://wiki.ubuntu.com/DaemontoolsUpstartConfig
<Keybuk> ^ and the award for the most pointless thing in the universe to do goes to ...
<thom> *giggle*
<AlexExtreme> ahahaha
<Keybuk> the last two commands in his "Validate" section kinda prove why you really don't need daemon tools if you have upstart
<Keybuk> upstart supervising the supervisor
<AlexExtreme> yeah
<Keybuk> . o O { upstart-compat-daemontools }
<yankees26> me being a dumb idiot has no idea what daemontools does and chooses to ignore it :P
<thom> well, you'll need some compat bits for daemontools, yeah
<thom> the way stdout and stderr and proctitling and stuff are handled
<thom> and logging
<Keybuk> how does it handled stdout/stderr ?
<thom> can't remember, i just remember it being funky
<thom> it's been ~4 years since i last went near daemontools
<Keybuk> http://upstart.ubuntu.com/wiki/ComplexEventConfig
<Keybuk> ^ wasabi_, et al
<yankees26> JobAsState link doesnt work
<yankees26> says the page doesnt exist
<Keybuk> ah, should be JobsAsStates
<yankees26> ya
!alindeman:*! Hi all!  Wikipedia, the free content encyclopedia project we've all come to depend on, is approaching 1.5 million English articles.  If you wish to track the countdown, join #wikimedia-milestones  Of course, please don't go creating useless articles to "help" :-)
#upstart 2006-11-25
<fafek2> Hi!
<AlexExtreme> brb
<AlexExtreme> oops
<AlexExtreme> wrong chan
* yankees26 applauds AlexExtreme 
<AlexExtreme> heh
<yankees26> ;)
#upstart 2006-11-26
* IRCD=dancer CAPAB CHANTYPES=# EXCEPTS INVEX CHANMODES=bdeIq,k,lfJD,cgijLmnPQrRstz CHANLIMIT=#:20 PREFIX=(ov)@+ MAXLIST=bdeI:50 MODES=4 STATUSMSG=@ KNOCK NICKLEN=16 :are supported by this server 
* SAFELIST CASEMAPPING=ascii CHANNELLEN=30 TOPICLEN=450 KICKLEN=450 KEYLEN=23 USERLEN=10 HOSTLEN=63 SILENCE=50  are supported by this server
-NickServ(NickServ@services.)- This nickname is owned by someone else
-NickServ(NickServ@services.)- If this is your nickname, type /msg NickServ IDENTIFY <password>
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* Due to a network split, you can not obtain channel operator status in a new channel at this time 
* #ubuntu-laptop  You can't join that many channels
-ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
!christel:*! Hi again all. So, it would appear that one of my staffers inadvertantly triggered a long-standing issue with our server software causing the ircds to core. Thank you for your patience. All is back to normal, and we're making sure that this bug can't be triggered again. 
* Signon time  :    Thu Nov  2 17:51:08 2006
* Signoff time :    Sun Nov 26 10:40:32 2006
* Total uptime :   23d 16h 49m 24s
* Starting logfile irclogs/upstart.log
<livingtm> i have a newbie queston about an upstart script on my ubuntu 64 system
<livingtm> when my machine starts up checkfs.sh is checking partitions that should be part of a software raid. im trying ot understand where it is getting the partition list from so i can prevent it frm checking those partitions
<tonfa> livingtm: likely /etc/fstab
<livingtm> tonfa, /etc/fstab doesnt list the partition its checking... 
<yankees26> try weeding through checkfs.sh for the file
#upstart 2007-11-19
<ion_> http://heh.fi/tmp/kineia-20071119b
<ion_> As many subframes as the hardware can do (so that the framerate doesnât drop below 60 Hz) are rendered to each frame.
<ion_> Overexposure also behaves correctly with the motion blur. If an stationary object emits so many photons that it gets overexposed on a film/CCD, not nearly as many fotons might reach the same spot in the film/CCD when itâs moving quickly.
#upstart 2007-11-21
<Exal> Im trying to start an application on the tty3
<Exal> I have disabled load a teminal on /etc/event.d/tty3
<Exal> so, im wondering where indicate to run the application
<Exal> I have my line: astk:2345:respawn:/usr/sbin/asterisk >/dev/tty3 2>&1 </dev/tty3
<Exal>  
<Exal> where should be this?
<mbiebl> Exal: copy /etc/event.d/tty3 to /etc/event.d/asterisk (or choose a name as you like)
<mbiebl> and change the exec line accordingly.
<Exal> mbiebl: if I create a /etc/inittab with the line I pasted above doesn't work?
<Exal> mbiebl: exec astk:2345:respawn:/usr/sbin/asterisk >/dev/tty3 2>&1 </dev/tty3
<Exal> is ok?
<mbiebl> no
<mbiebl> exec line must be something like
<mbiebl> exec /usr/sbin/asterisk >/dev/tty3 2>&1 </dev/tty3
<Exal> ho, thanks :)
<mbiebl> and don't use /etc/inittab anymore
<Exal> mbiebl: ok :)
<Exal> then, I can put any file in /etc/event.d ?
<mbiebl> well, you can define as many jobs as you want, as long as the files have the correct format.
<mbiebl> http://upstart.ubuntu.com/getting-started.html
<mbiebl> http://upstart.ubuntu.com/wiki/Stanzas
<Keybuk> mbiebl: elmo's trying to persuade me to blog about Debian not giving patches back to Ubuntu
<Jc2k> Keybuk: on debian vs ubuntu:
<Jc2k> debian lenny has a bug in its intel 3945 support that ubuntu fixed months and months ago
<Jc2k> their tracker knows of the ubuntu fix...
<Jc2k> yet they do not fix.
<Jc2k> im confibbled, but luckily im happy enough with the killswitch toggling workaround ;_;
<mbiebl> Keybuk: this is a much too broad statement.
<mbiebl> There surely are DDs and corresponding Ubuntu Developers where the collaboration is suboptimal.
<mbiebl> On the other hand, take the X maintainers.
<Keybuk> true, the issue is that we get flamed for every single time we fail to submit a patch back
<Keybuk> or fail to honour the Debian maintainer in the control file
<mbiebl> Well, flaming back won't help imho.
<Keybuk> or change the build/patch system
<Keybuk> etc.
<Keybuk> yet Debian does it all the time -- even for certain packages like "upstart" :-)
<mbiebl> Really?
<Keybuk> yeah, I agree flaming back won't help at all
<Keybuk> also I really really don't care about Debian -- and argue that Ubuntu shouldn't derive from it anymore :p
<mbiebl> I tried to inform you whenever I made changes which would make sense for you in Ubuntu.
<Keybuk> mbiebl: there's a few patches I found in your postinst, etc. that make sense for Ubuntu
<Keybuk> and you changed the patch system
<Keybuk> (nb: I really don't mind -- I just find it ironic)
<mbiebl> The patch system is currently unused, so I saw no point for you to add it.
<mbiebl> Ah, now I see what you are referring to: The usage of dpkg-query in postinst.
<mbiebl> Ã¤hm, I mean preinst.
<mbiebl> Keybuk: So I admit, my fault. 
<ion_> keybuk: Would you perhaps consider licensing libnih as LGPL? :-)
<ion_> I'm getting fed up with glib's inconsistencies, but i'm going to license this project as LGPL.
<Keybuk> ion_: err.
<Keybuk> the problem with that is that libnih assumes the program it's linked to is GPL 2 or later
<Keybuk> because that's what it writes in the output for --version
<mbiebl> Keybuk: about the patch system: you currently don't use one in you ubuntu package, but I needed one for some smaller changes.
<mbiebl> Do you actually want that to submitted back?
<Keybuk> nah
<Keybuk> I do actually use one from time-to-time in the Ubuntu package
<Keybuk> e.g. for -updates
<ion_> I'd have to implement a lot of stuff i get from glib for free, though. UTF-8 handling for instance. Perhaps i'll just live with it. :-)
<mbiebl> Which one do you normally use then?
<Keybuk> ion_: err, you get that from glibc for free
<Keybuk> mbiebl: home grown simple patchsys-a-like
<ion_> I mean glib's UTF-8 helper functions.
<ion_> And PCRE helper functions etc.
<Keybuk> ion_: what do you need those for?
<Keybuk> I tend to find that if you're trying to "deal" with UTF-8, you're doing it wrong ;)
<ion_> Well, i need to have a loop that iterates each UTF-8 character from a string and does stuff with it.
<mbiebl> About the preinst stuff: shall I send you a patch for that?
<ion_> The code being portable to Windowsâ¢ is a plus, since some users might use it.
<mbiebl> Keybuk: I guess one problem might be, that DDs don't know, if you pull the debian packages verbatim from the unstable archive (as happens for most motu packages)
<mbiebl> or if they diverged and maintained separately.
<Keybuk> mbiebl: sure
<mbiebl> For the first case, any changes to the package will be applied to the corresponding ubuntu package automatically.
<Keybuk> ion_: on licensing
<Keybuk> I'm finding the current licence problems distateful
<Keybuk> have been considering what the best licence for libnih/upstart actually i
<Keybuk> is
<ion_> Ok
<Keybuk> and the whole GPL 2 vs GPL 2+ vs GPL 3 vs GPL 3+ mess is just a train wreck
<ion_> Yeah :-P
<Keybuk> it worries me that people think they can take GPL 2+ code and relicense it to GPL 3
<Jc2k> like BSD -> GPL spectacle ?
<Keybuk> indeed
<mbiebl> Keybuk: so, for the future, shall I send you a PM with a patch, submit a bug against lp or just ping you on irc?
<mbiebl> You know, I'm actually interested in improving the collaboration ;-)
<mbiebl> And I'd say, most of the time it works really well for the packages I maintain.
<Keybuk> submit patch in LP :)
<mbiebl> ok
#upstart 2007-11-23
<ion_> http://heh.fi/tmp/kineia-20071123a
#upstart 2008-11-17
<sadmac2> Keybuk: did you perchance look at the state machine explanation I gave on the list?
#upstart 2008-11-19
<keesj> Hi ppl
<keesj> I am STILL at 0.3.8 and hava a question about starting jobs
<keesj> when I run "start my_job_name" the system doesn't return ,(I need to use --no-wait as extra parameter)
<keesj> what does that mean?
<keesj> my test file looks like this http://paste-it.net/public/cd60791/
<suihkulokki> keesj: start --no-wait
<keesj> suihkulokki: yes, but that doesn't work for me because my service is started when and other service is started
<keesj> so "start on starting myother_test" 
<Keybuk> keesj: it won't return because you never stopped it
<Keybuk> you probably want "service" in there
<keesj> my file is called service_xxx :P 
<keesj> what is service?
<keesj> Keybuk: It works!!
<keesj> great!!
<keesj> Keybuk saved the day
<Keybuk> jobs come in two types, "task" and "service"
<Keybuk> a task has to complete before it is "finished"
<Keybuk> a service merely has to be running
<Keybuk> therefore the start command waits for a task to start, run and then stop again
<Keybuk> whereas it only waits for a service to start and run
<Keybuk> in 0.3.x, the default for a job was a task
<Keybuk> so since you had no main exec/script, it ran until you issued a separate "stop" command
<keesj> it all gets messy when you start using emits in upstart scripts
<keesj> but so far it all works :P
<sadmac2> Keybuk: good afternoon
#upstart 2008-11-20
<reppel> Hi, does some real documentation exist for upstart?
#upstart 2008-11-21
<arekm> hi, is there anyone alive who could help me track one issue? poweroff from upstart is broadcasting message about system going  "for power off" but it's not doing actual poweroff. Nothing else happens. This is custom distro that wants to use upstart
<arekm> I'm looking into ubuntu configs and actually I don't see where poweroff events are handled
<arekm> strace shows that init gets some message with "INIT_HALT=POWEROFF" but does nothing
<arekm> Nov 21 23:42:02 arm init: event_new: Pending runlevel event
<arekm> Nov 21 23:42:02 arm init: event_finished: Finished runlevel event
<arekm> but hm, nothing is run
<arekm> "telinit 0" on the other hand works well
<arekm> "shutdown -P" now also does nothing but "shutdown -P now -h' shutdowns system and powersoff
<arekm> while according to manual -P implies -h
<arekm> s/manual/shutdown --help/
<arekm> looks like NIH_MUST (e = nih_sprintf (NULL, "INIT_HALT=%s", init_halt));
<arekm> or any other env sent (NIH_MUST (e = nih_sprintf (NULL, "BLABLA=ZIMA"));)
<arekm> causes init to behave wrongly
#upstart 2008-11-22
<keesj> arekm: I think upstart has it's own fake implementation of halt/reboot that will send a mesasge to the rest of the system
<arekm> keesj: it does that. init receives it but doesn't act properly
<keesj> I guess you need to implement some shutdown strategy. I also use upstart on an embedded system
<arekm> huh? the upstart should switch to runlevel 0, no "some" strategy required
<arekm> but it doesn't do that if it gets _any_ env passed 
<keesj> arekm: that is only true is you use the backwards compatible scripts, upstart itself has no notion of runlevels , that is something from far awy in the past :p
<ssd71> Hi, I wanted to convert a few of my custom init scripts to Upstart jobs.  Should these jobs go in /etc/event.d/ or /etc/init/jobs.d/ (which doesn't exist).  The "getting started" page says the latter, but all my pre-installed jobs are in the former.  Is there a difference between putting jobs in event.d vs jobs.d?
<arekm> keesj: I use scripts that are still supported by upstart
<arekm> if that functionality is to be ignored/left buggy etc then I'll be sad :-/ (wanted to switch to upstart but can't use buggy stuff)
#upstart 2009-11-16
<niteowl> Hi. I'm using ubuntu 9.10 and just trying to add an upstart service which runs after all of the legacy init scripts. It doesn't seem to be executing though and there doesn't appear to be a way to enable boot logging for upstart.
<niteowl> 'start on stopped rc[2345]' should do what I want, right?
<niteowl> I have a description line, followed by start on stopped rc[2345] and then exec /usr/local/bin/myscript
<JanC> are you sure you don't want "start on started rc[2345]" instead?
<niteowl> I'm pretty sure I've tried that but I'll try it again now
<niteowl> I just did a sanity check and 'start on startup' works.
<niteowl> start on started didn't work either
<niteowl> initctl list shows rc stop/waiting
<niteowl> Is there any way to get boot logging?
<niteowl> From some googling I did it doesn't look like it's supported right now
<niteowl> I'm finding upstart incredibly irritating to deal with.
<JanC> it's new (and is still worked on)
<niteowl> I'm aware of that but if it's still so new why is it the default?
<ion> Thereâs no rc2 job. There are events such as ârunlevel 2â, which may be what you want.
<ion> Look at the other jobs under /etc/init.
<JanC> start on runlevel would start the job parallel with the legacy init scripts
<JanC> I guess there should be an init.d script that runs after all other init.d scripts and then emits an event to signal that to upsatrt
<niteowl> Hmmm. Well I tried start on stopped rc RUNLEVEL=[2345]
<JanC> which is what a "task" does
<JanC> hm, rc is a task, so it should be "started" after all init.d scripts are run?
<niteowl> The description at the top of the rc task is: This task runs the old System V-style rc script when changing between runlevels
<niteowl> Wouldn't that imply that it runs the /etc/init.d scripts
<niteowl> so when it's finished doing that it's stopped
<niteowl> which should be an event I can use in another task?
<JanC> yeah, probably (the documentation could be more clear there  ;)
<niteowl> I just wish I had some output to explain why it's not running
<niteowl> (any output)
<niteowl> Even a log of events and tasks being run
#upstart 2009-11-17
<btm> 'status JOB' exists with 0 when the job is running and when it isn't. is there a way to tell from an exit code if a job is running with upstart (since starting now emits 1 if it is already running)?
<dchen_> is there a way to reset the upstart respawn counter?
<dchen_> with inittab, the init q command does this
<Keybuk> dchen_: same
<dchen_> Keybuk: init q didn't seem to do it
<dchen_> I just waited for the timeout
<Keybuk> oh, no, it's running
<dchen_> pardon?
<Keybuk> you need to stop and start the job
<Keybuk> (with the telinit in between)
<dchen_> hrm
<dchen_> so I tried
<dchen_> initctl stop blah
<dchen_> init q
<dchen_> initctl start blah
<dchen_> and it had an error message that it was restarting too fast or something
<sadmac> Keybuk: you said ubuntu doesn't re-exec init on every glibc change, but instead does it just before unmounting the FS?
<asalkeld> hi, has anyone tried to cross compile upstart 0.63 yet?
<sadmac> asalkeld: yes. there's been some complaints about the dependency on libnih creating issues
<asalkeld> It has problems as nil-dbus-tool is build with the cross CC
<sadmac> asalkeld: yep
<sadmac> asalkeld: don't know that there's been a resolution sadly
<asalkeld> does nil-dbus-tool generate c files (only - no other function?)
<asalkeld> if so , it would be good if these c files could be generated as part of the shipped tarball
<asalkeld> so we would not have to compile nil-dbus-tool at all.
<sadmac> asalkeld: interesting idea.
<asalkeld> ok, well thanks - I'll try find a solution myself
<sadmac> asalkeld: technically the c files are not "source," but rather the xml they are generated from is
<asalkeld> like a configure file ...
<sadmac> true.
<asalkeld> often there is some prep that is done before distributing a release (changelog, autotools, etc...)
<asalkeld> this could be a part of this
<asalkeld> unless there is some dbus version dependant code.
<Keybuk> sadmac: correct
<Keybuk> wing-commander scott% grep telinit /etc/init.d/umountroot
<Keybuk> 	[ -f /var/run/init.upgraded ] && telinit u || :
<sadmac> Keybuk: why re-exec at all? From a vm perspective I don't see what problems it causes.
<Keybuk> sadmac: if you've upgraded libc or init, you have a file open on the root filesystem that is "dirty"
<Keybuk> so you cannot remount readonly
<Keybuk> the remount will fail
<Keybuk> and you'll power off a dirty root
<Keybuk> incur a mandatory fsck on reboot
<Keybuk> etc.
<sadmac> dunno why its dirty
<sadmac> dirty implies there's an alternate "clean" state
<Keybuk> yes
<sadmac> there's no laundering procedure for the pages in question
<sadmac> they should just be freed
<sadmac> or rather become anonymous
<Keybuk> they don't
<sadmac> kernel mis-step methinks (or posix mandating stupidity as is often the case)
<Keybuk> like most stupidity, posix
<sadmac> fantastic
<wasabi> My vbox init scripts work. Yay.
#upstart 2009-11-18
<asalkeld> Hi another cross compile question: uClibc does not have malloc_usable_size()
<asalkeld> can we do with out it?
<Keybuk> it's probably only used by the test suite
<asalkeld> is there an easy way to disable the test suite
<asalkeld> (from building)
<Keybuk> it won't build until you run "make check"
<asalkeld> with a "make" I get:
<asalkeld> ../nih-dbus/.libs/libnih-dbus.a(alloc.o): In function `nih_alloc_size':
<asalkeld> /home/anguss/work/main/buildroot/build_powerpc_8540/upstart-0.6.3/nih/alloc.c:743: undefined reference to `malloc_usable_size'
<Keybuk> yeah that's code in the core to support the test suite
<Keybuk> you'll have to patch that out
<asalkeld> so I have put a "AC_CHECK_FUNC(malloc_usable_size, [with_malloc_usable_size=yes])"
<asalkeld> in configure.ac
<asalkeld> etc ...
<Keybuk> that won't do anything unless you patch the code to check for that
<asalkeld> yip, done that
<asalkeld> so all is good
<asalkeld> but, I just wanted to make sure that it would not get called
<Keybuk> can't think of a reason it would be
<asalkeld> (which you answered)
<asalkeld> I'll send a patch
<Keybuk> patch won't be accepted I'm afraid
<asalkeld> Can you suggest a way to get around nil-dbus-tool getting built with the cross CC
<asalkeld> why (about the patch)
<Keybuk> Upstart is only intended to work with glibc
<Keybuk> if you want to run it with something else, that's fine - feel free to post the patch to the ML
<Keybuk> or even make a "uclibc" bzr branch with any necessary patches applied
<Keybuk> (that others can merge to keep up to date)
<Keybuk> but I'm keeping the core #ifdef free
<asalkeld> that might be a bit tricky
<asalkeld> does nil-dbus-tool do anything dbus version dependant?
<Keybuk> no
<Keybuk> it just generates C code
<asalkeld> could I build upstart on my host then copy the generated c files to my cross code tree
<Keybuk> yes
<asalkeld> and have a configure option to not run or build the tool
<Keybuk> I tried for a while to actually have the sources included in the tarballs
<asalkeld> would you accept a patch like that
<Keybuk> but gave up with that
<Keybuk> nope
<Keybuk> oh
<Keybuk> depends
<Keybuk> if you can get the files included in the source, I probably would
<asalkeld> like: configure --disable-nil-dbus-tool
<Keybuk> no, again, it's necessary
<asalkeld> I worry about the generated c files
<Keybuk> nih-dbus-tool is actually being split out anyway
<Keybuk> I have most of the code ready to make libnih a separate module
<Keybuk> so you'll just need it as a build-dependency on the build machine
<Keybuk> so that solves that particular problem
<asalkeld> ok, that sounds better
<asalkeld> are you going to release a version soon with this?
<Keybuk> yes
<asalkeld> cool
<Keybuk> probably this or next week
<asalkeld> ok, I'll wait
<asalkeld> thanks for your help
<Keybuk> no probs
<ion> keybuk: Btw, how about something like #define NIH_MUST(_e) ({ typeof (_e) __ret; for (int __i = 0; ! (__ret = (_e)); __i++) if (i >= 10) log_an_error ("...%s...", #_e); __ret; })
<ion> Of course, the logger shouldnât use NIH_MUST to alloc stuff. :-P
<Keybuk> ion: how will that help?
#upstart 2009-11-19
<cleary_> hi folks 
<cleary_> I have a bit of a problem, if I explain my scenario upfront it might make it a bit easier to resolve/point me in direction of correct doco
<cleary_> I'm currently building a custom ubuntu karmic based livecd for deployment in my workplace
<cleary_> part of the legacy hardware this needs to support is ~30 machines running older nvidia 7XXX series cards
<cleary_> the rest of the machines are intel - 
<cleary_> as a result, during boot I do a bit of rudimentary detection, and build/install the nvidia kernel module if required
<cleary_> this happens in a sys v init script
<cleary_> with the concurrent init feature in 9.10, X is starting well before this kernel module build process has had a chance to complete
<cleary_> so my question is, what can I do to hold the upstart process while this init script executes?
<cleary_> (or how should I be approaching this issue if this is not correct?)
<cleary_> I have to head off, I'll keep lurking here (if that's ok)
<dman777> does upstart contain/use devicekit? or are they two seperate systems? sorry for the noob question
<Keybuk> ah, Chrome OS
<sadmac> Keybuk: what about em?
<wasabi> i wish work was not so freaking busy so i could come down and say hi
<Keybuk> http://git.chromium.org/cgi-bin/gitweb.cgi?p=chromiumos.git;a=tree;f=src/platform/init;h=cfb362727833fd44eb85c8c9249ddaa8c1fab504;hb=master
<sadmac> Keybuk: figures
<Keybuk> figures?
<sadmac> Keybuk: well I wouldn't expect them to be using anything else really
<Keybuk> well, it is Ubuntu ;)
<sadmac> Keybuk: Upstart has a shiny, green, vectorized logo, a general disregard for the "traditions" of what it replaces, and its associated with Ubuntu, which has a general distro-of-the-people feel. Google being all over that shit is no surprise.
<Keybuk> lol
<Keybuk> are you quoting or just being bitchy?
<sadmac> Keybuk: bitchy? I meant all of that out of love <3
<Keybuk> hehe
<Keybuk> it's hard to tell
<sadmac> Keybuk: Americans.
#upstart 2009-11-20
<benc> I want to use upstart for mochiweb - an erlang web server
<benc> the server knows how to kill itself so usualy people use a script that tells erlang to stop the server and the erlang VM
<benc> in upstart the stop event kill the process so aren't they both doing the same thing?
<babel> hello
<babel> I'm playing with upstart and would like to run a script before runlevel [016]. I tried several ways to express what I want but "start on starting runlevel [016]" seems to be right but my job doesn't start. I've tested the script before with initctl emit test and that was fine. any ideas?
<babel> note: the script should shutdown any running kvm guest with virsh shutdown.
<benc> what does this means 'stop on runlevel [!023456]'
<benc> I'm trying to understand when I should stop my server. It's a web server
<ion> Effectively âstop on runlevel 1â, as long as [0123456] are the only runlevel event parameters. âstart on filesystemâ, âstop on runlevel [06]â might be appropriate for Ubuntu 9.10.
<benc> ion: hi, you helped me yesterday. for a mochiweb app, when do I need to stop it? do I need the [!023456] or something else?
<ion> âstart on filesystem and net-device-upâ instead of âstart on filesystemâ might be appropriate for a network service.
<ion> âstop on runlevel [06]â probably works.
<benc> what about 'start on startup' and 'stop on shutdown' ?
<benc> ok. I want to be sure that the network is up
<benc> thanks
<ion> âstart on stopped rc RUNLEVEL=[2345]â to start after the entire rc2 has been run.
<benc> do I need to wait for the entire rc2?
<ion> Depends. You might not even need to wait for a network device, if the service listens on all present and future interfaces. I donât remember what mochiweb does by default.
<benc> I don't mind waiting. startup speed is not very important as long as it's reliable. it just help me understand how stuff work
<ion> We probably should have networking emit an event when *all* interfaces defined in /e/n/i are up. That would be reliable. In fact, waiting for the entire rc2 to finish doesnât really guarantee all network devices are up. They just probably are. :-) âstart on net-device-upâ only guarantees one interface is up. Currently one could do âstart on filesystem and net-device-up ethfoo and net-device-up ethbarâ to make sure ethfoo and ethbar are up.
<benc> are you missing couple of and in the last example?
<ion> Nope
<benc> what do I need to replace ethfoo and ethbar with?
<benc> all I want is to start a web server reliably :) couldn't find nginx or apache examples
<ion> The names of the network interfaces (âauto ethfooâ entries in /etc/network/interfaces)
<benc> it should be protable. I want to use the same job on my dev machine and on vps hosting
<benc> ion: I've created a job for my mochiweb app but the status is stop/waiting
<benc> http://dpaste.com/122823/
<benc1> ion: any idea?
<ion> benc: Add âexec >/tmp/log 2>&1â just after the âscriptâ line, start the job and look at the log.
<sadmac> Keybuk: I've had some thoughts on respawn
<sadmac> and limits thereof
<ion> For each job, have an integer respawn_delay initialized to 1. Whenever the job dies, respawn_delay *= 2; respawn_delay -= number_of_seconds_the_job_was_running_before_it_died * 1; respawn_delay = clip (respawn_delay, 1, 300); respawn_after (respawn_delay);  // TODO tune the constants
<sadmac> ion: something quite like that, yes.
<sadmac> Keybuk: new bug filed. You're welcome
<sadmac> :)
<Keybuk> huh?
<Keybuk> sadmac: no it doesn't
<sadmac> Keybuk: it doesn't?
<Keybuk> not here
<sadmac> Keybuk: ...oops. I accidentally 0.3
<Keybuk> huh?
<sadmac> Keybuk: its a 0.3 bug
<Keybuk> why?
<Keybuk> 0.6 is no different in this regard
<sadmac> Keybuk: apparently it is. over here init has 3 persistant connections to /dev/console
<Keybuk> yes, stdin, stdout, stderr
<Keybuk> wing-commander scott% sudo ls -l /proc/1/fd
<Keybuk> total 0
<Keybuk> lrwx------ 1 root root 64 2009-11-20 13:50 0 -> /dev/console
<Keybuk> lrwx------ 1 root root 64 2009-11-20 13:50 1 -> /dev/console
<Keybuk> lrwx------ 1 root root 64 2009-11-20 13:50 2 -> /dev/console
<sadmac> Keybuk: oh, so it does have the /dev/console, but the SAK key doesn't kill it for you?
<sadmac> Keybuk: yeah, that's because X is on tty1 here
<Keybuk> X is on tty7
<Keybuk> (here)
<sadmac> that seems to be the killer
<Keybuk> so you're probably killing X, not init
<sadmac> Keybuk: killing X is desirable
<sadmac> Keybuk: its also killing init
<Keybuk> I can't see anything that indicates why it would
<Keybuk> for a start, SAK only applies to a TTY
<sadmac> what do you mean?
<Keybuk> SAK is handled in the TTY code
<Keybuk> /dev/console is not a tty
<sadmac> Keybuk: init and X are on the same tty for us
<Keybuk> err
<Keybuk> init isn't on a TTY
<sadmac> Keybuk: it has open FDs to the active tty
<notting> sadmac: but if it's /dev/console, then it theoretically would kill it on whatever tty you did SAK on
<notting> not just tty1
<Keybuk> exactly
<Keybuk> but since /dev/console is separate to the tty later
<Keybuk> layer
<Keybuk> (it's not /dev/tty0)
<Keybuk> it won't
<sadmac> Keybuk: not what the kernel docs say
<Keybuk> which docs?
<sadmac> Keybuk: Documentation/SAK.txt
<sadmac> Keybuk: "On the PC keyboard, SAK kills all applications which have /dev/console opened."
<Keybuk> see the first line
<Keybuk> Linux 2.4.2 Secure Attention Key (SAK) handling
<Keybuk>       ~~~~~
<sadmac> there is that, isn't there...
<Keybuk> the sysrq.txt docs say "given console"
<Keybuk> besides
<Keybuk> sysvinit holds /dev/console open too
<Keybuk> (afaik)
<sadmac> Keybuk: its by SID from the foreground console
<sadmac> and nothing on fedora has SID 1 but init
<Keybuk> SID?
<sadmac> Keybuk: session id
<sadmac> Keybuk: the code is 1) get foreground tty. 2) get tty->session 3) kill processes with that session ID
<Keybuk> so why doesn't it kill init on other ttys?
<Keybuk> ah!
<Keybuk> because getty will take the session
<sadmac> Keybuk: I dunno if we should call that an upstart bug. Its kind of a sloppy mess
<sadmac> Keybuk: in an abstract sense, tty1 should have X's session ID.
<Keybuk> yes
<Keybuk> it should
<Keybuk> in fact, X will sulk heavily (ie. crash) if something else takes it
<Keybuk> but tty1 is in KD_GRAPHICS mode
<Keybuk> so all bets are off
<sadmac> Keybuk: will TIOCSCTTY fail in graphics mode?
<Keybuk> no idea
<sadmac> might be worth a shot
<sadmac> notting: thoughts on all this?
<notting> (on a conf call, not reading yet)
<sadmac> Keybuk: If upstart does close stdin/out/err, that would get it as well, would it not?
<Keybuk> "get it" ?
<sadmac> Keybuk: kill the bug
<sadmac> I don't know what the session would become in that case, but you can't be the controller for a terminal that you don't have open, can you?
<Keybuk> no idea
<sadmac> Keybuk: I thought you were the font of obscure tty behavior :)
<sadmac> time to go screw around with it. /me waits for $dayjob to end/
<wasabi> Keybuk, you guys doing dinner anywhere tonight? I'd love to meet up with ya.
<Keybuk> there's the BBQ and AllStars event at the hotel
<wasabi> hmm
<wasabi> i haven't been by at all. been swamped at Real Job
<notting> sadmac: hey, that bug has a dup
<sadmac_home> notting: really?
<notting> yeah, someone filed a bug against X about it
<sadmac_home> hm
<benc2> if I need to export HOME, do I do this at the top of the job or inside the script/end script ?
#upstart 2009-11-21
<benc1> ion: the debug statement helped. I needed to export HOME=/root
<benc1> ion: I wonder what should I set HOME to if I want to run as non super user without a home dir
<ion> su sets HOME here. In the future, when Upstart itself initializes PAM sessions for non-root jobs, that will initialize their session in a similar way. All users have *some* home directory in their passwd entry.
<benc1> what do you mean by 'su sets HOME here'?
<benc1> that if I'm using su I don't need to export HOME?
<ion> Yeah. su initializes a PAM session for the command, and iâm sure some PAM module creates the proper environment with HOME set.
<benc1> shouldn't upstart set HOME=/root if I'm running as root?
<ion> Upstart doesnât create a PAM session for *any* job at the moment. It sounds like your job wants a PAM session. su 'exec foo' root might be what you want in the meantime.
<benc1> ok
<ion> su -c 'exec foo' root, that is.
<ion> export HOME=... might suffice, of course, depending on the program. But su -c '' root will surely run the command in a familiar environment.
<benc1> 'su -c'  will probably make sure the PATH is also set
<ion> Upstart itself sets PATH to some internal default value, but su -c '' root should create an environment with PATH set according to the PAM configuration for a root login session.
<benc1> I probably don't want to use 'erl -detached' so upstart can monitor the process, right?
<ion> Yeah, donât use that until Upstart 0.10, which can properly monitor all processes, no matter how they behave.
<ion> Current Upstart has some rudimentary support for following forks, but one can upset that functionality very easily.
<benc1> what will 'erl -noinput' do?
<benc1> you said you use that
<ion> man erl :-)
<benc1> ok. thanks
<ion> http://github.com/ion1/camera-control/blob/master/camera-control.upstart
<ion> http://github.com/ion1/camera-control/blob/master/releases/0/run
<benc1> thanks
<ion> The Upstart job has some rudimentary log rotation, but iâll replace it with something saner some day.
<benc1> what will you replace it with?
<ion> An Erlang logger that saves plaintext logs but with rotation similar to mf.
<benc1> ok
<ion> One might exist already, i havenât really looked yet.
<benc1> it will be nice to have upstart with log rotation and reload event
<ion> Yeah, Upstart might implement the logging of jobsâ std{out,err} first, iâll just use that then. :-)
<systest> perhaps I've missed it in the docs, but is there a simple "disable" argument for services defined in /etc/init? (similar to the xinetd option)
#upstart 2009-11-22
<sadmac_home> I found a GCC bug.
 * sadmac_home will feel smug forever
<ion> A bug? In gcc?!
<sadmac_home> ion: yeah. parsing issues related to the use of two gcc language extensions in the same place
<sadmac_home> ion: https://bugzilla.redhat.com/show_bug.cgi?id=540047
#upstart 2010-11-22
<ivoks> guys, how does one make upstart not to kill child processes?
<ivoks> pkill -TERM [processname] - works
<ivoks> but within upstart, it's massacre
<ivoks> i've set expect fork
#upstart 2010-11-23
<twb> Is /lib/init/fstab an upstartism?
<twb> lxc-ubuntu creates it, but I'm not sure what uses it
<ectospasm> this channel seems underpopulated, and the Upstart documentation seems woefully inadequate.
<ectospasm> ...I never see any adequate answers to questions like that here.
<twb> ectospasm: I know, but it costs me little to try
<ectospasm> true enough
<twb> If I'm running upstart inside a container, how do I pass --debug to it?
<twb> (container as in LXC)
<mbiebl> twb: to be precise, /lib/init/upstart is used by mountall
<mbiebl> but yes, it is upstart specific (as is mountall)
<twb> OK.
<twb> I'm trying to run lucid in an LXC container, but unless I rip out most of /lib/init/fstab, it doesn't start a getty on /dev/console and there's no other output on /dev/console, and I don't know how to work out why -- short of bisecting over /lib/init/fstab
<mbiebl> which directories fail to mount under lxc?
<twb> mbiebl: I don't know
<twb> I don't know *how* to know
<twb> In /lib/init/fstab, is "showthrough" a mountallism?
<twb> i.e. if I'm moving those mountpoints to pre-upstart code, do I just strip that option out?
<mbiebl> showthrough from what I know allows you to mount /var/run early during boot
<mbiebl> and later /var 
<mbiebl> and /var/run won't be shadowed
<twb> Oh, I see.
<twb> That means I don't need it for my specific use case
<mbiebl> twb: if you don't have a separate /var, yes
<mbiebl> (not sure if that is even possible within an lxc container)
<twb> Yeah, but I happen to not be doing it :-)
<twb> Dumb question: does that mean ubuntu/upstart ignores RAMRUN=yes RAMLOCK=yes in /etc/default/rcS?
<mbiebl> yes
<twb> Hum.
<twb> Due to the way LXC operates, I want to instrument wherever the upstart calls the "real" (hard) halt
<twb> I can't see where that's happening in /etc/init -- is it done elsewhere?
<mbiebl> /etc/init/rc.conf
<mbiebl> it calls /etc/init/rc 0|6 on shutdown/reboot
<twb> Ah, and the hard halting is done by it
<mbiebl> it is done in S90reboot resp. S90halt
<twb> Right, I juts found it
<twb> Is it just me, or does upstart get pissy if its pid isn't 1
<twb> kill -9 1 wasn't working, so my first idea was to make upstart the not-quite-first init
<mbiebl> it needs to be pid 1
<ectospasm> twb: init is always 1
<twb> Because the kerenl gives special treatment to 1?
<ectospasm> init is the parent process of everything
<ectospasm> init cannot be a child of some other process
<ectospasm> old school UNIXy design, IIRC
<mbiebl> pid 1 has special semantics
<mbiebl> re-parenting of child processes etc
<twb> Is there a way to get "kill -9 1" or similar to work?
<ectospasm> twb: what are you trying to achieve with "kill -9 1"?
<mbiebl> killing pid 1 will result in a kernel panic
<twb> I'm in a container, and halt/reboot -f doesn't work quite right, but I'm told LXC will do the right thing if I instea terminate the init process
<twb> mbiebl: short of HTFS, is there a way to tell upstart "I know better than you, please let me kernel panic"?
<mbiebl> twb: I know there were problems in the past related to openvz and upstart
<mbiebl> I can't tell you more, sorry
<Keybuk> there's nothing about Upstart that would cause kill -9 1 to not work
<Keybuk> if kill isn't working, you have a kernel problem
<Keybuk> (which was implied by you saying you were using LXC, I realise)
<twb> Keybuk: my host OS is 10.04 (running stock lucid 2.6.32) -- could I fix this with a different / newer kernel?
<Keybuk> no idea
<twb> Or are you saying that "LXC is just wrong"?
<Keybuk> I was ;)
<twb> Grmph
<Keybuk> I'm not a fan
<twb> mbiebl: in case you don't know, lxc is basically openvz cleaned up and accepted into mainline
<twb> Well, lucid doesn't boot if /var/run isn't a tmpfs, and lxc doesn't detect the guest halting if /var/run is a tmpfs, so it looks like I'll have to give up and use KVM, taking the performance hit that emulating an entire peecee for every daemon implies
<twb> (If lxc doesn't see the domU pid 1 terminate, it does a dirty hack by watching /var/run/utmp for a restart event, but it can't see it when there's a tmpfs mapped over the top.)
<Keybuk> that sounds like a bug in lxc
<twb> mjt (in #lxcontainers) said: well, the prob can be solved in two places.  Either proper (for a container) sys_reboot in kernel (this is what halt -f is using), or in init.  So far kernel folks tells us "it can be done in userspace" (in init), and init folks say "kernel is wrong".
<twb> mjt said -9 might be special
<twb> So I just tried everything from -1 up, and -8 worked
<twb> So I *think* I can just edit /etc/init.d/S90halt to call "kill -8 1" instead of "halt -f"
<Keybuk> if kill -9 1 is being treated as special, it's being treated as special by the kernel ;-)
<Keybuk> so again, the fix for that should go in the kernel
<twb> I guess so.  Sorry for losing my temper.
<Keybuk> so the discord is because when you write software on any platform, you agree to a contract between yourself and things like the kernel for how you should operate
<Keybuk> something like init is even more important, it has special behaviours that aren't granted to ordinary processes
<Keybuk> so the contract (ie. API/SDK) between you and the kernel is very important
<Keybuk> the reason init authors tend to dislike things like LXC is that it makes the kernel break that contract
<Keybuk> and the LXC folks seem to think it's our fault
<Keybuk> now, if container authors could agree on an alternate contract
<Keybuk> *and* provide ways for init to be told which contract we should use
<Keybuk> things would be better
<Keybuk> but historically they've been unwilling to do that
<twb> I suppose they argue the whole point is you shouldn't be able to tell you're in a container
<Keybuk> (OpenVZ, LXC, etc. have all randomly changed their APIs and which kernel features they support between releases)
<Keybuk> and right, they argue that a call to tell whether you're in a container defeats the point
<Keybuk> and our counter-argument is that we *CAN* tell we're in a container
<Keybuk> we can tell because the kernel is not obeying its interface contract to userspace
<twb> haha
<Keybuk> they can't have their cake and eat it
<Keybuk> if a container should be invisible, it should also be invisible to init
<Keybuk> if init should handle containers specially, so should all user space processes be able to
<twb> OK, I think I have it actually working
<twb> Now a kill -2 to lxc-start (or upstart) from the dom0 will make upstart see a ctrl-alt-del, and at the end of that, /etc/init.d/reboot (or halt) will kill -SEGV 1, which lxc-start "sees" and handles the cleanup of stuff above upstart.
#upstart 2010-11-24
<BLZbubba> if upstart gets stuck in the boot process, mounting remote filesystems in this case, is there a way to get it to wake up and continue booting?
<BLZbubba> is there any way to protect myself from this error: plymouth main process killed by abrt signal ?
<mistergibson> hello all
<mistergibson> is anyone working on a gnome control panel (gui) settings app for upstart?
#upstart 2010-11-25
<twb> In lucid, upstart provides halt(8).  It's manpage indicates that it only accepts -fpw --verbose, but /etc/init.d/halt passes it (at least) -d as well.
<twb> Is the manpage incomplete?  I would expect it to mention if additional options were accepted and ignored for reasons of backwards compatibility.
<twb> For now I have just instrumented it as if it was Debian's reboot/halt/poweroff:
<twb> chroot /srv/lxc/template-minbase tee >/dev/null /sbin/reboot <<<$'#!/bin/bash\nwhile getopts nwdfiph opt; do [[ f = $opt ]] && exec kill -SEGV 1; done; exec "$0.distrib" "$@"'
<soren> twb: -d, -i, and -h are all ignored.
<twb> Thanks.
<soren> twb: Sure.
<jetienne> q. in a upstart script, [ "$HOSTNAME" == "jmebox" ] && export HOME="/home/jerome" || export HOME="/home/jetienne" <- this doesnt work... BUT does work in a interactive shell how come ?
<jetienne> script = ? bash ?
<ion> HOSTNAME is probably not defined in the environment, as set -u and perhaps set -x and logging the output should tell you.
<jetienne> ?
<ion> keybuk: How about set -u by default in Upstart scripts? :-)
<jetienne> ah ok 
<jetienne> ion: understood thanks
<Keybuk> ion: I think I answered that one once already
<Keybuk> it makes programming shell in Upstart more surprising than it should be
<Keybuk> and makes it pretty hard to actually do common shell-y things
<ion> ok
<jetienne> sudo initctl restart mystuff <- this doesnt work ?
<jetienne> the man page seems to say ok, but in practice i got an error 
<jetienne> sudo initctl restart lshow_http_proxy
<jetienne> initctl: Unknown instance: 
<jetienne> but this works with start/stop/status
<jetienne> so it cant be really unknown 
<Keybuk> is it running?
<Keybuk> ie.
<Keybuk> sudo status mystuff
<Keybuk> what does that say before you run restart?
#upstart 2010-11-26
<asmcos> hi
<asmcos> ubuntu 10.10 upstart don't need dbus ?
<ion> Upstart doesnât require the daemon, but does require the protocol library.
<asmcos> libdbus-1-3?
<ion> yes
<asmcos> oh
<asmcos> my ubuntu 10.10,can boot by init=/bin/bash
<asmcos> but upstart can't boot....
<asmcos> I use sysrq key to display task, upstart can list mountall,plymouthd
<asmcos> showTasks
<asmcos> ion, I can config /etc/init  only a task? 
<ion> Add â--debug >/dev/mountall.log 2>&1â to the end of the âexec mountallâ¦â line in /etc/init/mountall.conf, create /etc/init/sulogin.conf based on the first example in <http://upstart.ubuntu.com/wiki/OMGBroken?highlight=%28%28CategoryDoc%29%29> and reboot. You should have a shell in the virtual terminal 7 in which you should be able to look at /dev/mountall.log. It might have a hint as to why it doesnât boot.
<asmcos> thank you 
<asmcos> i try....
<twb> What's the difference between the "filesystem" and "local-filesystems" events?
<twb> Or: where are such events documented?
<asmcos> ion,thank you ...
<asmcos> ion, root remount rw on *.conf ?
<asmcos> ion, which file is  /proc/self/fd/8 ?
<twb> It's a file descriptor
<asmcos> i know it's a file descriptor
<twb> OK, I wasn't sure if you wanted the generic or the specific answer :-)
<asmcos> twb,i think it is a specific file.
<twb> I think it's something like the fd used for mountall to talk to upstart, or for upstart children to talk to pid 1
<twb> If you work it out let me know
<asmcos> twb,mountall can remount root?
<asmcos> twb, who remount root rw ?
<twb> I *think* mountall remounts *everything* it finds in /proc/mounts
<asmcos> so We must mount proc first ?
<twb> I dunno man
<twb> I'm just a poor ignorant sysadmin who wants his deterministic sysvinit back.
<asmcos> yes,I find proc have mounted....
<twb> Unless your fu is strong, it will be hard for /proc NOT to be mounted
<twb> In a pre-stop script, how do I match the PID of the daemon managed by the job?
<twb> Actually a better question:
<twb> How do I tell upstart to sent INT instead of HUP as the "soft" kill signal?
<twb> Er, INT instead of TERM.
<twb> http://paste.debian.net/100790/
<twb> I'd appreciate a review of these LXC upstart jobs.
<asmcos> hi
<asmcos> everyone
<asmcos> mount-tmp.conf 
<asmcos> start on mounted ...
<asmcos> the mounted is set by mountall.conf "emits mounted" ?
<asmcos> exit
<asmcos> ion
<asmcos> ion, hi
<asmcos> ion, I use a sulogin.conf exmaple. it can work.
<asmcos> start on startup.
<asmcos> I test emits,so I add line "emits logined" in sulogin.conf
<asmcos> I write a test.conf :start on logined,
<asmcos> test.conf don't work
<asmcos> start on starting sulogin , test.conf work.
<asmcos> problem at "emits" ??
<asmcos> hi Md
#upstart 2010-11-27
<asmcos> hi all
<asmcos> i have a question.
#upstart 2010-11-28
<jetienne_> q. in a config script of a service, can i do "if this daemon crash or stop running, relaunch it" ? if so how ?
<Stevee> just add a simple "respawn" to your job file
<jetienne_> Stevee: thanks
<Stevee> np
#upstart 2011-11-21
<zyga> hi
<zyga> I need to shut down uwsgi server from upstart, the problem is that the server expects SIGQUIT, not SIGTERM
<zyga> I have not found a way to configure the signal sent by upstart so I'm trying to achieve the same with pre-stop script
<zyga> how can I know the PID of the main task from the pre-stop script?
<zyga> jhunt_, ping
<zyga> jhunt_, ping
<jhunt_> zyga: hi
<zyga> jhunt_, can I have one job say "start on starting master-job INSTANCE=$INSTANCE"
<zyga> jhunt_, I have instances everywhere
<zyga> jhunt_, I wanted to have one master job per instance
<jhunt_> zyga: have you seen http://upstart.ubuntu.com/cookbook/#instance ?
<zyga> jhunt_, then a few actual jobs with daemons/processes that do particular aspect of that instance
<zyga> jhunt_, I read the cookbook (still staring at it)
<zyga> jhunt_, it just that it does not work in practice when I try
<zyga> jhunt_, note, I'm not starting any jobs from master-job (like the cookbook example did with script section)
<zyga> jhunt_, because that made my master-job not an abstract job (so something I could no longer stop)
<jhunt_> zyga: you can do what you are trying to do there, but have you specified "instance $INSTANCE"?
<zyga> yes
<zyga> w8
<zyga> (thunderstorm, flooding workplace)
<zyga> http://paste.ubuntu.com/745154/
<zyga> http://paste.ubuntu.com/745155/
<zyga> jhunt_, ^^
<zyga> jhunt_, I'm somewhat unsure on how variable expansion happens in upstart
<jhunt_> zyga: you don't have any "start on" so that job will only start if you run "start <job>".
<zyga> the problem is with uwsgi worker job
<zyga> there is another task that starts lava-instance
<zyga> and that works
<zyga> start on starting lava-instance INSTANCE=$INSTANCE
<zyga> this line, from the latter pastebin, seems not to work
<zyga> essentially I want to say "when lava-instance with the same instance identifier as myself is starting, start me"
<jhunt_> zyga: I think you might be missing an "export INSTANCE" in lava-instance.conf
<zyga> oh, 
<zyga> let me see, that would make sense
<zyga> jhunt_, I added "export INSTANCE" to lava-instance.conf
<zyga> jhunt_, it did not work (the lava-instance-uwsgi task never started)
<zyga> do I need to say env INSTANCE=$INSTANCE
<zyga> and then export INSTANCE?
<zyga> and does the order of declarations matter?
<jhunt_> zyga: the order nominally does not matter (unless you specify the same stanza twice, in which case the last instance "wins").
<jhunt_> zyga: ah - I think the problem is that you are setting INSTANCE, but that is one of Upstarts variables (http://upstart.ubuntu.com/cookbook/#standard-environment-variables).
<jhunt_> You should be doing something like "instance $FOO" such that INSTANCE will automatically be set to the value of $FOO.
<zyga> ah
<zyga> thanks, let me see how that works then
<zyga> now to think of a good alternative to INSTANCE
<zyga> still nothing
<zyga> let me give you all the upstart files I have
<zyga> root@limpy:/etc/init# pastebinit /etc/init/lava.conf
<zyga> http://paste.ubuntu.com/745162/
<zyga> root@limpy:/etc/init# pastebinit /etc/init/lava-instances.conf
<zyga> http://paste.ubuntu.com/745163/
<zyga> root@limpy:/etc/init# pastebinit /etc/init/lava-instance.conf 
<zyga> http://paste.ubuntu.com/745164/
<zyga> root@limpy:/etc/init# pastebinit /etc/init/lava-instance-uwsgi.conf 
<zyga> http://paste.ubuntu.com/745165/
<zyga> jhunt_, the syslog output of 'start lava' is:
<zyga> Nov 21 15:43:16 limpy logger: LAVA instance (lava) starting...
<zyga> Nov 21 15:43:16 limpy logger: LAVA instance (lava) started
<zyga> Nov 21 15:43:16 limpy logger: Staring LAVA (all instances)
<zyga> so it never touched the lava-instance-uwsgi.conf job
<zyga> jhunt_, any ideas?
<zyga> jhunt_, I managed to resolve the problem
<SpamapS> zyga: start on starting lava-instance LAVA_INSTANCE=$LAVA_INSTANCE ...
<SpamapS> zyga: that can't match, because $LAVA_INSTANCE == "" at that point
<SpamapS> zyga: I think what you want is just start on starting lava-instance
<SpamapS> zyga: then $LAVA_INSTANCE will be picked up because of the export LAVA_INSTANCE in lava-instance.conf
<zyga> roght
<zyga> right
<zyga> that's what I did
<zyga> now it works
<zyga> I have not tested it with multiple instances (still hacking other parts of lava)
<zyga> but that works now
<zyga> SpamapS, so you are correct
<zyga> :-)
<zyga> lava will have about 10 jobs total
<zyga> it could be nice example on how to use various parts of upstart
<zyga> btw, I think I found a bug, have not investigated deeper yet but "env PATH=/srv/lava/bin:$PATH" makes upstart reject the job somehow
#upstart 2011-11-22
<ZBandit> Since upstart apparently is now default in CentOS 6 (RHEL6) how does one make the autologin with only on one TTY?
<ZBandit> Never mind, figured it out on me own.
<lucs> I'm trying to get something working with upstart and I currently have a situation where "initctl status foo" responds with "foo stop/killed, process 3574"
<lucs> Yet, there is no process 3574, and I seem to be stuck there.
<lucs> (I think the situation was caused by a mistaken "expect" stanza.)
<jhunt> lucs: more than likely. Take a read of the newly updated section in the cookbook - http://upstart.ubuntu.com/cookbook/#expect.
<jhunt> lucs: also note the golden rule - don't use "respawn" until you are sure you have correctly specified "expect".
<lucs> jhunt: Yes, thanks, I'm there already (re. the cookbook).
<lucs> Right now, I'm wondering how I can get back to a "clean" state.
<jhunt> lucs: if initctl / status is hanging, control-C it. If it's not actually hanging, but is reporting incorrect information, I'm afraid you'll have to reboot to get Upstart to clear its knowledge of that job. What you *can* do if you're on a dev box is to copy the .conf file to a new name and "try again".
<jhunt> lucs: we're going to be looking into this issue for this (Ubuntu) cycle. It's quite a hard problem to solve though unfortunately.
<lucs> jhunt: Ah, I was kind of afraid I'd need to reboot, but there it is :)
<lucs> Yeah, it's a dev machine, so I can experiment all I want.
<jhunt> lucs: well, unfortunately, Upstart is powerless in this scenario right now as if the expect stanza is mis-specified there is no reasonable error recovery it can perform.
<lucs> Oh, copying the .conf and retrying is a good idea, thanks.
<lucs> jhunt: Ok, thanks for the info.
<jhunt> lucs: np.
<lucs> (Note to self: in "script" sections, don't declare environment variables with "env", unless you want to waste _a lot_ of time :-/ )
<jhunt> lucs: ah! :) http://upstart.ubuntu.com/cookbook/#init-checkconf is your friend
<jhunt> lucs: actually, that wouldn't have helped as of course 'env' *is* valid in shell, but not in the context you were using it in.
<lucs> jhunt: By the way, all my problems went away when I got rid of the faulty 'env's.
<jhunt> lucs: I'd be interested to see your .conf. Certainly sounds like a script process was aborting but Upstart was attempting to "follow forks" still.
<lucs> jhunt: I have many failing variations, basically all with "script \n env FOO=some_command args... \n exec $FOO \n end script".
<lucs> (sorry, was talking to a cow-orker).
<lucs> So FOO was empty, and a plain 'exec' was being done (I suppose).
<lucs> Time for a reboot.
<lucs> jhunt: Thanks again.
<jhunt> lucs: thanks for the info. I'll ponder this for future cookbook updates.
<lucs> upstart++
<lucs> jhunt: Nice cookbook too.
<jhunt> lucs: still lots to add when time allows :)
<lucs> :)
#upstart 2011-11-23
<scoopex> it seems that there is a buggy upstart script for apache in ubuntu/11.10...boot.log just shows "Starting web server - failed"....if i start it manually it works perfectly....how can i debug the reason for "failed" ?
<jhunt_> scoopex: apache is a SysV service - /etc/init.d/apache2
<scoopex> i discovered the reason for this....apache trys to include the config from a nfs-share....the script contains the following lsb-tags "Required-Start:    $local_fs $remote_fs $network $syslog $named"....this is outside of upstart control, right?
<jhunt_> scoopex: yes - apache2 is a SysV package. It really needs to be "upstartified" :)
<scoopex> it seems that the sysv-compatibility mode ignores the lsb-dependencies....
<SpamapS> scoopex: indeed, those can't be resolved because some are satisfied by upstart jobs
<SpamapS> jhunt: I wonder if we shouldn't just have an upstart job that uses apachectl in pre-start/post-stop and doesn't track apache's pids.
<scoopex> SpamapS: what about the the useful arguements? graceful-stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean|status
<scoopex> admins really need this :-)
<SpamapS> scoopex: apachectl isn't going anywhere
<SpamapS> scoopex: (which is where you were *supposed* to be calling those.. ;)
#upstart 2011-11-25
<lericson> Guys, it would be helpful if upstart didn't ignore jobs with whitespace-only lines in them.
<jhunt> lericson: ?
<lericson> I don't have much further to add, this might be fixed in the latest version.
<lericson> echo -e 'stop on runlevel [016]\n \nrespawn\nexec wait 100' >job.conf
<lericson> should trigger it
<lericson> apparently not
<lericson> ok i don't really know what triggers it
<lericson> this commit fixed it for me http://pb.lericson.se/p/BhCOQm/
<jhunt> lericson: ? that change shouldn't make any difference.
<lericson> wellp it did
<lericson> also why can't I symlink job descriptions?
<lericson> would be very convenient as we check our source out in /usr/local/share/
<lericson> guess I could hardlink but that seems like the wrong kind of solution here
<jhunt> lericson: http://upstart.ubuntu.com/cookbook/#symbolic-links-don-t-work-in-etc-init
<jhunt> lericson: please could you raise a bug if the whitespace behaviour you are seeing is repeatable.
<lericson> I am convinced, thank you
<jhunt> the latest version of upstart does provide a --confdir=/usr/local/share but use at your own risk.
<jhunt> also, you *could* make /etc/init/ a symbolic link to /usr/local/share, but again, you get to keep the pieces if your system breaks :)
<lericson> not doing that, thank you very much :D
<lericson> perhaps I should just make it part of my deploy step to copy new configuration files
<SpamapS> lericson: that sounds like a plan
#upstart 2011-11-27
<statim> hey guys, this is probably a dumb question but i cant wrap my head around how this works: http://pastie.org/private/z8biw4h8ddsoth4oe7iw i can see how it will "start" mongod, but what i dont understand is how it knows what to do to stop it
<broder> statim: "stop on runlevel [06]"?
<statim> broder:  right, but what does it execute to stop it?
<statim> i only see a script for starting it
<broder> statim: it keeps track of the process that gets started and kills it
<broder> (well, sigterms it)
<statim> oh i see.  so unlike init.d scripts it just needs to know how to start it, then the rest is process managed by upstart
<broder> yes. that's why the "expect" stanzas are so important when you create a new job
<statim> broder, and is restart provided automatically by this as well? or what if there was a specific signal the program new to use to restart itself like USR1?
<statim> knew*
<broder> "reload" is SIGHUP
<broder> "restart" is equivalent to "stop; start" iirc
<statim> ok cool
<ion> restart isnât equivalent to stop; start.
<ion> See restart(8)
<broder> ah right. it's like "stop; don't-read-the-new-config; start" :)
<statim> does 'instance' really work? ive got instance JOB_1 in script1, instance JOB_2 in script2, but launch the same executable with different ports.  but it seems they still conflict even with the different instance names given to them
<statim> ah nm, it looks like it was actually start-stop-daemon that was not allowing the second instance, not upstart.  gave unique pidfile options to each start-stop-daemon and now it works
<broder> statim: instances are for starting a single job multiple times. upstart never needs instances for two distinct jobs
<JanC> right, and the instance names could be used to create a unique pidfile
<JanC> using "instance $PORT" or something like that
<JanC> and using $PORT to provide the necessary options to the program and to start-stop-daemon
<statim> hey guys i have a job that remains at stop/killed, process 4930. that pid isnt running any more, and i cleaned out everything i can think of to get it back to a clean state, but it still keeps that status.  is there a way to 'reset' it?
<ion> Itâs easy to get the current version of Upstart confused by lying to it about the forking behavior of the main process with âexpectâ. If you donât want to reboot, run workaround-upstart-snafu 4930. http://heh.fi/tmp/workaround-upstart-snafu
<ion> A future version will be more robust in that regard.
#upstart 2012-11-19
<stgraber> jodh: hmm, one point I just noticed in the spec that I'm not too sure about is the D-Bus section on having the user upstart listen on /com/ubuntu/upstart-session/$user
<stgraber> jodh: I see why we need that so initctl can work until we get a working dbus session
<stgraber> jodh: but the fact that it's not unique per session is a bit problematic
<stgraber> jodh: would it work if we use /com/ubuntu/upstart-session/$PID (where $PID is the pid of the user upstart) and export a UPSTART_SESSION environment variable to all children containing the path?
<stgraber> jodh: it's really only going to be useful for the dbus job as it's likely going to be the only one that'll need to talk directly to upstart as any job after that will be able to use the session bus
<stgraber> jodh, xnox: alright, I think I'm done with https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions
<stgraber> feel free to do any additional edits. I'm out to get some food, I'm starving ;)
<xnox> stgraber: thanks. I will look through your edits =)
<LeoSh> is there a special way to do a sudo entry to allow a normal user to restart a service?
<LeoSh> when I do something like: "/usr/sbin/service uwsgi *" that doesn't work... I get: /usr/sbin/service: 123: exec: status: not found
<LeoSh> for the command "sudo service uwsgi status"
<JanC> LeoSh: what do you mean by "normal user"?
<JanC> (also, this sounds like a sudo question, not an upstart question?)
<JanC> http://manpages.ubuntu.com/sudoers explains sudo configuration
<LeoSh> @JanC: not root
<LeoSh> I suspect it's more of an upstart question, or at least one upstart users have run into
<LeoSh> the other strange detail is when I do 'service uwsgi' I get 'uwsgi: unrecognized service'
<LeoSh> even though there's a uwsgi.conf in /etc/init/ and it looks like it's all properly formatted (and 'service uwsgi restart' works without any problems)
<JanC> not every non-root user has the same rights when using sudo
<JanC> LeoSh: what if you use initctl ?
<LeoSh> 'initctl status uwsgi' works fine
<LeoSh> I'm not sure how to do an equivalent of 'service uwsgi' with initctl since it takes the command first
<JanC> from the manpage of 'service', that is not a legal use of the service command?
<JanC> it mentions "service SCRIPT COMMAND [OPTIONS]"
<JanC> which means the command is mandatory?
<JanC> unless you are using a different "service" command than I do
<LeoSh> hmm
<LeoSh> that's a good point
<LeoSh> I'm on Ubuntu 12.04
<JanC> I'm on Ubuntu 12.10 right now, but I'm pretty sure 'service' worked the same there
<LeoSh> ok, so 'unrecognized service' is probabl unrelated to my actual issue
<JanC> http://manpages.ubuntu.com/manpages/precise/en/man8/service.8.html
<LeoSh> is there a way to control who is allowed to restart a service through upstart?
<JanC> http://manpages.ubuntu.com/manpages/precise/en/man5/sudoers.5.html   âº
<LeoSh> yeah, that leads me to the original question :-/
<LeoSh> the sudoers config I used works for an init.d script
<LeoSh> but doesn't seem to work for my upstart .conf
<JanC> (there are examples at the end of the manpage)
<JanC> the sudoers file only cares about users, groups & command lines AFAIK
<LeoSh> hmm
<LeoSh> do I need to open up the other commands in sudoers? (ie. /sbin/start, /sbin/stop, etc.?)
<JanC> only if you want to use them like that?
<LeoSh> I don't, but looking at the error
<LeoSh> it refers to /usr/sbin/service:123
<JanC> hm, maybe think about how you define it and how you use it?
<LeoSh> which attempts to exec the action: exec ${ACTION} ${SERVICE} ${OPTIONS}
<LeoSh> and that's what fails
<JanC> well, you run service with sudo, right?
<LeoSh> yes
<LeoSh> I get the following if I just try to do "status" as my non-priv user: Command 'status' is available in '/sbin/status'
<JanC> if you execute it without an "action", that would probably fail
<LeoSh> and that it can't be located
<LeoSh> which is strange, since it should be running as root rather than the nonpriv user
<LeoSh> but it explains why the init.d version works fine
<LeoSh> it doesn't try to invoke another binary that the nonpriv user doesn't have access to
<LeoSh> is there some really good reason to not add sbin to your path?
<LeoSh> as a nonpriveleged user?
<JanC> well, if $ACTION is empty, that would certainly confuse $SERVICE being called as the main application?
<JanC> if hey have no proper checking in place  :p
<JanC> if they*
<LeoSh> here's the core problem
<LeoSh> 'service' is in/usr/bin and 'start' and it's kin are over in /sbin
<JanC> if you run 'service' as root (using sudo or otherwise) that shouldn't be a problem
<LeoSh> I do, but it still is
<LeoSh> I think the PATH of the user remains even when you sudo
<JanC> that depends on sudo options, but possibly, yes
<LeoSh> ok, yeah, the sudoers file has 'Defaults env_reset' which is recommended...
<JanC> LeoSh: I don't have the time to investigate right now, but AFAIK sudo allows you to override that
<LeoSh> JanC: yeah, I appreciate the help, I'm digging into it
<LeoSh> apparently the setting comes from some unholy mix of login.defs and pam config
#upstart 2012-11-20
<stgraber> jodh: so far no feedback is good feedback I guess? :) I saw you made a bunch of edits to the wiki page, will quickly go through them in a minute.
<jodh> stgraber: just one comment so far (to upstart-devel only): https://lists.ubuntu.com/archives/upstart-devel/2012-November/001988.html
<stgraber> jodh: ah, I guess I should subscribe to upstart-devel ;)
<stgraber> jodh: I'm not sure I really see the point of having public and private events considering that the effect on the system will be public anyway (and anything passing on the system bus is public)
<stgraber> jodh: but if that becomes useful, I guess we can always implement a :sysprivate: namespace for those
<jodh> stgraber: the problem is that if we don't have public/private events, a user job may 'accidentially' change state based on a system event. Hence, it would be convenience if the user had to choice of either having a job react to a named event from any source, or only react if its a system event, or only react if its a user event.
<stgraber> jodh: right, but the current design does that. You can simply do "start on :user:dbus" to only react to the dbus job of the user instance of upstart
<stgraber> jodh: My interpretation of Evan's e-mail is that he wants to add some private/public flag to "initctl emit" so that if you do "initctl emit blah" against the system upstart the event won't be sent to the session instances
<stgraber> jodh: but that you'd have to explicitly do "initctl emit :all:blah" to have it be sent to the instances
<jodh> stgraber: right - I think we were talking "cross-purposes" there - I though you were saying we didn't need :user: and :sys:. Just replying to his mail...
<stgraber> stgraber@arkose-tmpCXgHdn:~/Desktop/upstart$ ./test 
<stgraber> Got a change: /org/gnome/nautilus/desktop/volumes-visible
<stgraber> jodh: ^ :)
<stgraber> using the dconf API to get any gsettings change. Now I just need to decode the new value and plug that thing into an upstart bridge (figured it'd be a reasonable way to refresh my memory on nih/upstart coding)
<jodh> stgraber: awesome! ;)
<stgraber> jodh: monitoring dconf is really quite easy :) http://paste.ubuntu.com/1372844/
<jodh> stgraber: nice :)
<stgraber> jodh: oh, one thing that'll be fun in the dconf bridge is that I'll need both libnih and glib, need to figure out what to do with the main loop :)
<SpamapS> stgraber: out of the question to have two processes?
<stgraber> SpamapS: well, ideally I'd like the dconf bridge to be a single process. The only real source of events will be on the glib side, so I'm trying to avoid the nih main loop entirely for now, if that doesn't work, I'll probably just end up replacing nih by glib for that bridge and glib-dbus instead of nih-dbus
#upstart 2012-11-21
<toabctl> stgraber, I recognized that you implemented a dconf bridge for upstart. what's the reason for that?
<xnox> toabctl: https://lists.ubuntu.com/archives/upstart-devel/2012-November/001987.html
<toabctl> xnox, so user session daemon should be started when a dconf key changes, right?
<toabctl> that's a possible usecase?
<xnox> toabctl: no.
<xnox> toabctl: well yes.
<xnox> toabctl: e.g. upstart runs the use session, and user jobs can listen to dconf events and do start on stop on.
<xnox> etc.
<toabctl> ok
<xnox> toabctl: so yes =)))) but it's for any dconf events.
<xnox> s/use/user/
<toabctl> sure
<toabctl> what about other daemons? eg NetworkManager?
<toabctl> maybe you want to start a job when NetworkManager sends an event.
<toabctl> eg a firewall script, ...
<jodh> toabctl: we already emit net-device-up and net-device-down. See upstart-events(7)
<jodh> toabctl: that said, we could expand the variables set in those events to include things like ESSID say.
<toabctl> jodh, but more detailed events. eg "vpn-connected"
<jodh> toabctl: please raise a bug so we can consider it
<toabctl> jodh, I don't need this. I just want to get a picture where the border between upstart and other system daemons is
<toabctl> I guess you could build a bridge between every system daemon and upstart which has something like signals/event and map that to upstart jobs/tasks
<jodh> toabctl: any system facility is free to emit upstart events. We're trying to add events where appropriate to allow jobs to react in the most efficient manner to system state changes.
<jodh> toabctl: yes, but we don't want hundreds of bridges running. We are planning dconf, temporal events (a la cron), inotify events for file changes and a generic dbus bridge would probably give user 99% of what they need
<toabctl> jodh, sounds good.
#upstart 2012-11-22
<toabctl> stgraber, my did you use dbus-glib instead of gdbus for the upstart-dbus-bridge code? is there any reason for that?
<xnox> toabctl: what is the package name?
 * xnox can't find gdbus in the archive
<toabctl> xnox, gdbus is from glib/gio
<toabctl> xnox, see http://developer.gnome.org/gio/2.32/gdbus-convenience.html
<toabctl> xnox, it's the prefered way in the glib/gtk/gnome world to write dbus clients
<toabctl> xnox, and see http://www.freedesktop.org/wiki/Software/DBusBindings
<toabctl> dbus-glib is obsolete
<xnox> stgraber: and the ^^^ is available in python2&3 via from gi.repository import Gio
<xnox> toabctl: to be honest, I had no clue & I have a package written in dbus-glib.
<xnox> no clue about gdbus, that is.
<stgraber> toabctl: I didn't know it existed ;)
<toabctl> :-)
<toabctl> xnox, for python, the dbus server support does not work with introspection. ask pitti about that.
<xnox> *sigh*
<toabctl> xnox, but I think the python-dbus package works now with python 2&3
<toabctl> stgraber, you should definitly switch to gdbus
<stgraber> toabctl: yep, will do, should be easy enough
<toabctl> stgraber, here's a migration guide: http://developer.gnome.org/gio/2.32/ch30.html
<toabctl> I ported d-feet from python-dbus to gdbus (with introspection) and it works very well.
 * xnox is not that good with dbus
<xnox> toabctl: what do you mean by "dbus server support"
<xnox> or in other words is gdbus good enough for both publishing & using objects over dbus?
<toabctl> xnox, you can not create a service (eg "com.foo.bar") on the bus with gdbus and python
<xnox> toabctl: that sucks.
<toabctl> xnox, yes, it is. but not the python introspection stuff
<xnox> not good for me then =(
<toabctl> xnox, see http://www.piware.de/2011/01/na-zdravi-pygi/#comment-2010
<toabctl> xnox, but just in python it does not work. In C, all works fine
<toabctl> xnox, here's the bug: https://bugzilla.gnome.org/show_bug.cgi?id=656330
<xnox> thanks.
<toabctl> np
#upstart 2012-11-24
<zhilbert> I am trying to modify an upstart job config file so it starts an instance of for each config file in a directory, but I can only get it to start one instance of the daemon. can anyone help?
#upstart 2012-11-25
<SpamapS> zhilbert: you need 2 jobs to do that
<SpamapS> zhilbert: one to iterate over the files in the dir, the other to be the actually running instances
<zhilbert> Thanks SpamapS.  I've got that part working. I think my issues are with daemon not with upstart. 
<shaz_> hey, so I have a python daemon based on: http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/
<shaz_> and the following upstart script
<shaz_> http://pastebin.com/qvkJqAuC
<shaz_> but it is hanging when i start/stop
<shaz_> i've tried with combinations of expect /fork/daemon but nothing seems to work
<shaz_> any ideas?
<shaz_> i have checked the command works normally in the terminal
<shaz_> so I am thinking its something to do with my upstart config
<SpamapS> shaz_: that upstart config should return as soon as python is executed
<SpamapS> shaz_: rather, 'starting' that upstart job
<SpamapS> shaz_: however, the daemonize code you posted wants 'expect daemon'
<SpamapS> shaz_: can you be more clear when you say "it is hanging" ?
<shaz_> I mean it doesn't ever return
<shaz_> as if you were running the blocking script in the terminal
<shaz_> i've just tried it with expect daemon
<shaz_> and it still does the same
<shaz_> I am doing all of this over ssh, if that makes a difference
<SpamapS> shaz_: it does not make a difference no
<SpamapS> shaz_: can you pastebin the output of 'strace -e trace=process -f /home/ubuntu/LoudPopcorn/venv/bin/python /home/ubuntu/LoudPopcorn/TwitterClient/streaming.py' ?
<shaz_> sure, give me a sec
<shaz_> http://pastebin.com/3NbCfpdF
<SpamapS> shaz_: for the record, the upstart job you pasted makes it nearly impossible for 'start ...' to block.. because upstart will consider the job started immediately upon executing python
<SpamapS> shaz_: any chance you have a 'start on starting that-jobs-name' in some other job that blocks?
<shaz_> no i don't have that in any other scripts
<SpamapS> shaz_: interesting. I think virtualenv may make using 'expect ...' impossible because of all the stuff it has to fork and exec first
<SpamapS> shaz_: in this case, I'd suggest having a --nodaemonize mode for your code, and just let upstart manage it in the foreground
<SpamapS> shaz_: also its worth noting that you need a 'setgid ubuntu' also.. 
<shaz_> ok, i will give that a go.
<shaz_> ok
<SpamapS> shaz_: also its worth nothing that if this is a cloud instance, you should *NOT* run code as ubuntu (it has sudo w/o password)
<shaz_> um, same thing when i run without daemon
<shaz_> (without expect daemon)
<SpamapS> shaz_: try 'sudo initctl log-priority info' ... note the last line in syslog, and then run the 'start' and then pastebin the lines produced by 'init:' in syslog
#upstart 2013-11-18
<Redoubt> SpamapS: Not sure what timezone you're in. You around?
#upstart 2013-11-20
<stgraber> jodh, slangasek, xnox: there you go, cgroup proposal sent to the ML
<jodh> stgraber: thanks!!
<xnox> stgraber: \o/
<stgraber> the only tricky bits for upstart should be the tear down when the job stops (as it has to check for sub-cgroups and existing tasks). Everything else should be as easy as parsing the cgroup stanza as a nih_list, iterating through it, replacing $auto by some relevant value and doing direct calls to the manager
<stgraber> no extra parsing should be required, the manager will do all the checks and return a failure code if something's off
<stgraber> xnox: hey, shouldn't libnih-dbus-dev depend on libdbus-1-dev?
<stgraber> I'm writing a small dbus daemon as an example for hallyn and noticed that I was missing some headers ;)
<xnox> stgraber: according to pkg-config file it doesn't need it. but in practice it links against and uses headers from dbus. so yeah, it needs both fixing .pc file and dependencies. 
<xnox> stgraber: you want to fix it, or should I ?
<stgraber> feel free :)
<xnox> stgraber: ok.
<stgraber> xnox: https://github.com/stgraber/cgmanager is the minimal dbus server+service I wrote. Nih really makes this easy once you've spent an hour going through its code to figure out how that's all supposed to work :)
<xnox> lol =) yeah.
<xnox> stgraber: the dbus stuff, and especially dbus-tests are the most twisted parts of libnih imho.
<stgraber> having had to debug the code generator a couple of times for upstart, I can certainly agree with that ;)
<xnox> stgraber: =)))) i'm glad you did that ;-)
<stgraber> also the test suite is a major pain because a single char change in the code generator means hours of fun tweaking all the tests ;)
<xnox> stgraber: i should finish up fixing the bugs in doc-comments and finally generate and publish libnih & upstart gtkdocs.
<xnox> there are more and more libnih users now in the archive.
<slangasek> xnox: does "needs review" on https://code.launchpad.net/~xnox/upstart/kfreebsd/+merge/196028 mean you're not ready for review yet?
<slangasek> xnox: er, rather, "work in progress"
<xnox> slangasek: it's not ready for review yet. some pieces are useful refactoring, but overall it doesn't pass tests nor compile on kfreebsd yet.
<xnox> slangasek: thus at this point this is a standing merge-proposal for me to notice/check for bit-rot & merge conflicts.
<slangasek> ok
<xnox> slangasek: i'm not sure what to do with libnih yet. I will stub out missing nih_watch api for now & it would be ready to be merged upstream...... although keybuk hasn't been receptive of a kfreebsd port yet.
 * slangasek nods
<slangasek> speaking of which, 13h to my libnih NMU. http://ftp-master.debian.org/deferred.html
<xnox> slangasek: second nmu. the first one is not merged upstream, although i believe i've addressed the review knit-picks (w.r.t. style and formatting) 
<xnox> https://github.com/keybuk/libnih/pull/2 
<stgraber> xnox: no luck with something like libinotify-kqueue?
<stgraber> oh I guess you considered it since you uploaded it to Debian ;)
<xnox> stgraber: yeah, it fails libnih test-suite with fire =)
<xnox> stgraber: cjwatson suggested to get inspiration from glib/gio code as it does alternate between inotify & kqueue/kevents
<xnox> and that would be my next move.
#upstart 2013-11-21
<Mr_K> Hello! I'm trying to keep track of why an upstart service of mine is stopping/restarting i.e. whether it was restarted by a user via initctl or the underlying program crashed. My first thought was to use the pre-stop stanza to detect intentional restarts, but there is a bug with the pre-stop stanza that breaks `initctl restart` (https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/703800). Does anyone know
<Mr_K> of a upstart-related work-around for this?
#upstart 2013-11-23
<shutej> when does cloud-init try to execute an upstart job it has loaded?  after cloud-config does its thing?  (12.04.3)
#upstart 2013-11-24
<joelteon> how do I make a service start at boot?
<xnox> joelteon: specify start on condition, see cookbook http://upstart.ubuntu.com/cookbook/. something like "start on runlevel [2345]" should do it.
<joelteon> hmmm
<joelteon> okay
<joelteon> so if you have normal conditions *and* a runlevel condition, is that bad?
#upstart 2014-11-17
<sokmar> hi, is there a way to reset the state of a job that's stuck in /starting state? start and stop can only get it between start/starting and stop/starting; upstart 1.12.1
#upstart 2014-11-20
<jgornick> Hey guys, is it possible to setup my upstart script to do a core dump and automatically restart if a service faults?
#upstart 2014-11-23
<astropirate> hello friends
<astropirate> I didn't know this channel existed :)
<astropirate> How does upstart actually stop a process? What signal does it send to the process to have it stop?
<astropirate> nvm figured it out
#upstart 2015-11-17
<akkad> for some reason start launches the app, but upstart loses track of it, and thinks it did not start properly
<akkad> how do you clear the status of a job that has a pid listed that does not exist and has not existed in a long time?
