#upstart 2007-03-21
* Starting logfile irclogs/upstart.log
<Keybuk> I thought of a much more sick way of dealing with pre-requisite mountpoints :p
<_ion> Cool!
<_ion> Oh, i misread it as "slick" :-D
<Keybuk> lay a tmpfs over the root filesystem using unionfs 
<Keybuk> make the mount point directories on it
<Keybuk> then you can always mount them :p
<Keybuk> (actually, you can get away with just requiring that mount point directories always exist on the root filesystem)
<_ion> script
<_ion>     mkdir -p "$mountpoint"; mount "$mountpoint"
<_ion> end script
<_ion> ? :-)
<Keybuk> only works if you wait until the root filesystem is writable before mounting under it
<Keybuk> and you'd need to use the same bind-mount trick as Ubuntu does for /var/run and /var/lock
<Keybuk> (which has the advantage that when you unmount /usr, /usr/local is still mounted <g>)
<Keybuk> needs much locking to work too <g>
<Keybuk> very sick
<_ion> :-)
<_ion> Yeah, dbus would be really nice instead of whatd, but it would need to 'start on startup'.
<Keybuk> don't Fedora already do that/
<_ion> I have no idea.
<_ion> If it's plausible that distributions using libwhat would actually do that, dbus would be the obvious solution.
<_ion> I added a note about dbus to the page.
<_ion> I added a usplash mockup to http://johan.kiviniemi.name/blag/2007/03/21/upstart-and-interaction-with-user/
<AlexExtreme> looks interesting
<AlexExtreme> I'm still not keen on the idea of using DBUS thought
* AlexExtreme is rather skeptic of using DBUS as a core system component
<_ion> It has some pros and a bunch of cons.
<AlexExtreme> yes, it does have some pros because it provides an easily available IPC protocol, but IMO the cons outweigh the pros
#upstart 2007-03-22
* Starting logfile irclogs/upstart.log
<sadlede1> mbiebl: hi, how are you planning to integrate replacement-initscripts into debian when they get used in ubuntu?
<mbiebl> sure, I'm already working on them ;-)
<mbiebl> sorry, but I have to run now...
<mbiebl> cu later
<fatal> about interaction with user.... why would anyone want to do that during boot?
<Keybuk> retrieving keys for encrypted filesystems
<Keybuk> (or Apache SSL passphrases)
<Keybuk> driving fsck responses
<fatal> why not provide that on the boot command line?
<fatal> I wouldn't want my bootup to halt on some stupid question...
<fatal> guess you could define some base services that shouldn't ask any question to get around that though.
<Keybuk> some people do want their boot to halt though
<Keybuk> though heres a thought ... pre-seeding answers to questions ;p
<_ion> "Yo Linux! If something in the boot asks whether i want to fix inode 46837, the answer is yes."
<Keybuk> or "just fix every damned fsck thing"
<Keybuk> (who doesn't hold down the "Y" key until fsck goes away? :p)
<Keybuk> "no, actually, I don't want to fix my filesystem)
<_ion> I *always* set FSCKFIX=yes
<_ion> If we were evil enough, we could use libwhat to let the user input her login and password before gdm is started. :-)
<fatal> seems like you're on the same track as me.... you don't want questions during bootup. ;P
<fatal> "just do the right thing"<tm> :)
<fatal> encrypted partitions might be a separate issue.... still I'd rather have the answer provided from the start and no questions asked... (or extend grub to ask questions if something more "user friendly" is needed. I guess grub could even be smart about it... grub reads filesystems already, no? Could check /etc/fstab on the fly if any key is needed... or if the root partition needs would know that as well when trying to access it?)
<fatal> not sure about apache / ssl-keys ... why would you want to auto-start something that can't be auto-started?
<sadlede1> _ion: or just start gdm on a framebuffer ;-)
<Keybuk> gdm takes ages to start
<sadlede1> Keybuk: sure, just kidding
<pkt_> well, qingy is a framebuffer getty and it is themeable and whatnot
<pkt_> if you want a framebuffer screen for logging in this is much better than nihing your own
<_ion> fatal: If i were using an encrypted partition or apache with a password-protected SSL key, i'd definitely want to be queried for the passwords.
<_ion> keybuk: Btw, any new progress with the delayed watch stuff?
<Keybuk> _ion: none, I have a half merge in my working branch
<Keybuk> it's been a busy week
<Keybuk> lots of CVs to read :-/
<_ion> Alright.
<sadlede1> mbiebl: i found your upstart-jobs branch
<mbiebl> hehe, that's not yet ready for public use though.
<sadlede1> mbiebl: how are you going to push that into debian? will the jobs be in the indiviual packages?
<mbiebl> That's my long term goal, yes.
<sadlede1> mbiebl: sure, i'm just curious how the process will be
<mbiebl> Short term, I will ship the upstart jobs for the most important packages myself.
<mbiebl> Upon installation of the upstart-jobs package, I will scan which packages are currently installed, deactivate the sysv init script and activate the corresponding upstart job.
<mbiebl> If I have a working set of native upstart jobs, I will start to ping the individual package maintainers and ask for them to include these files directly.
<mbiebl> As I'm (co)-maintainer of dbus/hal/dhcdbd/network-manager I can do that for these packages directly.
<mbiebl> (avahi-daemon too)
<sadlede1> ok, so packages will provide both a sysv script and an upstart job
<sadlede1> mbiebl: so i'm very much looking forward to using the first round of debian upstart-jobs
<mbiebl> If you're willing to test them and give me feedback, that would be great.
<sadlede1> do you run the jobs from upstart-jobs?
<mbiebl> Maybe I have something working around mid next week.
<mbiebl> http://pastebin.ca/406556
<mbiebl> So, basically the rc2.d/multiuser part is upstartified already.
<sadlede1> wow!
<sadlede1> btw, shouldn't avahi-daemon do the .local check from the sysvrc script?
<sadlede1> policykit is not yet in debian, is it?
<mbiebl> I'm currently packaging it for experimental while preparting hal-0.5.9 packages.
<mbiebl> Its in the pkg-utopia svn
<mbiebl> Something to wet your appetite:
<mbiebl> http://debs.michaelbiebl.de/upstart/bootchart.png
<sadlede1> oh dear!
<mbiebl> around 15 sec the fully upstartified boot process kicks in.
<sadlede1> oh yes, that point isn't hard to find ;-)
<mbiebl> cu later
<sadlede1> and the first part will be fast as well
<sadlede1> ok, cu
<tale_> can upstart detect docking events?
<Keybuk> tale_: was just about to reply to your e-mail ... :)
<Keybuk> Upstart doesn't detect anything itself, it relies on things like udev, HAL, GNOME Power Manager, etc. to do all of the detection and handling
<Keybuk> those processes request an upstart event be emitted through libupstart or the "initctl emit" tool
<Keybuk> so provided you've got something already that can detect a docking event, it's just a matter of making it send an event to upstart
<Keybuk> at which point upstart will start and stop services
<Keybuk> the only events that upstart emits itself are "startup" and those due to jobs changing states
<tale_> Keybuk, yeah I didn't notice the irc group until I had sent that email.
<tale_> Keybuk, I'll do some more investigating to see how it is detected.   I know it can be detected because there is a script that can be setup, but from what I hear it's not trival.  This should work out of the box.
* Starting logfile irclogs/upstart.log
<AlexExtreme> mbiebl, could you point me to your upstart jobs for debian sometime, i'd like to see what you're using there
<AlexExtreme> brb, dinner
<mbiebl> AlexExtreme: They are not ready yet. 
<AlexExtreme> i know, but what you have so far
<mbiebl> Give me some more time until I feel confident to announce them.
<AlexExtreme> Ok
<cortana> mbiebl: thanks for uploading a new tracker with my patch :)
<mbiebl> You're welcome. I have to thank for the patch.
<AlexExtreme> nice
<AlexExtreme> syslog-ng doesn't write it's pid file when run with --foreground
<mbiebl> AlexExtreme: Yeah, I used that too ;-)
<AlexExtreme> :p
<AlexExtreme> it was useful for my syslog-ng logrotate thing, but i'm writing a initctl pid command to replace that
<mbiebl> argh, now I understood you.
<mbiebl> AlexExtreme: what do you need the pid for?
<AlexExtreme>         postrotate
<AlexExtreme>                 /bin/kill -HUP `cat /var/run/syslog-ng.pid 2>/dev/null`  2> /dev/null || true
<AlexExtreme>         endscript
<AlexExtreme> that was what I had in the logrotate file for syslog-ng
<mbiebl> That should imo be solved by providing a reload command 
<mbiebl> within upstart
<AlexExtreme> h,,
<AlexExtreme> *hmm
<AlexExtreme> true
<AlexExtreme> i'll file a bug report
<mbiebl> Yes, please.
<mbiebl> reload should probably use SIGHUP as default.
<mbiebl> But there also should be the posssibilty to define a separate signal for reload
<mbiebl> e.g. some daemons also use SIGUSR1
<AlexExtreme> ues
<AlexExtreme> *yes
#upstart 2007-03-23
<catid> hello.. the respawn COMMAND syntax no longer works right?
<catid> i'm trying to update my svscan script in event.d to work with Fiesty
<catid> respawn exec /command/svscanboot doesn't seem to do the trick
<catid> would someone please help me to craft this so upstart will do the right thing?
<catid> eh, just removing respawn from the line works..
<catid> having it respawn would be nice though
<catid> later..
<cwillu> is upstart broken'ish on edgy?
* cwillu breaks into tears
<sadleder> cwillu: why do you think so?
<cwillu> more likely my assumptions are off
<cwillu> events/jobs are run as root?
<cwillu> I can't seem to get any output out of a script in an exec or respawn line;  I know the script runs because the process stays alive if I change the script to 'sleep 100m', but it seems like if I put anything else in there, it doesn't do anything.  It seems to work fine if I run it via sudo though
<cwillu> ah, no $HOME
<cwillu> this is why you don't do work at this hour
<cwillu> while the drunks are still in the office (grr)
<sadleder> hmm, was that the problem?
<sadlede1> cwillu: could you resolve the problem?
<cwillu> ya, environment wasn't as I expected
<cwillu> there's still a udev glitch on edgy that I'm working around, but things are working
<sadlede1> cwillu: ah, ok
<sadlede1> cwillu: for what task are you using upstart on edgy?
<cwillu> multiseat autoconfig;  udev to assign keyboards devices names corresponding to existing displays, and then triggering an upstart event to launch an evdev bridge from that device to the actual display
<cwillu> the idea being that a keyboard should be able to be unplugged, and a different one plugged in, and it'll get assigned to the display that's missing a keyboard
<sadlede1> wow
<cwillu> additionally, if a display used a particular usb port before, it'll prefer to use a keyboard on that port again if available
<cwillu> which makes the initial setup much easier:  don' t have to move keyboards around if they don't go to the right monitors when it's first set up, you can just swap the plugs
<cwillu> from there on in, as long as you don't unplug more than two keyboards at the same time, and then plug them into physically different ports, everything will work as expected
<cwillu> important when somewhat computer illerate people will need to keep 5 keyboards pointing at the right 5 monitors :p
<cwillu> (re:  said drunks)
<cwillu> only thing left is to selectively re-trigger the udev event for keyboards that are unassigned when a new display comes up
<cwillu> I figure it should save us about $10,000 a year in electricity alone (16 less computers, better options for power savings on the ones that are left)
<sadlede1> what is the system you are developing this for?
<cwillu> phone order stations for a pizza shop
<cwillu> currently use a bunch of old machines, one per phone line
<sadlede1> cwillu: sounds like a great project
<sadlede1> cwillu: so you have 5 graphic adapters?
<sadlede1> in one machine?
<cwillu> 3 dual headed
<cwillu> although I'm planning on using cheaper singleheaded cards in other machines
<cwillu> there's another bit of magic to make this work on sharedfb displays :p
* Keybuk reads another Linus vs GPL-3 interview with amusement
<_ion> Heh
<Keybuk> what amuses me is mostly how many inches of column can be dedicated to a licence that doesn't even exist yet
<_ion> :-)
<Keybuk> I've had maybe a dozen e-mails so far asking whether Upstart will be GPL-3
<_ion> Heh, that's interesting
<Keybuk> I just reply that I can't make any decision until I've read the final version of the licence, and until then it will definitely remain GPL-2
<_ion> The source can be used under the terms of GPL-3 as well, as soon as it exists anyway.
<_ion> unless you remove the "or (at your option) any later version" clause. :-)
<Keybuk> sure, I don't see a problem there
<Keybuk> the FSF have always promised the GPL-3 will only be more restrictive
<_ion> Yeah
<Keybuk> it won't allow people to do things the GPL-2 prevents people from doing
<Keybuk> so someone has the option of modifying and/or distributing the source /under the terms/ of the later version
<Keybuk> they don't have permission to *change* the terms, just follow the more restrictive ones
<_ion> Indeed.
<Keybuk> and that permits the code being combined with GPL-3 code at a later date
<Keybuk> providing the GPL-3 isn't bad, there's no problem there
<Keybuk> if there's real problems with it, I'll remove the clause :p
<_ion> Etsivt etsivt etsivt etsivt etsivt etsivt etsivt.
<_ion> That translates roughly to "the private investigators, that search for the private investigators, search for the private investigators that search for the private investigators". :-)
<Keybuk> ?#
<_ion> Something akin to the http://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo thing :-)
<cortana> nice link
<cwillu> what version of upstart supports arguments on events?
<Keybuk> 0.3.2 I think
<Keybuk> 0.3.8 is the current recommended version
<cwillu> :/  edgy is runs 2.something I think
<cwillu> no environment vars either, huh
<_ion> Feisty will be released soon. :-)
<cwillu> this is true, which just means I have to take out whatever hack job I use to get this working this month when its release next month :p
<cwillu> know of any good hackjobs to do this?
<_ion> What are you trying to do?
<cwillu> I've got some udev stuff that maps keyboards to heads on a multi-seat system, but doesn't actually do the connection (just names them after the server that should use them)
<cwillu> I've got another program that reads the keyboard and forwards the events via xtest
<cwillu> I want to have that last program launched via upstart
<cwillu> "initctl trigger kbd/added <device name>" is what I'm after
<cwillu> but there may be anywhere from 1 to 12 heads, so I'd like to avoid making 12 upstart event definitions if possible
<Keybuk> you want to use the current version of upstart, then
<cwillu> that's what I hear :)
<cwillu> does it work with edgy?
* cwillu is starting to appreciate the advantages of a lts build
<_ion> It's probably easiest to grab the feisty source package and build it.
<_ion> So you get the 0.3.8-compatible Ubuntu jobs as well.
<cwillu> let me rephrase:  has the job definition syntax changed enough to break edgy jobs?
<cwillu> ahh
<cwillu> this is becoming a bit of a beast;  already running fiesty versions of some udev scripts (by-path symlinks otherwise stopped being generated if I plugged in more than a couple keyboards), evince (didn't handle landscape printing in edgy), 
<_ion> There's always the possibility of upgrading to feisty already.
* cwillu thinks
<cwillu> running it at home, true enough;  haven't run into any issues there
<cwillu> though come to think of it, I'm already going through the legwork to make sure the device name is constant, even if the physical keyboard for that display changes.  I could just poll the device
<cwillu> would make it an easy fix for fiesty at least
<cwillu> is there a handy script to wait for a display to come up?  I can rip the code out of xinit, but if it already exists...
<_ion> Can't you just use xinit directly?
<cwillu> it doesn't really fit in very well with what I'm trying to do;  would work fine for the nested servers, but the master server, I don't want any window managers running, I don't want it to exit when the clients quit, and the list of clients is generated dynamically
<cwillu> I already checked the xinit source code, it's just polling xopendisplay, so I'll probably just reimplement that
<cwillu> I dunno; xinit just leaves a bad taste in my mouth
<cwillu> and thus was born xpoll :p
<cwillu> is there a trick to getting upstart to redetect /etc/event.d scripts under edgy?
<Keybuk> it does it by itself
<cwillu> so I should be able to dump a one line "exec <some script>", and launch that job immediated via "start <filename in event.d>"?
<cwillu> immediately even
<Keybuk> yes
<cwillu> 'cause I can't :p
<Keybuk> oh
<cwillu> "initctl: Unknown job: masterServer"
<Keybuk> /etc/event.d/masterServer exists ?
<cwillu> cwillu@8th:/etc/event.d$ ls -l masterServer 
<cwillu> -rw-r--r-- 1 root root 149 2007-03-23 12:05 masterServer
<Keybuk> check the syslog to make sure theres no parse error
<cwillu> nothing shows up in syslog, although I did have a couple hits on some other jobs I just tried
<Keybuk> try opening it and saving it again :p
<Keybuk> 0.2 wasn't very good at this
<cwillu> I'm noticing this :)
<cwillu> okay, got something that time
<Keybuk> gnargh
<Keybuk> yet another "why doesn't upstart use yacc to parse its config files?" e-mail
<Keybuk> 1) because yacc does not generate parsers 
<cortana> it doesn't?
<Keybuk> no ... it generates a grammar reader
<Keybuk> e.g. you can tell bison
<Keybuk>   expression: expression '+' expression
<Keybuk>             | NUMBER
<Keybuk>             ;
<Keybuk> but you can't tell it how to extract NUMBER or '+' from a file, or where the whitespace goes, etc.
<cortana> well, is that not lex's job
<Keybuk> exactly
<Keybuk> the correct question would be "why doesn't upstart use LEX/FLEX to parse its config files?"
<Keybuk> :p
<cortana> ok now i know i didn't totally misunderstand what they o :)
<cortana> exactly ;)
<Keybuk> yacc/bison aren't much use here, because the config grammar is simpler to deal with using a function table
<cortana>  & does it?
<Keybuk> no
<cortana> but then again lexing is piss easy
<cortana> i'm surprised this is such an FAQ
#upstart 2007-03-25
<hansi_> hey
<hansi_> somebody could give me some upstart-help, please?
<hansi_> hello?
#upstart 2008-03-17
<age6racer> hi all, I want to start firefox at the start of a session and I need it to respawn if it is closed. Will the following jobfile work? http://pastebin.com/meee0801 (I am on Ubuntu Gutsy) 
<matteo> hi
<matteo> Md: what a surprise!
<sadmac_> Keybuk: https://bugzilla.redhat.com/show_bug.cgi?id=437379
<sadmac_> ^^thoughts?
<Keybuk> sadmac_: there is no runlevel syntax in 0.3
<Keybuk> err, I mean && syntax
<Keybuk> the best thing I can think of is to make sure that the serial-console-available events aren't emitted until you want them
<sadmac_> Keybuk: I figured. What's the next workaround?
<sadmac_> hmm. that might involve doing nasty nasty things to udev.
<Keybuk> yeah
<Keybuk> you're encountering a lot of problems with your gettys :)
<sadmac_> yep
<Keybuk> you really can't do what you're trying to do with 0.3 :-/
<sadmac_> I'm thinking about adding a wait-for command to initctl that will just block until a given event is recieved.
<sadmac_> then we can hack this into pre-start
<Keybuk> you could do that
<Keybuk> though that's inherently racy :)
<Keybuk> since what happens if the event has already been received?
<sadmac_> true.
<sadmac_> I also need to add telinit u
<Keybuk> what does that one do?
<Keybuk> isn't that just kill -TERM 1 ?
<Keybuk> which version of Fedora are you targetting upstart for?
<sadmac_> Keybuk: upstart will be appearing in F9
<sadmac_> Keybuk: and yes, telinit u does just kill -TERM 1. we already have a 3-liner patch that implements it by doing exactly that.
<Keybuk> F9 is out on Halloween?
<Keybuk> You do seem to be trying to do more with Upstart than you were doing with sysvinit
<Keybuk> but I guess that's inherent for you because you have to justify using it instead of sysvinit?
<Keybuk> whereas in Ubuntu, the justification for using Upstart with the exact same feature set *as* sysvinit is simply testing and debugging
<Keybuk> you've pretty much hit every single reason that I stopped developing 0.3 and focussed on 0.5 instead
<Keybuk> they weren't trivial patches, but some major redesigns that needed to happen to the core
<sadmac_> The sysvinit stuff was kinda brokenish. Upstart features are often easier to do than preserving our own precarious setups.
<sadmac_> What we're replacing here is stuff that's legacy from red hat linux 6 and earlier. Its hackish.
<Keybuk> *nods*
<sadmac_> If all goes well and we get 0.5 for F10, then F10 might nearly qualify as a new distro :)
<AlexExtreme> I haven't noticed any change at all in the startup process and the way the sysv scripts are managed since RH6
 * AlexExtreme wonders if he still has his boxed copy of RH6
<Keybuk> I think that was about the last version I used
<ion_> Same here
<sadmac_> I'll have to mail out install media to everyone
<sadmac_> :)
 * AlexExtreme currently uses an RH-based distro on all his boxes, so doesn't need it ;)
<sadmac_> AlexExtreme: which one? Or does it vary?
<AlexExtreme> varies
<AlexExtreme> main box F8, test box rawhide, my VPS CentOS
<AlexExtreme> and CentOS on the router
<ion_> sadmac: Btw, i found another use for wait-for-file: http://gitweb.heh.fi/?p=ion/ubuntu/compcache.git;a=blob;f=debian/compcache-utils.init;hb=ubuntu :-)
<sadmac_> nice
<sadmac_> ion_: nice
 * sadmac_ goes to class
<ion_> I learned that /dev/compcache0 might appear just a little while after modprobe has returned.
<Keybuk> heh
<Keybuk> that would split that job in two though, right?
<Keybuk>   start on <something>
<Keybuk>   exec modprobe compcache
<Keybuk> --
<Keybuk>   start on modprobe-compcache and file-exists /dev/compcache0
<ion_> Yeah
<Keybuk>   exec swapon -p 100 /dev/compcache0
<Keybuk> ?
<jdong> Amaranth: and yeah, full upstart boot
<Amaranth> jdong: sweet
<Keybuk> jdong: hi :)
<Amaranth> is it faster? :)
<jdong> Keybuk: hi :)
<Keybuk> back up a bit, it's less insane here
<Keybuk> what's the problem and question?
<jdong> Amaranth: around 15s
<Amaranth> jdong: damn
<ion_> Neat
<jdong> Keybuk: a lot of my upstart rules are hackish "states", as in a pre-start script /etc/init.d/foobar start
<jdong> Keybuk: google told me to use the "service" keyword for that
<jdong> Keybuk: my question is, does this in any way prevent parallelized service startups?
<jdong> Amaranth: right now I'm mostly IO bound -- I'm sure my readahead is wasteful and incomplete at the same time
<jdong> Amaranth: I'm thinking about disabling or drastically lowering pdflush during bootup
<Keybuk> ok
<Amaranth> disable the page cache during boot?
<Keybuk> the difference between "service" and not specifying it is the difference between a service and a task
<Keybuk> (ie. those with "service" are services, those with tasks are not)
<jdong> Amaranth: disable the periodic writeback flush
<Amaranth> ah, right
<Amaranth> that sounds dangerous :P
<Keybuk> a task is expected to complete before it has deemed to have been successful, or to have failed
<Keybuk> a service is only expected to have become running
<Keybuk> Amaranth: ironically maybe less dangerous - since the next boot will be the same as the current one in cases of crash
<Keybuk> this affects how events and commands block
<jdong> Keybuk: ah, that makes sense
<Keybuk> "start task" will block until the task actually finishes
<Keybuk> (ie. you'll see the pre-start, post-start, main, pre-stop and post-stop scripts in the output)
<Keybuk> "start service" will only block until the task is running
<Amaranth> jdong: gimme :)
<jdong> Keybuk: so with a service, what does the "pre-start" script block?
<Keybuk> (ie. you'll see the pre-start, post-start and main scripts in the output)
<Keybuk> jdong: life cycle of the job itself is unchanged
<Keybuk> it only affects the things that change the job
<Keybuk> ie. if you use the "start" command or "emit" command anywhere
<jdong> Keybuk: ah, so during bootup can multiple services be "starting up" if they don't depend on each other?
<Keybuk> yeah
<jdong> Keybuk: sweet
<Keybuk> though note that if you do
<Keybuk>   start apache
<Keybuk>   start dbus
<Keybuk> and apache is a task (no "service" stanza), then dbus won't be started until apache *stops*
<jdong> Keybuk: ok, that makes sense
<Keybuk> so service is probably far closely to what you want for all of these things
<jdong> Keybuk: so it's reasonable to wrap an init script into an upstart job using service?
<Keybuk> (a long standing issue is that service probably should be the default, and task require the stanza)
<Keybuk> very reasonable
<Keybuk> all init scripts in rc2 are generally services
<jdong> Keybuk: also, are compound start conditions supposed to work?
<Keybuk> whereas all init scripts in rcS are generally tasks
<Keybuk> jdong: only in trunk
<jdong> Keybuk: well that explains a lot! :)
<Keybuk> the reason that task is the default is that respawning tasks makes no sense
<Keybuk> so it'd have to be an error to give both respawn *and* task
<Keybuk> and the code didn't have the ability to emit that kind of parsing error for a long time ;)
<jdong> Keybuk: also, what's the shutdown event?
<Keybuk> jdong: whatever you define it as
<Keybuk> upstart has no specific notion of shutdown
<Keybuk> (though it probably needs one, to disable respawning of services)
<jdong> Keybuk: oh, so I need to do that :)
<jdong> Amaranth: http://jdong.mit.edu/~jdong/event.d.tar.gz
<jdong> Amaranth: warning: I didn't port S20nvidia-kernel as I don't have nvidia stuff
<jdong> Amaranth: warning 2: usplash must be off. I'll look into that $eventually
<Amaranth> heh
<Amaranth> hmm, really fast boot or nvidia and usplash? :P
<jdong> Amaranth: :) the decision is so difficult
<Keybuk> nvidia-kernel is evil
<jdong> Amaranth: Note that I also hackishly knocked out rcS/rc2's actually spawning of init.d/rc :)
<Keybuk> it wouldn't be necessary if the nvidia kernel module was ported to udev
<Amaranth> good luck there
<Keybuk> nouveau ftw
<Amaranth> some year
<Amaranth> actually probably end of the year for me
<Amaranth> jdong: interesting, so all this does is wrap the existing init scripts in upstart jobs so you can do an event driven boot
<AlexExtreme> not fully native?
<Amaranth> no
<Amaranth> it just wraps the init scripts so they can be started in parallel and in an event driven way
<AlexExtreme> fair enough
<Amaranth> i don't see how that would break usplash
<AlexExtreme> it possibly could
<AlexExtreme> was it faster than normal?
<Amaranth> jdong can apparently boot in 15 seconds now?
<Amaranth> but i think last time i asked him he was booting in 21 seconds anyway
<AlexExtreme> i got around that when I did a fully native boot quite a while ago
<AlexExtreme> possibly less, can't quite remember
<AlexExtreme> haven't got the bootcharts to hand atm
<jdong> Amaranth: I just got bootchart hooked in and when all activity stops, it's around 22s
<jdong> Amaranth: but stopwatch time is around 15s to the point I can log in
<jdong> Amaranth: bootchart has exposed a few bottlenecks that I'll work on :)
<Amaranth> cool
<Amaranth> jdong: and what was your times before using upstart?
<jdong> a bit over 30 I bleieve
<jdong> Amaranth: I've got a backup of /etc, I will time a "before" afterwards :)
<sadmac_> Keybuk: can you explain the speed reports we've gotten?
<ion_> sadmac: What speed reports?
<sadmac_> ion_: people are claiming fedora boots faster and shuts down MUCH faster with upstart, even though at the moment upstart is doing exactly what sysv did.
<ion_> I think Ubuntu got those reports as well and it was 100% subjective. :-)
<ion_> A placebo effect.
<AlexExtreme> probably people *think* there's a speed improvement :P
<ion_> Unless someone has actually measured a difference?
<jdong> ion_: yeah indeed I've seen such reports with Ubuntu
<sadmac_> ion_: I remember seeing that one person had measured. a couple seconds faster on either side.
<jdong> I'm going to have some upstart vs upstart-sysv-compat bootcharts ready in 30s
<jdong> on Ubuntu at least :)
<sadmac_> Fedora is definitely going to be faster. Only because we'll need to rewrite a bunch of things that are overdue for it.
<mbiebl_> sadmac_: what are your plans for fedora? do you want to switch to a completely upstartified boot process in fc9+1.
<mbiebl_> Or will move over gradually
<mbiebl_> supporting both old sysvinit+upstart jobs
<mbiebl_> in parallel
<sadmac_> mbiebl_: all the sysinit and lower level stuff will be upstart. Getting things like apache etc. to use upstart depends on how long it takes me to force the maintainers to do it.
<sadmac_> so both will be present, though ideally sysvinit won't be used for anything.
<ion_> Could use a BFDL? :-)
<ion_> DF
<jdong> http://jdong.mit.edu/~jdong/macbook/bootchart-sysv.png
<jdong> http://jdong.mit.edu/~jdong/macbook/bootchart-upstart.png
<jdong> upstart vs sysv bootchart
<jdong> but that doesn't tell the whole story -- with upstart g
<jdong> with upstart GDM is up and waiting to log in almost 10s earlier
<mbiebl_> sadmac_: will do define a state like "multiuser"
<mbiebl_> when certain upstart jobs are running you enter this stage and from that on you will run the sysv scripts?
<jdong> note the period from 20-25s and how much more fully upstart was able to utilize system resources...
<sadmac_> ion_: where benevolence toward the project and malevolance toward its contributors are not necessarily mutually exclusive, yes.
<sadmac_> mbiebl_: hard to say.
<sadmac_> jdong: looks like 8s improvement
<jdong> sadmac_: indeed
<jdong> sadmac_: but considering that initramfs->readahead->udevtrigger is really not improvable by ANY init system.... remove those from the times
<mbiebl_> sadmac: I'd be interested if you plan to convert the scripts bottom-up or top-down.
<jdong> sadmac_: and as far as actually starting up of services, it's a much bigger improvement factor.
<ion_> Would be nice to replace readahead with filesystem block rearranging. :-)
<jdong> look at the compactness of the area from about 12s on, when readahead finishes
<jdong> ion_: indeed :)
<jdong> also note my slow-arse macbook hard drive
<sadmac_> mbiebl_: my first desire for the F10 cycle is that rc.sysinit disappear completely.
<jdong> had I NOT had a 12MB/s max IO limit...
<mbiebl_> sadmac when will f9 be released?
<sadmac_> mbiebl_: Some time in May.
<sadmac_> mbiebl_: 29 April by current schedule
 * jdong now plans writing all these init scripts in native upstart....
<jdong> Keybuk: so with a service where pre-start could take a while, does the service count as "started" after the pre-start script exits?
<jdong> i.e. if foo "starts on started bar", and bar just sleeps 30 in its pre-start, will upstart wait out that 30s before starting foo?
<jdong> does upstart ignore any types of files in event.d? dotfiles maybe?
<Keybuk> jdong: started yes
 * Keybuk sets mode +v
<Keybuk> that is to say, a service does not count as started until pre-start finishes
<Keybuk> (actually later, but that's close enough for your kinds of service)
<Keybuk> if you want to know if it has simply "been started", use starting instead
<Amaranth> jdong: 5 lousy seconds?
<Amaranth> that's painful
<Amaranth> then again your boot is tweaked to hell anyway :P
<Keybuk> 5s is pretty good
<Keybuk> as long as the boot doesn't slow down, I'd be happy
<ion_> Yeah
<Keybuk> actually, right now, I'd be happy if I could stop procrastinating about this damned dbus bindings tool
<Amaranth> Keybuk: I want me computer to be on before I even think to hit the power button :P
<Amaranth> s/me/my/
<Keybuk> Amaranth: that's when we get reliable suspend and resume
<Keybuk>   stop on suspend
<Keybuk>   start on resume
<Amaranth> eh?
<Keybuk> "wake on esp"
<Amaranth> hehe
<Amaranth> can a service stop on suspend like that though?
<ion_> I was amazed when the suspend feature on this laptop i recently got (ye olde Compaq with whopping 64 MiB of RAM and a faulty monitor) actually worked on the first try. :-)
<Amaranth> would be nicer than editing /etc/default/acpi-support to stop/start stuff
<ion_> Sure it can.
<Keybuk> why not?
<Amaranth> cool
<Keybuk> HAL/GnomePowerManager would just need to send a dbus message to Upstart before actually initiating the syspend
<Amaranth> although then you'll be blamed for slowing down the suspend/resume even more :P
<Keybuk> gets rid of all the hacky scripts and stuff that do it right now
<Amaranth> yeah, that's true
<Amaranth> upstart - removes the nasty hacks made to keep sysvinit working
#upstart 2008-03-18
<Absorto> hello! I'm running Gutsy and unable to get a text mode login with Ctrl-Alt-F[1..6]. Help!
<Keybuk> heh @ Absorto
<Keybuk> that's actually the most logical bug to blame on Upstart in a while
<Keybuk> better than last week when someone filed a bug on Upstart for muting their sound card when they switched to a VT
<AlexExtreme> haha
<ion_> He even had a whopping five minutes of patience!
<Keybuk> (I *love* the fact that sound card stops when you switch VT
<Keybuk>  it proves that Linux is really starting to get the underlying architecture correct)
<ion_> Yeah
<ion_> Unfortunately, that feature hasn't been ported to my drivers yet.
<ion_> We'd still have time to make that feature consistent by the Hardy release. Could boast about it in the release notes.
 * Keybuk tries to work out what the dbus marshalling code should actually look like
<Keybuk> it'd be nice if a method just looked likt
<Keybuk> int
<Keybuk> dbus_job_start (Job *job,
<Keybuk>                 char **env)
<Keybuk> {
<Keybuk>     /* do stuff to start the job, or nih_error_raise */
<Keybuk> }
<Keybuk> and there was auto-generated wrapper code to marshal the function call, and generate the reply
<Keybuk> not sure how to handle errors though
<Keybuk> since NihError and DBusError don't quite 1:1 match
<sadmac2> Keybuk: that reminds me. We've had to patch nih so that it would recognize rpm tempfiles as package manager files (and thus upstart would ignore them in event.d)
<sadmac2> do you want that upstream?
<Keybuk> yeah, definitely
<jdong> Keybuk: if I am not careful, is it possible to end up with a circular start-stop relationship? :D
<Keybuk> jdong: sure
<Keybuk> foo:
<Keybuk>   start on stopped bar
<Keybuk>   stop on started bar
<Keybuk> bar:
<Keybuk>   start on stopped foo
<Keybuk>   stop on started foo
<jdong> cool :)
<jdong> Keybuk: a less silly question, are there any plans/ideas for revamping initramfs with something upstart related?
<Keybuk> general idea is that /sbin/init in the initramfs is upstart
<Keybuk> and you copy the bits of /etc/event.d you want in too
<jdong> Keybuk: it seems like rigth now more than 1/3 of my bootup is in initramfs and I can't help but think it can be done more efficiently
<Keybuk> hand-over by reexec, it would pass the job configuration over as "deleted jobs"
<jdong> sounds cool
<Keybuk> so the upstart in the real system would know the status/pid/etc. of those started in initramfs
<jdong> what's the Ubuntu timeline for having more stuff done by Upstart? Next cycle?
<Keybuk> yeah
<jdong> awesome, I really look forward to it. Hacking my Hardy box to boot off upstart has been one of the more exciting things I've done recently
<jdong> Keybuk: also, what kinds of files are ignored in event.d?
<sadmac2> Keybuk: check your email. you have a patch
<Keybuk> jdong: hidden files, backup files, swap files, RCS control files and packaging debris
<jdong> Keybuk: very nice
<jdong> Keybuk: does Upstart understand subdirectory structure in event.d?
<Keybuk> yes
<jdong> does it have any special meaning, or can I arbitrarily use it to organize my job files?
<Keybuk> arbitrary organisation
<Keybuk> the /etc/event.d/foo/bar/baz file defines a job called foo/bar/baz
<jdong> cool
<jdong> Keybuk: also, is there a way for sysv jobs to interact with upstart, such as automatic firing of events for when sysv jobs start/stop?
<jdong> other than hacking /etc/init.d/rc :)
<Keybuk> why is not hacking rc important?
<Keybuk> I'd just hack rc to emit sysv-started and sysv-stopped at appropriate times
<jdong> Keybuk: just wondering if there's any standardized way yet. I have no problem hacking rc if that's the right way(tm)
<sadmac2> jdong: that's how we're doing it in Fedora
<jdong> Keybuk: could this also be an upstart-compat-sysv feature for Intrepid?
<jdong> sadmac2: yeah, I'll do that locally  for now
<sadmac2> Keybuk: I'm thinking that some time very shortly after 0.5 NetworkManagerDispatcher could be replaced entirely by upstart.
<sadmac2> brb moving desk
<Keybuk> I can't decide which is better
<Keybuk> changing NihError to have some kind of dbus-compatible error string
<Keybuk> or having a look-up table to convert between NihError enums and DBusError strings
<Keybuk> thought-of-the-day
<Keybuk> should the Start() method return immediately, or not return until the service is running/task is finished?
<ion_> keybuk: Iâm not familiar enough with how dbus APIs generally behave to give an opinion.
<Keybuk> me neither
<Keybuk> you basically expose objects
<Keybuk> objects have interfaces
<Keybuk> interfaces have methods
<Keybuk> so that's all well and good
<Keybuk> Upstart has JobConfigs and Jobs
<Keybuk> (or Jobs and Instances, depending on the direction I'm explaining from :p)
<Keybuk> so in theory, these should map well
<Keybuk> we'd have a /com/ubuntu/Upstart object with a com.ubuntu.Upstart.Manager interface
<Keybuk> that has a FindByName(String name) -> (Object) method
<Keybuk> obviously that's going to return a Job object
<Keybuk> to start a Job, you need to find or create an Instance, then start that Instance
<Keybuk> it can fail because you didn't supply enough parameters to identify an Instance
<Keybuk> it can fail because the Instance was already started
<Keybuk> if you start a job, you probably want to also be notified of its goal and status changes (initctl does anyway)
<Keybuk> and you want to be notified when it is actually started, or the starting failed
<ion_> Yeah
<Keybuk> the goal and status changes are clearly Signals
<Keybuk> you have to tell D-Bus that you want a signal, so this wouldn't work:
<Keybuk>   job = FindByName("apache")
<Keybuk>   instance = job.Start(...)
<Keybuk>   dbus.AddMatch(instance, "StatusChanged")
<Keybuk> since you have a race between the Start and the AddMatch where you'll miss signals
<ion_> Yep
<ion_> Fix dbus API? :-P
<Keybuk> you only want the signals from the instance you're going to start
<Keybuk> you don't care about the other running apache instances
<Keybuk> (and jobs don't have goals or status anyway)
<Keybuk> we could expose the entire process to the client, and let it do the hard work
 * ion_ envisions the DBus API taking a Ruby-style block, which is executed *after* the object is created but *before* the command has been sent, i.e. instance = job.Start(...) {|it| dbus.AddMatch(it, "StatusChanged") }
<Keybuk> but I think that's generally bad
<Keybuk> so my idea was to have a magic D-Bus "request" object
<Keybuk>   job = FindByName("apache")
<Keybuk>   request = job.Start(...)
<Keybuk>   dbus.AddMatch(request, "StatusChanged")
<Keybuk>   request.Go()
<ion_> Yeah, that would be equivalent (without the syntactic sugar). :-)
<Keybuk> though I guess it should be StartRequest(...)
<Keybuk> since Start() would do it without an intermediate object
<Keybuk> and almost everything other than initctl will just use Start()
#upstart 2008-03-19
<Keybuk> another idea
<Keybuk>   req = com.ubuntu.Upstart.Request ()
<Keybuk>   job = FindByName("apache")
<Keybuk>   dbus.AddMatch(req, "StatusChanged")
<Keybuk>   instance = job.Start(env, req)
<Keybuk> or I guess
<Keybuk>   job = FindByName("apache")
<Keybuk>   req = job.Request()
<Keybuk>   dbus.AddMatch(req, "StatusChanged")
<Keybuk>   req.Start(env)
<Keybuk> basically pre-alloc the Request object
<Keybuk> oh, DBus
 * Keybuk has a KHAAAAAAAN! moment
<Amaranth> so are you writing your own libdbus now? :)
<Keybuk> basically
<Keybuk> well
<Keybuk> libnih-dbus
<Keybuk> which wraps libdbus and makes it less itchy
<Keybuk> http://people.ubuntu.com/~scott/nih-dbus.png
<Amaranth> neat, didn't realize you were that far
<Amaranth> but i thought libdbus aborted when the daemon went away
<Keybuk> I fixed that
<Amaranth> how? :)
<Keybuk> reimplemented dbus_bus_get()
<Keybuk> otherwise it's just a flag in the struct you leave as FALSE
<Amaranth> ah, neat
<Keybuk> at the point of chaining everything together
<Keybuk> so you do something like:
<Keybuk>   NihDBusInterface job_interfaces[] = {
<Keybuk>       IFACE_JOB,
<Keybuk>       { NULL }
<Keybuk>   };
<Keybuk> :
<Keybuk>   nih_dbus_register_object (job, job_path (job), job_interfaces);
<Keybuk> IFACE_JOB, and all the necessary marshalling functions, are generated by a python script
<Keybuk> so you just need to define
<Keybuk>   job_start() and job_stop(), etc.
<Keybuk> which have C-like arguments and return values
<Amaranth> that's pretty neat
<Keybuk> main problems are the difference in interface style ;)
<Keybuk> e.g. that function creates an NihDBusObject struct, holding the path, interface array and underlying object
<Keybuk> for bus, that needs a vtable structure - the message function is a standard one inside libnih-dbus that knows how to dispatch based on the interface array
<Keybuk> (and handle the Introspect and Properties interfaces)
<Keybuk> the unregister function is a standard one as well
<Keybuk> so when the connection vanishes, it calls nih_free() on the object
<Keybuk> *but* that means if you call nih_free yourself, the destroy function has to unregister the object
<Keybuk> which calls the unregister function
<Keybuk> which is nih_free
<Amaranth> i think i'll just keep using dbus from python :P
<Amaranth> i thought nih_free just lowered the reference count
<Keybuk> no, nih_alloc isn't refcounting
<Amaranth> ah
<Keybuk> some bits of dbus seem a bit broken to me
<Keybuk> or, at least, poorly designed
<Amaranth> you say that about everything, i think :P
<Keybuk> like the fact you can't share an object table between multiple dbus connections ;)
<Amaranth> multiple connections? why would you have multiple connections?
<Keybuk> one to the bus
<Keybuk> and one for when the bus isn't there
<Amaranth> ah, for initctl?
<Keybuk> right
<Keybuk> try:
<Keybuk>     bus = dbus.SystemBus()
<Keybuk>     manager = bus.get_object("com.ubuntu.Upstart", "/com/ubuntu/Upstart")
<Keybuk> except:
<Keybuk>     server = dbus.connection.Connection("unix:abstract=/com/ubuntu/Upstart")
<Keybuk>     manager = server.get_object("/com/ubuntu/Upstart")
<Amaranth> neat
<Keybuk> though in practice, most things will be discouraged from doing the fail-over
<Keybuk> it's mostly just for initctl, so if dbus is down, you can either start dbus - or shutdown the machine
<Amaranth> i can't think of anything else that would need it
<Keybuk> me neither
<Amaranth> well, i'm sure people will _think_ they should use it
<Amaranth> but you can just tell them to quit being stupid and start the system bus :)
<Keybuk> yeah
<Keybuk> *sigh*
<Keybuk> D-Bus needs a lot of glue
<jdong> you could write an UpstartBus and expose some Dbus compatibility mode for a few release cycles ;-)
<jdong> you know that sounds tempting
<jdong> then the KDE4 folks will have a real world justification for their dbus abstraction layer!
<Keybuk> we had an upstart-native IPC before
<Keybuk> that's what I'm trying to get away from
<Keybuk> :p
<jdong> Keybuk: What kind of {pre/post}-start/stop events are available to me in Hardy's upstart?
<jdong> are post-start and pre-stop logical/existent?
<Keybuk> yes
<jdong> cool
<jdong> Keybuk: so when 5 jobs "start on stopping bar" and I do initctl stop bar, what is the order of actions that happen from that with regards to pre-stop/post-stop scripts on bar?
<Keybuk> pre-stop will be run
<Keybuk> the stopping event for the job will be emitted
<Keybuk> that event blocks
<Keybuk> the main process of the job will be killed
<Keybuk> post-stop will be run
<Keybuk> the stopped event for the job will be emitted
<jdong> Keybuk: beautiful and logical
<Keybuk> no order between the individual 5 jobs is guaranteed
<jdong> sounds reasonable.
<Keybuk> but between the 5 jobs and bar *is* guaranteed
<Keybuk> bar will not actually be killed until the 5 jobs have started
<jdong> Keybuk: in  your replacement-initscripts, is there any reason you chose to not use a service and pre-start/post-stop for readahead, readahead-watch, and other non-daemonized stuff?
<Keybuk> how do you mean?
<jdong> Keybuk: like in readahead, you used a single "exec readahead-list blah", while I probably would've used "service; pre-start script readahead-list blah"
<Keybuk> why would you do it in pre-start ?
<jdong> Keybuk: so that way readahead shows up as "started" and I can say "start on started readahead" which makes more sense to me than "start on stopped readahead ok"
<jdong> Keybuk: is there something insane about doing it in pre-start?
<Keybuk> not really insane, per-se
<Keybuk> it's certainly one way to do tasks
<Keybuk> though "started readahead" implies readahead is still ongoing to me
<Keybuk> whereas "stopped readahead" says that the readahead has actually finished
<Keybuk> (the "ok" is arguably a bug, it shouldn't matter whether it worked or not <g>)
<sadmac2> Keybuk: We'll be needing to document the 0.3.9 job format soon.
<Keybuk> sadmac2: happily that's pretty stable ;)
<Keybuk> obviously it all changes in 0.5 again <g>
<sadmac2> well that'll be nice
<sadmac2> I'm just hoping I don't miss any features.
<jdong> Keybuk: lazy question of the day: Is there syntactic sugar for restarting services yet?
<Keybuk> not yet
<Keybuk> it's actually more than sugar
<Keybuk> restart has different behaviour than stop && start
<sadmac2> bounce <job>
 * sadmac2 would be very happy if the command were called bounce
<Keybuk> heh, why? :)
<Keybuk> wouldn't that clash with MTA commands?
<jdong> because he can create innuendos with jobs like "fsck"
<sadmac2> jdong: you're one to talk, what with having dong in your name and all
<jdong> not like he can't do that right now, already.
 * jdong goes down the road of greedy  boot speed optimization.
 * jdong plays with nice/ionice :)
<sadmac2> Keybuk: bounce is a pretty ubiquitous colloquial term around here for restarting something.
 * Keybuk wonders whether it's against the rules to name a computer after a game that's not yet been released
<sadmac2> Keybuk: what game?
<Keybuk> spore
<Keybuk> makes a good machine name
<Keybuk> (my naming scheme is computer game names)
<sadmac2> Keybuk: the firewall has to be named Portal.
<sadmac2> I name mine after postmodernists
<sadmac2> Baudrillard, Warhol, Foucault
<Keybuk> heh, the firewall used to be frontier ;)
<sadmac2> The windows box should be Solitare
<sadmac2> (sp?)
<sadmac2> s/tar/tair/
<Keybuk> yeah, used that one a few years ago
<AlexExtreme> mine are named after characters from The Matrix
<Keybuk> it was replaced by minesweeper and now is hearts
<mdales> I have a quick question. If I remember correctly upstart will blacklist any script that fails too frequently within a given period
<mdales> at any point does that blacklisting expire?
<Keybuk> depends on the period
<Keybuk> it's a rate limit
<Keybuk> if you say a job can only respawn 10 times a minute, then it cannot respawn within a minute of the first of 10 respawn attempts
<Keybuk> the default is 5 times in 10 seconds
<mdales> hmmm
<mdales> okay
<mdales> what's happening here is an ubuntu system has had a bad udev rule added that means a job is being invoked too early in the boot process, rather than waiting for runlevel 2
<mdales> so it fails, then at runlevel 2 the rule is no longer available
<Keybuk> which "here" is this?
<Keybuk> udev doesn't emit any upstart events in Ubuntu
<mdales> it's a gutsy system that I don't have ssh access too, just through the software that is started by this upstart job
<Keybuk> what software is that?
<mdales> well, that's the pain - someone accidently made udev to it
<mdales> some remote management software I wrote
<Keybuk> right
<Keybuk> and that crashed?
<mdales> I imagine the software crashed as the world wasnt' ready. the udev rule restarts the software on block devices (intended for USB stick configuration)
<Keybuk> ok
<mdales> so I assume it's being started on hard disks :)
<Keybuk> definitely would be, yes
<mdales> we get an unknown job error on the system we've reproduced the error on here
<mdales> but I was wondering if we waited long enough that would go away
<Keybuk> unknown job is odd
<Keybuk> that means the name isn't right?
<Keybuk> they're only stopped if they run out of control
<Keybuk> not deleted
<mdales> hmmm
<mdales> the script is still there and is valid
<mdales> I say, the runaway invocation was just a theory
<Keybuk> does status not show it?
<mdales> initctl list does not show it
<Keybuk> what happens if you touch it?
<Keybuk> touch /etc/event.d/myjob
<Keybuk> does it show up in list?
<mdales> let me see
<mdales> yes
<mdales> it does
<Keybuk> Upstart thinks you deleted the file
<mdales> cool :)
<Keybuk> is it changed at all on boot?
<mdales> no
<mdales> the only thing this udev script does is call start and stop
<Keybuk> weird
<mdales> in that it tries to stop an existing thing and then start it
<Keybuk> I'd boot with --debug to see what's going on
<mdales> will give that a whirl. but I'm assuming my theory that the job would become avaiable over time is bogus then?
<jdong> Keybuk: does Upstart log anywhere?
<jdong> I think I have a race on boot :)
<Keybuk> to syslog
<Keybuk> mdales: right, it won't become available if Upstart has wiped it from its memory
<jdong> Keybuk: does console output imply not console logged?
<Keybuk> console logged is broken
<jdong> Keybuk: would that be why /var/log/boot is empty?
<Keybuk> yes
<jdong> cool :)
<mdales> not much new info on debug. I can see that on start the process in question respawns and then terminates a lot
<Keybuk> odd that upstart deleted it though
<Keybuk> it should mention that
<mdales> I can't see it - is there a specific term I should be scanning for in the logs?
<Keybuk> "deleted" is a clue ;)
<Keybuk> there should certainly be something like:
<Keybuk>   Deleting foo job
<mdales> cd /var/log; grep elete *  | grep job shows no results
<Keybuk> did you look at the output on the screen?
<Keybuk> it might be happening before syslog starts
<mdales> ah. alas it scrolls off too quickly
<mdales> 25 lines really isn't enough :)
<mdales> okay, so this is interesting. I actually start two processes, the second dependant on the first. it's the first that's being deleted. I note the second gets too many restarts, but the first only seems to be started once
<mdales> ther'es a terminate message, then silence
<mdales> this was a reboot without debug
<ion_> We really should move the drivers from Xorg to the kernel, have it provide a good framebuffer interface with acceleration, resolution settings et al, and have the virtual consoles as well as X use the same framebuffer interface in harmony. :-)
<mdales> heh
<mdales> I assume then it says job terminated with status 2 the 2 is the exit status for the process
<ion_> That would also make it possible for X to break horribly and still have a working console, or even a kernelâs debug console you get with a magic sysrq key over virtual consoles as well as X.
<Keybuk> mdales: yes
<Keybuk> ion_: it makes it possible to panic the kernel and do something more useful than flash the caps lock light ;)
<Keybuk> (I kid you not, this is in keithp's use case list)
<ion_> Yep :-)
 * AlexExtreme hates not getting panic info when in X
<AlexExtreme> btw, is kdump going to be used in ubuntu any time soon?
<ion_> I donât even have a caps lock light. :-)
<mdales> with --debug there's just too much crap
<mdales> well, many thanks for the assistance. if I find any more info I'll file a bug perhaps :)
<Keybuk> do you know, I think I just won?
<Keybuk> still need to handle new connections, disconnection and properties
<Keybuk> but the basics are there now ...
<ion_> Congrats. :-)
<ion_> You tamed the beast.
<Keybuk> heh, I've stopped it biting me
<Keybuk> I haven't yet got a saddle on it
<ion_> Heh
<Keybuk> of course, now to decide which bit to attack next
 * sadmac2 attacks the crab's weak point for massive damage
<sadmac2> ion_: there's quite a few X developers here at RH that want to do what you want to do with X, and similar things.
 * Keybuk wonders
<sadmac2> ...???!!!
<sadmac2> what? what?
<Keybuk> which bit to do next
<sadmac2> Keybuk: what are the options?
<Keybuk> still just plodding on with the dbus stuff
<Keybuk> I guess I need to work on the python script to auto-generate the bindings
<sadmac2> which bindings are those?
<Keybuk> basically just C marshalling functions
<Keybuk> to turn DBusMessage into a function call, and vice-versa
<sadmac2> auto-generating code makes kitty scared. But I won't judge without seeing.
<Keybuk> really?
<Keybuk> auto-generating code is the *best* way to do things
<Keybuk> since then you only need test the generator
<sadmac2> The better way is to be really smart about de-duplication, so you just don't have to write much code.
<Keybuk> sadly the C compiler doesn't yet support runtime-generated function calls ;)
<sadmac2> I suppose the cpp is auto-generation though. And I do love the cpp.
<sadmac2> well, you'd still have to do the generating before compile time, wouldn't you?
<Keybuk> it doesn't even support that
<sadmac2> I dunno. I'd need a fuller picture of what's going on.
<Keybuk> int
<Keybuk> hello_world (const char *who,
<Keybuk>              const char **str)
<Keybuk> {
<Keybuk>     sprintf (*str, "hello %s", who);
<Keybuk>     return 0;
<Keybuk> }
<Keybuk> ideal C code for a D-Bus method with the IDL
<Keybuk>   com.netsplit.Nih.Test.HelloWorld (in String who, out String str)
<Keybuk> to be able to make the code that simple, you need a function to marshal a DBusMessage into a function call
<Keybuk> and form a valid reply as well
<Keybuk> people.ubuntu.com/~scott/test_dbus.c
<Keybuk> err
<Keybuk> http://people.ubuntu.com/~scott/test_dbus.c
<Keybuk> test_hello () there is the example of the simple function I'd like to spend my time writing
<Keybuk> the test_hello_marshaller () function makes it possible by marshalling the message
<Keybuk> and the test_hello_args, test_methods, test_signals, test_properties and test arrays connect it all together
<Keybuk> I'd like everything but test_hello() to be autogenerated
<Keybuk> since it's entirely based on the iDL
<sadmac2> I see.
<sadmac2> I think I could get nearly there using just the cpp.
<Keybuk> it'd be quite difficult
<sadmac2> :) I was damn close to having try {} catch {} blocks implemented in the cpp.
<sadmac2> sigsetjmp was behaving oddly though.
<Keybuk> you can certainly do exceptions in C
<Keybuk> cf. dpkg
<ion_> A human can be considered a code generator. :-P
<ion_> Or perhaps a caffeine to code converter.
#upstart 2008-03-20
<mdales> is it possible to have upstart start job b if job a failed?
<Keybuk> yes
<keesj> hi
<Keybuk> mdales: the stopping and stopped events have arguments saying that it failed, what failed and why
<mdales> ah, excellent
<mdales> is that in the version that's in gutsy?
<mdales> I was reading up on jobfailedevent, but I assume that's not there at the moment.
<mdales> thanks for the info
<Keybuk> it's there
<Keybuk> job-failed-event was implemented in 0.3.x
<mdales> ah
<mdales> w00t
<keesj> I have a job that was started and exite sucessfully , it is not a rewawn job , but I would like the job to remain in "start(ed)" status or at least would like to know that is was started 
<keesj> (I currently have a while sds ; sleep 10 ;  to keep it running 
<Keybuk> I'm not sure I follow
<keesj> :P
<Keybuk> you have a job
<Keybuk> and you want that job to always be running?
<keesj> what I really want to know is if is was stated regardless of whether it is still running
<Keybuk> if it was started, the goal will always be start?
<keesj> much like the mount-kernel-filesystem job
<Keybuk> usual way for that kind of thing is to put the work in the pre-start bit of the job
<keesj> Keybuk: what is the "goal" of a job?
<Keybuk> spore scott% sudo status tty1
<Keybuk> tty1 (start) running, process 4576
<Keybuk> the goal is start, which means Upstart will attempt to keep the job running
<Keybuk> if the goal is stop, Upstart will attempt to keep the job _from_ running
<Keybuk> goal is changed to start by events or manual command
<Keybuk> goal is changed to stop by events, manual command and the main process exiting (unless respawn and not normal exit)
<keesj> yes but I don't want it to be running, even if I call start mount-kernel-filesystems
<Keybuk> jdong: I was thinking about whether there should be the option of "sticky" jobs
<Keybuk> that stayed running even after the process exited
<Keybuk> but I couldn't decide whether that was any different from what you were doing, and just doing the work in pre-start
<keesj> after that (because the jobs is no respawn) the status is stop
<keesj> I would like it to be something else  :p
<Keybuk> respawn would keep it at start
<Keybuk> (though you would still get stopping/stopped/starting/started events each time it exited)
<keesj> but I don't want that. I want the job to finish gracefully and the status to remain on something else then "stopped"
<Keybuk> the best way to do that is to put your "job" in pre-start
<Keybuk> it'll be run when you start the job, and the job will stay in running (since there's no script/exec) until otherwise stopped 
<keesj> the that sounds very sexy!
<keesj> let me try that!
<Keybuk> it's an interesting pattern
<keesj> I can not say how happy I am ! it is working!
<keesj> well kinda ...
<keesj> apparently I can not simply start such a service using emit (with no --no-wait) 
<keesj> perhaps it is missing some events
<Keybuk> start?
 * Keybuk really must fix that confusion
<Keybuk> if you have /etc/event.d/foo
<Keybuk> then the right way to start it is just "start foo"
<Keybuk> emit foo won't do anything unless foo has "start on foo" in its job definition
<keesj> yes , I have things like start on start_boot_mode_select
<keesj> also with start foo I have to use --no-wait, , I am using 0.3.8
#upstart 2008-03-21
<jdong> oh keybuk is going to kill me.
<jdong> http://bazaar.launchpad.net/~uphackers/uphack/uphack-tools/files
<jdong> it's the beginnings of a script to automatically hook sysv init scripts to upstart :D
<xjjk> hello, I've created a new job in /etc/event.d... but when I try to start it via 'start', I get an "Unknown job" error
<xjjk> am I forgetting to do something?
<xjjk> the lob is not listed via 'initctl list' either..
<ion_> Does your system have inotify?
<xjjk> I'm not sure
<xjjk> using Ubuntu 7.10 Server
<xjjk> I'm missing /dev/inotify, so I suppose not..
<xjjk> do I need to telinit/reboot to get the jobs recognized?
<xjjk> or is there something simpler, like a signal I can send...
<ion_> No, there's no /dev/inotify.
<ion_> Are there any error messages about the job in syslog?
<xjjk> ah, yes... totally missed that, thanks
<xjjk> ion_: works great now, thanks
#upstart 2008-03-23
<Alfafa> Hi. I am fairly new at doing ustart scripts. But now I would like to convert an old daemontools service to upstart. What are the events upsart can listen to. I would like it to stop the service when my laptop is on battery power
<Alfafa> Is this possible?
<keesj> Alfafa: I guess so
<keesj> the thing would be to listen to uevents or are those apm events?
<keesj> Alfafa: again differently: upstart does not listen to many events , for every "job" / service you can define your own event names
<Alfafa> keesj: I am on ubuntu hardy. I think gnome-power-manager sends a event over DBUS..or I know it does, but I don't know how I get upstart to pick it up?
 * Alfafa is back. 
<keesj> from readinf the acpid man page it really should be very easy
<keesj> really I would say a) create a job that starts the acpid on startup , b) convert the required events into upstart even "so emit power-in-the-house" in the script
<keesj> c) define your jobs that need to listen to the power-in-the-house 
<Alfafa> keesj: from what I understand upstart doesn't yet have a way to get DBUS events? I saw some talk of a DBUS proxy...which would convert from DBUS events to upstart events?
<Alfafa> keesj: Hmm..I could also make something which listens to DBUS and emit an upstart event
<Alfafa> keesj: thanks for the help anyway :-)
<keesj> and hal will put the messages on dbus?
<keesj> on my ubuntu machine I simply have /etc/acpi/battery.d so a one liner would send the events to upstart
<Alfafa> keesj: maok. that sounds easy :-)
<Alfafa> keesj: I am not sure it is hal sending the dbus message. I think it is gnome-power-manager
<keesj> the problem mi be that acpi is not for every computer , the gnome-thingy might be more suited :p
<Alfafa> keesj: thanks for the help..i thin the acpi thing will work :-)
<keesj> yo
<Frymaster-UK> o/ is there a manpage or other documentation for writing jobs in event.d? I've found some examples and a getting started guide, but no reference
<keesj> Frymaster-UK: not that i am aware off. download the example jobs or replaceÃment scripts
<Frymaster-UK> yeah :( was hoping for sommat a bit more structured
<keesj> if you find a real reference if would love o see it
<keesj> i tried finding the parsing code shortly but did not find it fast enough
#upstart 2009-03-16
<Keybuk> MarcWeber: *blink*
<Keybuk> waitpid doesn't return the pid?
<MarcWeber> No, it returns pid - 1 !
<MarcWeber> Anyway after appying the pid++ patch everything is fine :)
<Keybuk> I'm going to start a wiki page
<Keybuk> "ways in which vserver is just broken" :p
<MarcWeber> Yes, do that. And don't forget to mention it in the irc channel headline!
<MarcWeber> If I had known this earlier I would have saved a lot of time..
#upstart 2009-03-17
<ion_> http://arstechnica.com/news/2009/02/sector-remap-fragmentation-slowing-intel-x25-m-ssds.ars
<Keybuk> and the moral of the story is that it's better to do such things in software in the O/S than in hardware
<ion_> Yeah
<suihkulokki> ion_, Keybuk, indeed the SSD storage is going all the wrong direction - hiding the raw NAND chips behind a microcontroller that tries to make them look like spinning hard drivers with sectors, cylinders and heads..
#upstart 2009-03-18
<xzirrow> Does anybody can help me with upstart to get /var/log/boot and my boot-up messages ?
<keesj> try the kernel boot you can get with the dmesg command but there is no such logging facilitie in upstart
<xzirrow> too pity. Yes i can see kernel messages in dmesg - i'm interested in messages of phase two :)
<xzirrow> is it planned to realise such thing in future ?
<keesj> upstart itself logs events to syslog and you can (apparently) log the output of the processes to syslog
<keesj> after that is's a matter of configuring syslog to log to the right file I guess
<xzirrow> Do I need configure smth in upstart to make it log starting scripts output to syslog ?
<keesj> I don't know the future of upstart and I am not developing in the main branhc
<xzirrow> Do I need to config smth in upstart to make it log messages from startings scripts to syslog ?
<Keybuk> Upstart doesn't do that
<keesj> http://upstart.ubuntu.com/wiki/Stanzas check the "console"
<keesj> apparently it's called "logger"
<Keybuk> that'd been disabled for ages
<keesj> Ok , sorry about that
<xzirrow> So, as i can get - there is no possible way to recive /var/log/boot ?
<Keybuk> xzirrow: not currently
<xzirrow> Keybuk, so console output or console logged at ( /etc/event.d/logd) does nothing with upstart ?
<Keybuk> console output will send the output to the console
<xzirrow> Keybuk, so console logged will do what ? 
<Keybuk> nothing
<Keybuk> it's not implemented right now
<xzirrow> Keybuk, ok, thank you very much - it clearified situation
<Keybuk> I'd like to do something with it, obviously
<Keybuk> but there's lots of problems and pitfalls
<Keybuk> a miriad of different syslog daemons
<Keybuk> I'd kinda like cron "mail output on failure" functionality
<Keybuk> and the filesystem is generally read-only for much of the boot
<keesj> tricky, what the kernel does is to use a ring buffer for the kernel output
<Keybuk> an ordinary growing buffer would probably do just as well
<keesj> I also guess you wil need to add some instance information, and that kinds a sounds like syslog again
<keesj> in our setup we have the busybox syslog logging to memory with a shared buffer , you can then read the data using logread
<keesj> (but no job output indeed)
<Keybuk> "some instance information" ?
<keesj> what job instance is generating the output
<ion_> http://www.networkworld.com/community/node/39858
#upstart 2009-03-19
<elli222> hello
<elli222> anybody alive?
<elli222> i guess i could just ask my question then?
<elli222> I added this to my rc-default. will my changes work or will i have a massive desktop paperweight? http://paste.ubuntu.com/133713/
<ion_> You lose nothing by trying. You can always recover â if by nothing else, by booting with init=/bin/sh. :-)
<elli222> init lines seem to be ignored
<elli222> ive tried with init 3 at the boot line...
<elli222> lets test it!
<keesj> hi
<Keybuk> hai
<keesj> I will probably do some profiling on upstart in the next days
#upstart 2009-03-20
<kysucix> hi
<kysucix> I'm using Ubuntu intrepid version of upstart. Using "console logged" I can't see where the output gets logged
<kysucix> Does it get redirected to syslogd or something else? is it a known bug?
<kysucix> upstart Version: 0.3.9-8
<kysucix> I get unable to read: Invalid argument
<Keybuk> it doesn't
<kysucix_> Keybuk, it does not log in any way?
<Keybuk> correct
<Keybuk> you can send the output of jobs to the console
<kysucix_> with 'console output' right ?
<Keybuk> right
<kysucix_> thx
<sadmac> Keybuk: ping
#upstart 2009-03-22
<Md> Keybuk: did you find a solution to the multiple consoles problem? (I mean, standard init only outputs to /dev/console which can be either the monitor *or* the serial console but not both)
<Keybuk> Md: "the multiple consoles problem" ?
<Md> Keybuk: in practice you cannot use at the same time a serial console and a normal monitor
<Md> this tends to limit the usefulness of configuring a serial console in some environments, so I wonder if this is something which could be solved in upstart...
<Keybuk> well, you'll still have the basic problem that the kernel only recognises one console at a time
<keesj> Keybuk: it can and does output to different consoles at the same time, but only one (the first one I think) is interactive
<keesj> mu upstart "service_console" does some cat /proc/cmdline magic to reuse the same serial as given
<Keybuk> keesj: how do you mean?
<Md> keesj: the last one, which is the one which connects to /dev/console
<Md> so I wonder if it would be practical to make upstart listen for input on all configured consoles
<Md> s/connects to/becomes/
<Keybuk> upstart doesn't "listen for input" ?
<Md> Keybuk: think about single user mode, when there is no getty
<Keybuk> Md: yes, but getty can only be attached to one pty at a time
<Keybuk> there's no pty multiplexer inside the kernel :)
<Keybuk> there is one in userspace
<Keybuk> called "screen" :)
<Keybuk> I've non-jokingly suggested before that on servers we should start screen on the consoles
<Keybuk> but not sure what happens to consoles at all with KMS yet
<Md> Keybuk: the problem is not gettys, but everything before that
<Md> you can already start as many gettys as you need
<Keybuk> I'm clearly not following ;)
<Md> stdin/out/err of init is normally connected to /dev/console
<Md> and /dev/console can be only one of the consoles configured on the kernel command line
<Keybuk> right
<Md> so it would be very useful if init could multiplex its input and output on all existing consoles. OTOH, it may be argued that this should be fixed in the kernel
<Md> the use case is that if you configure the serial console e.g. for the IPMI netconsole then an attached monitor and keyboard are useless
<Keybuk> but it's not that simple
<Keybuk> what if the different consoles are different sizes?
<Keybuk> what if they have different terminal types (esp. relevant to serial console)
<Keybuk> or different speeds?
<Keybuk> multiplexing ptys is not a simple job
<Md> I do not think that there is much expectation of curses applications working before a getty is started anyway
<Keybuk> one of the most run things from single-user mode surely is apt? :p
<Keybuk> which implies aptitude
<Keybuk> or debconf
<Keybuk> they're all curses
<Keybuk> hell
<Keybuk> in Ubuntu we don't just drop to bash in single user mode
<Keybuk> but we display a curses menu of common fixes
<Keybuk> one of which is "give me a root shell"
<Keybuk> we often get away with justifying why single user mode exists on the basis that "you're at the physical console, so you could take away the machine"
<Keybuk> opening that up to foreign consoles could be implied to be a bug
<Keybuk> I'm not disagreeing that it would be nice
<Keybuk> but I think that Upstart is not the appropriate place to do it
<Keybuk> or even in the kernel
<Keybuk> but reconfiguring single user mode to run screen, connected to the listed consoles, then running things in that
<Keybuk> screen in single user mode is a win anyway, since then you can spawn additional shells ;)
<Md> I see that doing this in init is complex, but it's not just single user mode but the messages of the init scripts as well
<Keybuk> oh, I fully plan to get rid of those ;)
<Keybuk> they shouldn't be on the console anyway unless !quiet
<Md> not even if a script failes?
<Md> fails, even
<Keybuk> the console is not a very useful place to put those
<Keybuk> I'm thinking more of the cron model
<Keybuk> logging the error messages, e-mailing them, putting them in the syslog, etc.
<Keybuk> it should be trivial to write a program that when you login tells you there were errors during boot
<Keybuk> and you should be able to look through those errors
<Keybuk> and it should encourage people *not* to do things like >/dev/null 2>&1 || true in their jobs
<Md> what about fsck prompts?
<Keybuk> prompts are better handled in other ways
#upstart 2010-03-22
<mrand> Is  $LANG  an acceptable (and expected to be future supported) way to support locales?  This is in reference to this potential patch for MythTV: http://launchpadlibrarian.net/41297489/mythtv-backend.conf.diff  If not, what is the recommended way?
<JanC> mrand: that patch looks weird
<mrand> JanC: I'm not sure that the person doing it understands upstart, and I'm "just" a triager.
<mrand> Hence the ping here.
<JanC> e.g. LANG=$LANG is basically assigning the value of LANG to LANG?
<mrand> JanC: I believe that is a shell trick for making sure that it gets passed on to the called application?
<JanC> I think you better ask in #ubuntu-devel (as this is Ubuntu-specific), but in my opinion LANG=$LANG is useless, and LC_ALL=$LANG might be wrong (there is a reason why there is both LANG &  LC_*) but there *might* be a reason for that (in which case the reason should be given--I have no idea what this patch tries to fix)
<mrand> JanC: oops.... sorry, here is the bug: https://bugs.launchpad.net/bugs/541042
#upstart 2010-03-23
<blakemizerany> I'm a first-time upstarter.  I've installed ubuntu 2.6.28 on VMWare fusion.  I've also placed the `echo --Bounced--` script in /etc/init/foo.conf.  When I run `start foo` or `initctl emit bounced` they all say "unkown job foo".. can anyone help?  is /etc/init the right place to put these?
<wasabi> I have an upstart job that has died.
<wasabi> Yet it still think it's stop/waiting.
<wasabi> Oh. N/m
<wasabi> It just never respawned it.
#upstart 2010-03-24
<sadmac> ion: we took logd out of upstart because when you killed it it would SIGPIPE anything using it, right?
#upstart 2010-03-25
<jdub> given that upstart doesn't natively support kicking off a process as a particular uid/gid, is it still sane/recommended to use start-stop-daemon?
<jdub> at least if you have that particular requirement
<ion> sadmac: I donât remember.
<ion> jdub: How about su?
<jdub> ion: i do *not* want to run su in my init script :-)
<Keybuk> ya know what I also want
<Keybuk> on the interactive "start this service y/n" boot thingy
<Keybuk> the ability to start a shell, there and then, so you can see what state the machine is in right now
<Keybuk> then, when you exit the shell, ask again whether to start the service
<sadmac> Keybuk: did we kill logd because it SIGPIPEd all its clients when you killed it?
<Keybuk> yes
<sadmac> Keybuk: one liner fix
<sadmac> Keybuk: man sendmsg. search for MSG_NOSIGNAL
<Keybuk> yes, let's rewrite everything that writes to standard output to use sendmsg() instead of printf() and add that to it :p
<sadmac> Keybuk: when I read it the first time it looked like it'd turn it off for subsequent calls.
<sadmac> Keybuk: shit, yeah they mean for this call.
<sadmac> I think...
<sadmac> yeah, that's probably it
<mbiebl> Keybuk: seen that: http://article.gmane.org/gmane.linux.suse.opensuse.devel/26237
#upstart 2010-03-26
<Keybuk> mbiebl: no, hadn't heard anything about that
<Keybuk> cool ;-)
<nanonyme> Any devs or other people who'd like to spar a few ideas about upstart present?
<sadmac2> nanonyme: what do you mean?
<nanonyme> Well, I bumped into the apparently common issue of it being a bit tricky to start programs inside a chroot when dealing with upstart.
<nanonyme> I was wondering if there is some working solution and if not, whether dbus could be used so that upstart outside the chroot could communicate with processes inside the chroot and supervise them.
<nanonyme> Opinions or ideas?
<Keybuk> there isn't a working solution
<Keybuk> just some fuzzy ideas
<Keybuk> it's not really that high on the urgency list
<nanonyme> Yeah. But would you think something like that could work? That is, that since upstart can use dbus, you'd hook up the directories dbus uses between real system and chroot.
<nanonyme> (or am I missing something crucial here?)
<Keybuk> I don't see how D-Bus helps here
<nanonyme> Point. I didn't really think it far enough through.
<Keybuk> the difficulty mostly comes from the chroot separation
<Keybuk> making sure that "start apache" in the chroot starts the apache in the chroot, not in the outside system
<nanonyme> Hrm.
<sadmac2_> udev's syntax makes me pee a little.
<sadmac> Keybuk: here's one for you: writing a "hey, look how cool libnih is!" blog post. Wanted a practical but simple code snippet that shows why multiple parents is useful.
<Keybuk> err, there must be one somewhere in Upstart's source ;-)
<sadmac> Keybuk: practical, lots of them. The simple is key :)
<sadmac> i.e. an example that makes sense in 20 lines without having to see the whole rest of upstart's code
<Keybuk> err, you could use a message?
<Keybuk> where a struct has a string in it
<Keybuk> (string parent is struct)
<Keybuk> and you borrow the string, referencing it, using it in another struct
<sadmac> was thinking along those lines
<sadmac> http://screwyouenterpriseedition.blogspot.com/2010/03/why-you-should-be-using-libnih.html
<sadmac> Keybuk: are you against patches to make some of the ignored compatibility options in /sbin/shutdown do what they used to?
<Keybuk> yes
<Keybuk> for the most part
<Keybuk> IMO shutdown should only accept options that change the way the machine is shut down
<sadmac> notting: we still have bugs for making -f, -F, and -n
<Keybuk> all of the other silly hangers-on are better off moved to other tools / GNOME UI / etc.
<sadmac> notting: kill these things?
<Keybuk> -f, -F, etc. wildly assume your filesystem check implementation
<Keybuk> e.g. for us, forcing a fsck is adding a kernel command-line argument, not touching a file
<sadmac> we can do it either way
<Keybuk> right, but I don't want to force that kind of thing
<Keybuk> you may not even fsck on boot
<Keybuk> maybe it's an embedded system with a read-only filesystem anyway
<Keybuk> etc.
<Keybuk> that's why I don't want any of those flags in shutdown
<sadmac> I'd prefer not to carry patches. I think I'll WONTFIX the fedora bugs. If plautrba wants/is forced to do something about it in RHEL, so be it.
<notting> Keybuk: well, if it's an embedded system, you get what you deserve if you tell it to fsck on the next reboot
<sadmac> notting: are you up for an initscripts-based fix for 464456?
<sadmac> see comment 3
<notting> eh, i'm not sure the current behavior is really wrong
<Keybuk> notting: put another way
<Keybuk> if shutdown should have a "and check filesystems on next reboot" option
<Keybuk> shouldn't shutdown also have a "reboot into windows" option? :p
<notting> oh gah, lilo -R
<sadmac> notting: I can close 464456, or give it to you to close. Where should we put it?
<notting> i'll close it
<sadmac> notting: https://bugzilla.redhat.com/show_bug.cgi?id=441048 , terminal isn't in cooked mode when it should be?
<notting> yeah. it goes away, it comes back. usually we blame halfline
<sadmac> notting: should I move it to plymouth? Or to initscripts (I'm guessing some sort of echo ^[!@#$%!@#$^! at the start of the single user job could fix it)
<notting> plymouth
<sadmac> Keybuk: do you have a launchpad bug about upstart not working on XFS?
<nanonyme> Hrm, ^M is supposed to be enter too though, me thinks.
<halfline> ^M is carriage return.  tty settings determine whether ^M or ^J or some combination there of is enter
<nanonyme> Right. Both ^M and ^J are considered enter here though.
<nanonyme> I've always hated the amount of variation those things have. :p Including backspace.
<Caesar> Keybuk: you around?
#upstart 2010-03-27
<Caesar> Keybuk: in an Upstart world, what's most appropriate for something like Puppet to use to manipulate services?
<Caesar> service, or invoke-rc.d?
<ion> start for starting, stop for stopping, status for querying status.
<ion> Or alternatively initctl start, initctl stop, initctl status (which do the same thing).
<Caesar> ion: that won't help for a system that has hybrid Upstart and legacy init scripts
<Caesar> But yes, for a fully Upstart world, I can see that being the case
<Caesar> Oh nice, they seem to work with non-upstart jobs as well
<Keybuk> http://news.opensuse.org/2010/03/25/opensuse-11-3-milestone-4-release/
 * Keybuk laughs at libnih on OBS
<Keybuk> "It duplicates much of glib for no (really) good reason."
<Keybuk> that's, seriously, the package description
<ion> Haha
<sadmac2> http://en.wikipedia.org/wiki/Gobject
<sadmac2> ^^ I love it when wikipedians find subtle ways to inject their opinion (see image)
<ion> Hehe
<corecode_> hey
<corecode_> i'm wondering what the correct way is to start upstart jobs from a debian postinst hook
<corecode_> i'm using "start mytask", but that hangs
<ion> Let dh_installinit handle it.
<corecode_> i'm on maemo, there is no dh_installinit that can deal with upstart
<corecode_> at least as far as i can tell
<ion> Iâd suggest cherrypicking the change from Ubuntu.
<corecode_> not really under my control :/
<ion> Patches attached to bug trackers tend to be effective.
<corecode_> i wouldn't even know where to look
<corecode_> so, until such a change is in place, how would i start an upstart job?
<ion> Ubuntuâs installinit adds âstart JOB || :â to postinst. The hang youâre encountering needs to be debugged, though. Probably an issue with some âstart onâ relation blocking.
<corecode_> oh meh.  there is a "dh_installupstart" which is undocumented
<corecode_> i just have "start on startup"
<ion> And thereâs no other job that has e.g. âstart on starting YOURJOB and SOMETHINGELSEâ?
<corecode_> no
<corecode_> i think it also got started
<corecode_> just start never returned
<corecode_> very strange.
<corecode_> start is running
<corecode_> so, it will start it
<corecode_> just it won't return
#upstart 2010-03-28
<imop45> hi all, I have a q that someome might be able to answer.
<imop45> I have a Palm WebOS device that uses upstart
<imop45> currently upstart just uses a graphic boot screen.
<imop45> I was wondering if a Verbose Mode would be possible.
<imop45> I've been searching the upstart site to see how to enable a verbose mode but can't seem to find it.
<imop45> hmm, so webOS uses a splash program
<imop45> are upsplash and splashy the only 2?
<JanC> normally upstart jobs are in /etc/init/ (new versions) or /etc/event.d/ (older versions)
<JanC> so I guess you should find it there somewhere (if it's started by upstart at all)
<corecode_> what do you mean with new/old versions?
<corecode_> ah!
<corecode_> how can i start a binary that doesn't daemonize?
<corecode_> i'm sorry to say so, but upstart is horribly underdocumented
<corecode_> i just can not find any documentation on how to start a non-backgrounding service
<ion> programname.conf: exec programname
<ion> start programname
<corecode_> that's what i have
<corecode_> but it just does not return
<corecode_> the start command
<ion> Anything interesting in syslog?
<corecode_> the service gets started, sure
<corecode_> but start doesn't return
<ion> Oh. I take it you have an ancient version of Upstart? In that case, add the line âserviceâ to the config.
<corecode_> i don't know which version is running
<ion> In old versions of Upstart, âtaskâ was the default. Nowadays, âserviceâ. A job being a task means that âstart jobâ returns when the program exits (i.e. the task is finished).
<corecode_> ah
<corecode_> ok
<corecode_> yea, too bad that this is not documented
<ion> Current Upstart releases have much better documentation than the ancient ones.
<corecode_> still it is confusing, and barely non-existing on the web
<corecode_> thanks for your help
<ion> Itâs in the form of man pages that come with the package.
<corecode_> yes i know
<corecode_> but on my platform
<corecode_> man 5 init = fail
<imop45> hi could someone guide me in enabling verbose boot mode on upstart?
<imop45> I'm trying to get a WebOS to boot without a splash screen.
<zdzichuBG> Hi, "--debug" in kernel comand line is supposed to dump all events emitted. Where can I read those logs?
<ion> Upstart outputs them to syslog, and until a syslogd is available, theyâll only go to the console. A proper boot logger is in TODO.
<zdzichuBG> Thanks.
<zdzichuBG> This is not good for me, unfortunately. I'm trying to debug problem where my application do not start on event which should be emitted, according to upstart documentation. I believe event is somehow not emitted.
<zdzichuBG> I have
<zdzichuBG> start on device-added SUBSYSTEM=block DEVNAME=sd[ab][!0-9]
<ion> [!0-9]?
<zdzichuBG> yes, I'm only interested in whole devices, not partitions
<ion> sd[ab][!0-9] matches e.g. sdaq, sdb! and sda_ but not sda or sdb. Youâll want sd[ab]
<zdzichuBG> uhm, isn't empty string part of [!0-9] ?
<ion> See glob(7)
<zdzichuBG> OK, thanks. Apparently I screwed the rule again (the one I had in F12 was wrong, also) :)
#upstart 2011-03-22
<froes> hi guys, i used to use init and was able to start 2 XDM instances on my machine. tty0-tty3 was consoles and tty4 and tty5 were gdm consoles. is there a way i can do it on upstart or should i go back to init ?
<BlackDex> Hello there
<BlackDex> i am trying to create an upstart config so i can start a java application via a screen
<BlackDex> but for some reason init has a non running pid as the pid that should be running
<BlackDex> if i do status <conf-name> it returns pid 531, but the app is running under pid 534
<BlackDex> so now i can't start/stop it any more
<JanC> BlackDex: currently upstart is not able to determine the exact PID when a service forks more or less than it expects
<JanC> and I guess using screen doesn't make that easier...
<JanC> it's probably best to stop & start the application from within the pre-start & pre-stop stanzas...
<BlackDex> janC i have figured it out just a few second ago, with some help via the mailing-list
<BlackDex> i need to start screen with -D -m, and no console, no expect or what ever, that did the trick
<BlackDex> so it looks like this: exec su myapps -c "screen -D -m -S MYAPP java -jar MyApp.jar"
<BlackDex> now i can screen -r into it using the user myapps, and i can start/stop etc via service
* Keybuk changed the topic of #upstart to: Upstart 1.2 "This sort of thing is my bag, baby" | http://upstart.at/ | Supporting a separate /usr since 2006! http://bit.ly/dQobg7
<jMCg> Hello happy people.
<jMCg> I'm trying to get a daemon running via runit which won't daemonize by itself, and which needs to run as a specific user, but can't setuid() itself.
<jMCg> My pathetic atempts: http://dpaste.com/524600/ look like this, both of which do not work.
<jMCg> With start-stop-daemon it records the wrong pid, and with su it doesn't really start.
<ion> expect fork *definitely* wonât match the behavior of that main process.
<jMCg> Won't?
<jMCg> hmnn.. I thought.. it would match with start-stop-daemon
<ion> Can you make it not daemonize and not use âexpectâ?
<jMCg> Can you reduce the negations in that sentence, thereby making it more understandable, please.
<ion> Make your main process not daemonize. Donât use âexpectâ.
<jMCg> ACK.
<jMCg> Okay. Now how do I get rid of this state:
<ion> Reboot or use the nasty kluge at http://heh.fi/tmp/workaround-upstart-snafu
<jMCg> tibemsd start/killed, process 4694
<ion> workaround-upstart-snafu 4694
<jMCg> tibemsd start/running, process 4702
<jMCg> Even though it's not.
<jMCg> Does that workaround-upstart-snafu still work in that case?
<ion> Does âstop tibemsdâ fail?
<jMCg> Nope.. it just hangs.
<jMCg> So, yes, it sortof fails.
<ion> I mean, does it get stuck in â¦/killed (because of incorrect use of âexpectâ)? If it does, workaround-upstart-snafu should nudge Upstart back into a good state.
<ion> A future release will have more robust code to track forks.
<jMCg> ion: yes, it does.
<jMCg> ACK, so I'll just clean stuff up with workaround-upstart-snafu.. I seem to have spend a lot of time.. "testing".
<jMCg> tibemsd stop/waiting
<jMCg> w00t.
<jMCg> tibemsd start/running, process 4723
<jMCg> tibco     4723     1 TS   19 20:58 ?        00:00:00 /opt/apps/tibco/ems/5.1/bin/tibemsd64
<jMCg> exec chpst -u tibco:tibco -U tibco:tibco /opt/apps/tibco/ems/5.1/bin/tibemsd64
<jMCg> That's what I'm using right now, and it works out fine.
<jMCg> ion: I really hope a next release will be able to handle that itself :-/
<jMCg> Or should I say: Is there anything I can do to help a next release do that itself?
<ion> You could test http://upstart.at/git/?p=scott/intendant.git with any programs you want, e.g. tibemsd with daemonization. git clone git://upstart.at/scott/intendant.git, build it, sudo ./intendant some-command. No child process should be able to escape it. Please email the logs (no matter if it works correctly or not) to Keybuk at scott@netsplit.com
<ion> Thatâs a test program that implements the method Upstart will use at some point in future.
<jMCg> ion: How do I generate the configure? autoreconf -i complains it's missing an m4 dir.
<jMCg> s/.*//
<jMCg> I did a /opt/bw/sbin/itedant /opt/bw/sbin/vsftpd and got a shitload of: cgroup notify closed on us?! 
<jMCg> as result.
<jMCg> Not quite sure why.
<ion> Not a problem.
<ion> All results are useful.
<ion> The main thing is that it shouldnât lose track of any of the child processes.
<jMCg> hehheheh
<jMCg> Also: how do I start something with params?
<jMCg> No man pages.
<jMCg> brb, need to pick up dinner.
<jMCg> Like.. half an hour ago.
<ion> Just add them on the command line.
<jMCg> Ah.. right.. makes sense.. had a typo.
<jMCg> sudo /opt/bw/sbin/intendant /opt/bw/sbin/vsftpd /etc/bw/vsftpd/vsftpd.conf
<jMCg> Now works out fine.
<jMCg> Well, until I Ctrl+C, that is, then I get the same cgroups stuff again.
<ion> Not a problem.
<Keybuk> jMCg: when you ^C, do all the processes of vsftpd go away again?
<jMCg> Keybuk: it's just one, so, yes.
<ion> % bzr pull
<ion> Using saved parent location: bzr+ssh://bazaar.launchpad.net/%2Bbranch/upstart/
<ion> Conflicting tags: 1.0
#upstart 2011-03-23
<Keybuk> jMCg: ok, cool
<Keybuk> ion: pull --overwrite
<Keybuk> I tagged the wrong rev with 1.0 and changed it ;-)
<jMCg> Another thing is logging: http://upstart.ubuntu.com/wiki/Debugging says to do this manually.
<jMCg> SMF for instance does that automatically.
<jMCg> It would be of invaluable use.
#upstart 2011-03-24
<JohnTeddy> http://pastie.org/1707503
<JohnTeddy> I don't know how to program, I'm trying to setup a script so my ssh tunnel is working on local host, so I can proxy out on my web browser and avoid the great Chinese firewall.. so I can get to facebook and youtube, etc.
<JohnTeddy> Can someone look at that url and tell me what is wrong with the script. Doing service china.firewall status keeps showing a new pid. How can I debug upstart scripts, is there a log somewhere?
<SpamapS> JohnTeddy: start on startup is too soon
<SpamapS> JohnTeddy: you need to have a network first
<SpamapS> JohnTeddy: try 'start on net-device-up IFACE!=lo'
<jMCg> ion/Keybuk - is it intendet for intendant to leave a mess in /tmp? http://pastebin.com/944LsUKr
<ion> jmcg: Itâs just a test program. That doesnât matter.
<Keybuk> ion: there was kudos for your ionice stuff in mountall earlier
<ion> Yeah, i noticed :-)
#upstart 2011-03-25
<marrusl> SpamapS, the cookbook is killer.  TY! (and JH)
<JohnTeddy> Mr_Bond: start on startup is too soon
<JohnTeddy> SpamapS: http://pastie.org/1712252
<JohnTeddy> What is wrong with that upstart script?
<JohnTeddy> o, apparently there is an autossh software package
 * JohnTeddy installs
<JohnTeddy> autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic. The original idea and the mechanism were from rstunnel (Reliable SSH Tunnel). With version 1.2 of autossh the method changed: autossh uses ssh to construct a loop of ssh forwardings (one from local to remote, one from remote to local), and then sends test data that it expects to get back.
<JohnTeddy> This will work better than what I have now
<JohnTeddy> http://pastie.org/1712298
<JohnTeddy> ok, let's see if this works.
<JohnTeddy> ok, the upstart script doesn't work.
<JohnTeddy> I wonder if it will auto reconnect after broken pipes though.
<JohnTeddy> It was consistently giving me a broken pipe after 10 minutes, so I just have to wait 10 minutes then see if I can still use pidgin/chromium.
<SpamapS> JohnTeddy: start on startup is before the network is up.. before filesystems.. *way* too soon
<JohnTeddy> SpamapS: right, http://pastie.org/1712298 I have 'start on net-device-up IFACE!=lo' now.
#upstart 2011-03-26
<mydoghasworms> Can upstart be used to monitor non-root processes?
#upstart 2012-03-19
<glenn___> spamaps: ok well that is good news and bad news, since 12.04 would still support mongrel.. thus the upstart script should spawn multiple puppetmasters
<SpamapS> glenn___: can you point me to the code that spawns multiple mongrel based puppet masters right now?
<SpamapS> glenn___: I suspect you'll want to use the 'instance' keyword
<glenn___> spamaps: http://paste.ubuntu.com/890983/ and http://paste.ubuntu.com/890984/
<glenn___> spamaps: its what i have so far... and it spawnz multiple masters.. it just wont shut them down yet :)
<glenn___> spamaps: I must be doing something wrong.. but im glad its spawning multiple masters though.. just finished that work
<SpamapS> start on puppetmaster
<SpamapS> stop on puppetmaster
<SpamapS> glenn___: neither of those will do anything useful :)
<glenn___> spamaps: when i start puppetmaster, it will start puppetmasters too :)
<SpamapS> glenn___: you probably want 'stop on stopping puppetmaster'
<glenn___> spamaps: just tried that, and gave weird fails, ill try it again :>
<SpamapS> glenn___: yes, but there is no defined event 'puppetmaster' so that start on isn't useful
<glenn___> spamaps: when im using stop op stopping puppetmaster it wont start anymore
<SpamapS> glenn___: why not do the check for mongrel in puppetmaster, so you avoid ever starting 'puppetmaster' ?
<SpamapS> err
<SpamapS> puppetmasters
<SpamapS> those names are very confusing
<SpamapS> would rather see a 'puppetmaster-mongrel'
<glenn___> oh the logfile is starting it, the processes are just not spawned
<SpamapS> glenn___: all in all though, you're on the right track
<glenn___> spamaps: thanks :) but in puppetmasters (mongrel) im doing a check for servertype = mongrel 
<glenn___> spamaps: so if its not mongrel it wont use puppetmasters
<SpamapS> glenn___: right, seems silly to go through the trouble of starting another job.. when you could do that check in 'puppetmaster'
<SpamapS> and void the entire loop
<SpamapS> avoid rather
<SpamapS> oh wait
<SpamapS> you do
<SpamapS> so nevermind :)
<glenn___> hehe
<glenn___> but why would it not start if i say stop on stopping puppetmaster
<SpamapS> glenn___: it should stop at that point, yes.
<SpamapS> glenn___: which means it wil be sent SIGTERM, then if it hasn't died in 5 seconds, it will be sent 'SIGKILL' (you can change that with 'kill timeout #')
<glenn___> im confused
<glenn___> when i add that line, nothing is starting anymore :(
<glenn___> and when i remove it, everything starts, but wont stop
<glenn___> lol
<glenn___> root@puppetclient:/etc/init# stop puppetmaster
<glenn___> stop: Unknown instance: 
<glenn___> carnit
<glenn___> i think i know why its stopping
<glenn___> its only starting the puppetmastermongrels, it leaves puppetmaster stopped :)
<glenn___> how am i supposed to keep puppetmaster running when it only spawns puppetmastermongrels?
<glenn___> ls
<glenn___> im on it :>
<glenn___> almost
<glenn___> the pain :)
<SpamapS> glenn___: its stopped because your script exitted
<SpamapS> glenn___: so instead of 'stop on stopping puppetmaster' I'd recommend 'stop on runlevel [^2345]'
<glenn___> spamaps: i fixed that, im using ur tip now..
<glenn___> argh
<glenn___> spamaps: how can i have puppetmaster running, when it is starting other upstart jobs? 
<glenn___> spamaps: isnt there a trick so puppetmaster will show the other upstart jobs, and think its running?
<glenn___> oh 
<glenn___> i think i got something now :>
<glenn___> but this will only start 1 extra daemon
<glenn___> at least it stops too :>
<glenn___> ps auxf
<glenn___> IT WORX :>
<glenn___> i just need 3 upstart files :)
<glenn___> Spamaps: http://paste.ubuntu.com/891213/ http://paste.ubuntu.com/891214/ http://paste.ubuntu.com/891217/
<glenn___> awesome :)
<glenn___> im someone could review this and give me feedback that would be good
<SpamapS> glenn___: there seems to be a lot of "extra" stuff there... I think it could be done simpler. :-P
<jaha> how do i control an upstart job without sudo
<jaha> EX: start foojob, stop foojob
<jaha> i added the setuid and setgid but no go
<SpamapS> jaha: er, you don't? ;) those are root's commands.
<SpamapS> jaha: unless you're talking about user jobs.
<SpamapS> in ~/.init
<jaha> these are jobs i created
<jaha> conf files in /etc/init
<SpamapS> oh then those are system jobs
<SpamapS> and you must be root to manipulate them
<jaha> ok, well im trying to start/stop jobs through a chid process im spawning with node.js
<jaha> i get sudo errors when trying to sudo a command in the process, any idea how I might get around that?
<SpamapS> jaha: make sure you have NOPASSWD privileges for the start/stop commands
<SpamapS> so like this
<SpamapS> mydaemonuser ALL = NOPASSWD: start
<jaha> i also just found that "service job reload" may work, would that be safer?
<jaha> instead of sudo reload job
<SpamapS> jaha: no, its identical
<SpamapS> though I do advocate using the 'service' command because its more portable
<SpamapS> and restart "does the right thing" when the service is stopped
<SpamapS> (meaning it ignores that it is stopped, and starts it)
<jaha> thanks, i appreciate the help
<JanC> so basically: use sudo, but without password restrictions
<JanC> and you might want to restrict what services can be manipulated without password...
<JanC> (I don't think it's a good idea 'mydaemonuser' can start/stop random jobs)
<SpamapS> JanC: agreed
#upstart 2012-03-20
<glenn___> spamaps: well this was just in testing phase, but im wondering if the structure is good, with 3 init scripts
<glenn___> spamaps: 1 script would be to start a server, wether its mongrel or webrick, the other 2 scripts are there for spawning multiple mongrels
<glenn___> spamaps: i made them simpler now: http://paste.ubuntu.com/892038/ http://paste.ubuntu.com/892039/ http://paste.ubuntu.com/892040/
<zyga> what is the correct way to start a script once networking is up
<zyga> start on startup and started networking ?
<SpamapS> zyga: depends on the OS
<zyga> SpamapS, oneiric+
<SpamapS> zyga: you never need to 'start on startup and xxxx' .. startup is just if you have something that can be started without regard to the current system state (since startup happens *first* before disks are mounted or anything else is running)
<zyga> SpamapS, right
<SpamapS> zyga: for Ubuntu 11.10 (oneiric) or later, runlevel 2 is always "after the network is up"
<zyga> SpamapS, actually I have a different requirement
<zyga> SpamapS, I just explained it incorrectly
<zyga> SpamapS, I need "first boot script"
<zyga> SpamapS, I start with a pre-made image
<zyga> SpamapS, then I need to run a shell script on the first boot
<SpamapS> zyga: perhaps look into cloud-init
<zyga> SpamapS, I'm starting with a barebone oneiric image
<SpamapS> zyga: it has a "nocloud" mode where you just drop a config yaml file on the disk and it reads it.
<glenn___> is there anyone else who could review my upstart scripts for puppet, before i will add them to the issue for the ubuntu package?
<zyga> SpamapS, does it have any upstart files I could reference?
<SpamapS> glenn___: I'm taking a look now. :)
<SpamapS> zyga: it has several that it uses to run before and after networking has come up
<glenn___> spamaps: awesome :)
<SpamapS> zyga: it just keeps track of whether or not it has already run, and exits gracefully if it has
<zyga> SpamapS, ok, let me try to find that 
<glenn___> zyga: im using upstart scripts on runlevel 2345
<glenn___> so when the server is in its right init it would start
<SpamapS> glenn___: so, are you hoping to get this into 12.04? And if so, why?
<glenn___> spamaps: everyone is telling me it probably wont work
<zyga> SpamapS, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/upstart/cloud-init-nonet.conf this looks like it
<glenn___> spamaps: why upstart? :)
<glenn___> spamaps: but perhaps we could insert it before beta2
<SpamapS> glenn___: right now the package is in sync w/ Debian, and works fine. Why change it?
<glenn___> spamaps: why use upstart...
<SpamapS> for this particular service, why use upstart.. yes thats what I'm saying.
<glenn___> spamaps: since that is the new way of starting daemons in precise
<glenn___> spamaps: almost all services we use is in upstart
<glenn___> except for apache, varnish, haproxy and such
<glenn___> spamaps: all services work without upstart, this is the same as asking why use upstart at all
<zyga> glenn___, what new  way if I may ask?
<glenn___> zyga: upstart
<zyga> glenn___, well that's true for a number of releases, just that most services were not converted
<glenn___> hence my point to get all services upstart compatible
<SpamapS> glenn___: so.. "because other stuff uses upstart" is not a valid reason, IMO. The main reason I encourage usage of upstart is because it allows the scripts to be simpler, since upstart handles most of the boiler plate stuff.
<zyga> SpamapS, I hate the inconsistency between service XXX start and start XXX 
<SpamapS> glenn___: the other big reason is because you want other upstart jobs to be able to start before or after it.
<SpamapS> zyga: so use service all the time. It works with upstart jobs.
<glenn___> spamaps: what exactly is ur point
<glenn___> ive been spending a lot of hours so we can implement upstart for the puppet package
<SpamapS> glenn___: I do want your upstart job to land in Ubuntu. But we're *way* way way way too late for precise without a compelling reason.
<glenn___> spamaps: i gave up on the precise release
<glenn___> :)
<glenn___> spamaps: but, if, it would be in there, that would be nice though
<SpamapS> glenn___: Ok, so I expect mongrel to be gone for 12.10 .. so we can drop to just the one upstart job. :)
<glenn___> spamaps: when do we know if mongrel is gone in 12.10?
<glenn___> spamaps: also, i think we should default to puppetmaster-passenger as a master
<SpamapS> http://bugs.debian.org/663921
<SpamapS> glenn___: ^^ .. removal has begun already from Debian. When we sync, it will be gone.
<glenn___> spamaps: that would be a nice point to use upstart as well then
<glenn___> spamaps: since the init.d scripts have to be changed anyway, including the defaultfiles
<SpamapS> glenn___: indeed.
<glenn___> spamaps: puppet client upstart script, im using that one already
<glenn___> spamaps: the passenger is relying on apache 
<glenn___> spamaps: so if we sync this from debian into 12.10 the puppetmaster package needs to be changed right? to remove the mongrel support..
<glenn___> but still there would be an upstart script for the puppetmaster, just not with mongrel support, thus only 1 script instead of 3
<SpamapS> glenn___: right
<glenn___> spamaps: that makes things a lot easyer. i suppose i should focus on that then :)
<SpamapS> glenn___: right, and I think at this point.. we're a couple of days from beta2 freeze.. its bugfixes only... what you've done is a fantastic feature. :)
<glenn___> spamaps: hopefully the first of many to come :)
#upstart 2012-03-21
<atpa8a> wow
<atpa8a> unexpectedly there's a channel :)
<atpa8a> hello
<atpa8a> why would ubuntu say 'Starting OpenSSH Server [OK]' followed by 'Stopping OpenSSH Server [OK]' for every NIC or alias during boot?
<m15k> Hi is it enough to place a conf in /etc/init to ensure that a serivce is started on boot?
#upstart 2012-03-22
<codebeaker> how can I (easily) HUP to reload a process
<codebeaker> everything says "initctl reload <myjob>" - but as far as I can ascertain that's simply for reloading initctl's config file for that job
<codebeaker> I'm wroking with three daemons which respond to HUP by seamlessly rebooting themselves with zero-downtime
<codebeaker> I don't really feel like going back to systemv init scripts, or reading pidfiles and sending HUPs - especially as that causes upstart to lose track of them when their PID changes
<ion> Parse the pid from the output of initctl status job, send HUP to that.
<ion> pid=; eval "$(initctl status foo | sed -nre 's|^cron start/running, process ([0-9]+)$|pid=\1;|p')"
<ion> if [ -n "$pid" ]; then â¦
<codebeaker> thanks ion, that's a bit cleaner
<codebeaker> but when teh pid changes, initctl will still lose track of it, right ?
<codebeaker> (sorry, didn't see your response)
<ion> If the pid changes, please file a bug report against the daemon. :-P
<codebeaker> heh
<codebeaker> Unicorn (web server) treats a USR2 as an invitation to reload itself, it spawns a new master process - and replaces the old one as the worker processes complete their tasks
<codebeaker> so that's a perenial problem
<codebeaker> and in Rails land, booting an application takes 45 seconds
<ion> Perhaps Unicorn could have a very thin parent process that just keeps the child running and dies if the child dies. That would result in a constant pid.
<SpamapS> codebeaker: initctl reload does in fact send HUP to the tracked pid
<codebeaker> but it says that it's used for reloading the initctl script
<SpamapS> codebeaker: anything that forks and then exits multiple times in its lifecycle cannot be tracked by upstart
<SpamapS> codebeaker: wrong, that is reload-configuration
<codebeaker> ok, so that is "restart" is a stop/start
<SpamapS> yes, restart also does not reload the job file between stop/start
#upstart 2013-03-18
<xnox> jodh: apport hooks looks good. use python3 shebang as a reminder that it's executed as python3 by apport. the syntax looks fine so it should be fine =)
<jodh> xnox: mountall hook?
<jodh> xnox: added python3 to upstart+mountall hooks.
<xnox> yes.
#upstart 2013-03-19
<RobOakes> Good afternoon. Is there a command that I can use to check which version of upstart is installed?
<jY> dpkg -l upstart
<SpamapS> initctl --version works too
<SpamapS> but.. RobOakes waited all of 5 minutes for an answer.. :-P
#upstart 2013-03-20
<you-tee-f> how can i change the default run level ?
<jY> start on runlevel [2345]
<jY> ?
<SpamapS> /etc/init/rc-sysinit.conf, btw, if he comes back
<herriojr> hello
<herriojr> I'm having a hard time following documentation on how to handle this scenario:
<herriojr> I have a daemon which can be started and stopped by calling "daemon start" and "daemon stop" respectively
<herriojr> now, initctl will send out the sigterm signal itself, but the daemon catches the sigterm and waits until it is actually safe to shut down, so it can take X amount of time
<SpamapS> herriojr: initctl does not send any signals
<SpamapS> herriojr: it tells upstart to send them from pid 1
<SpamapS> herriojr: if you have an expected lag for your kill signal, you can use 'kill timeout'. man 5 init shows that.
<herriojr> yes, ok, so is it safe to put the "daemon stop" in pre-stop to force it to wait (daemon stop will wait until the daemon has exited before returning)
<herriojr> SpamapS: the issue is due to the nature of the daemon, it's safe point is undetermined
<SpamapS> herriojr: you mean due to the fact that it doesn't handle SIGTERM properly by shutting down gracefully?
<herriojr> SpamapS: yes, and I didn't write the daemon, so I'm having to work around it
<SpamapS> herriojr: or due to the fact that upstart doesn't know its pid, because you need to use pre-stop and post-start to send the 'daemon start' and 'daemon stop' commands?
<herriojr> so it's written like: do some undetermined amount of work; check if sigterm was sent and if so, exit
<SpamapS> herriojr: upstart does not have to track a daemon's pid. You can defer that to those programs by using post-stop (don't use pre-stop) and post-start to run the stop/start commands.
<herriojr> would that mess up a restart?  meaning, restart sends a stop followed by a start and if it wasn't stopped in time, this daemon could get screwed up
<SpamapS> restart is 100% broken and does not run pre-stops actually
<herriojr> ok
<SpamapS> (thats why I say, don't use pre-stop)
<herriojr> great to know
<herriojr> haha ok
<herriojr> ty6
<herriojr> ty
<SpamapS> but I would actually avoid restart if you can
<herriojr> I think that might be enough information for me to try some things out
<herriojr> thanks
<herriojr> kk
<SpamapS> if you use the 'service' command, it does stop/start
<herriojr> ok thanks
#upstart 2013-03-21
<herriojr> so, I'm running a python daemon that starts up with double forking and for some reason "expect daemon" doesn't cause it to track the correct pid and it is tracking the initial pid before any forks take placeâ¦are there known issues with expect daemon?
<xnox> herriojr: how are you launching it?
<xnox> herriojr: is the python daemon launched with exec stanza?
<herriojr> @xnox: not the whole file, but the section you asked for: http://pastebin.com/N70HXzZB
<xnox> herriojr: you want "... all the environment ... exec python <args>" or "exec ... all the environment ... python <args>"
<xnox> try both of those and see if one or both of them work and do what you need.
<herriojr> xnox: are you saying use exec instead?
<herriojr> and can I do that in the script section or do I do it as a separate section?
<xnox> herriojr: just as it is inside script section.
<xnox> herriojr: see line 46 for example https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/xinetd/raring/view/head:/debian/xinetd.upstart#L46
<xnox> couldn't find one with envrionment variables as well.
<herriojr> is that just so it can identify the command that is being daemonized?
<xnox> exec is kind of an indicator as to "start counting forks from here" marker.
<herriojr> ah ok
<xnox> yes.
<herriojr> alright, I figured out my issue: https://bugs.launchpad.net/upstart/+bug/799884
<herriojr> so can "expect stop" be used in place of "expect daemon" to report the pid of the daemon process?
<twb> I'm writing a near-trivial job for an Ubuntu 10.04 system, which is upstart 0.6.5-8.  Are you guys interested in discussing that, or is that old enough to be "upgrade or GTFO" territory?
<twb> http://paste.debian.net/243300/ well anyway, that's what I've got.
<twb> It all works... except "start streamrippers" never exits.  It's starting the individual streamripper jobs OK tho.
<twb> http://paste.debian.net/243301/
<SpamapS> why can't I run init-checkconf as root?
#upstart 2013-03-22
<twb> Anybody awake today?  Still after any input re my question yesterday http://paste.debian.net/243576/
 * twb goes through the cookbook, prepares post to ML
<SpamapS> twb: I had some answers for you
<SpamapS> twb: task blocks until tasks stop. That is the very definition of task
<twb> Cool, thanks
<twb> I still don't get it though -- it's running each of the "start streamripper" instances, and they exit straightaway, so why would the streamrippers task not exit at the end of that
<SpamapS> twb: so you probably just need to remove all the task statements (and the &'s and the waits)
<twb> OK, I'll try
<SpamapS> twb: well your post-stop on streamrippers will actually kill your sudos
<twb> It seemed counter-intuitive to me for the streamrippers job to *not* be a task, because it doesn't actually run anything itself that stays around
<SpamapS> twb: task only means "block until I stop" instead of "block until I start"
<twb> hum, OK
<twb> SpamapS: you were right, thanks a lot.
 * twb rereads the "task" part of cookbook for good measure
<SpamapS> :)
 * SpamapS goes to bed
* jodh changed the topic of #upstart to: Upstart 1.8 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
#upstart 2014-03-17
<cqql> I am looking for something like a `restart on` stanza. Is there a way to do such a thing?
<cqql> To be exact I have a server that is running my app and an upstart job, that run a unicorn server or reloads it, if it is already running. When the app is deployed, I emit an app-deployed upstart event. The thing, that is missing, is a way to restart the unicorn job, when this event is received.
<cqql> I guess, I could make my job an instance job
<jodh> cqql: You can create a second job that specifies something like "start on app-deployed\nexec { stop unicorn || true; } && start unicorn"
<cqql> The problem is, that unicorn does some tricky live reloading stuff instead of actually restarting
<cqql> But I will try this anyway
<JanC> then why not just send that reload signal (or whatever it is using to do that)?
<cqql> I am trying this now
<cqql> So should I make my second job a task (in the upstart sense)?
<jodh> cqql: if unicorn can reload itself without changing pid (ie re-exec's), specify "reload signal SIGNAL" in the unicorn job and have the helper job call "reload" rather than "stop+start".
<jodh> cqql: yes, task would make sense
#upstart 2014-03-19
<Ztyx> I have a "post-start exec" to check my process is fully up. Can "post-start exec" stop my service if it doesn't come up in say, 60 seconds?
<xnox> Ztyx: loop/wait the check for 60s in post-start, exit non-zero. that will stop the service.
<xnox> Ztyx: see (probably the most convoluted way to do so) in http://paste.ubuntu.com/7120379/
<gena2x> Could anyone please tell how to set upstart env with result of shell command?
<gena2x> something like env DATE=$(date)
<Ztyx> xnox: Thanks for give me a push in the right direction. My exec application most certainly exits with 1. I even added a sleep in it just to make sure this wasn't a timing issue. Will I need to use a "post-exec script" for this?
<jodh> gena2x: is this for a system job, or a session job?
<gena2x> jodh, system job
<jodh> gena2x: in which case there isn't really a good way. Either define DATE in your script sections (all of them that need to use $DATE!) or have each script section source /etc/default/myservice.
<Ztyx> Also, will I need to reload upstart if I make changes to /etc/init/?
<gena2x> jodh, got it, thank you
<jodh> gena2x: alternatively, have another job emit an event ('initctl emit my-event DATE=... hello=world') that your job can 'start on' and thus get the value of that event's variables.
<xnox> Ztyx: configs are re-read automatically, but they are applied against /newly/ started jobs only. E.g. if the job is running, you'd need to do: stop myjob; start myjob => for changes to take effect.
<xnox> Ztyx: it's not "post-exec" but rather "post-start" =) so you can do: post-start exec sleep 60; run-my-check
<xnox> Ztyx: that means it will always take 60s to start, the check would run, and if check exits 0 -> all is good your job is started. Otherwise the job will stop.
<gena2x> jodh, ty once again, will put into script section, thats most clear solution in my case.
<Ztyx> xnox: see any errors in this https://gist.github.com/JensRantil/9644545 Seem like it should shut down my application after 10 seconds, right?
<Ztyx> Originally, I tried this https://gist.github.com/JensRantil/9644643 but after looking at the mysql.conf I tried the "post-start script" version.
<xnox> Ztyx: correct, but you have set it to respawn. thus it just respawns again.
<xnox> Ztyx: if you want "exit 1" to stop it, and abort respawns, then you should do "stop; exit 1"
<xnox> Ztyx: see cookbook.
<xnox> Ztyx: or if you are testing, comment out the respawn / respawn limit
<Ztyx> xnox: I see. Goodo to know!
<Ztyx> xnox: Still seem to be running when I try this: https://gist.github.com/JensRantil/9644545
<Ztyx> The only difference from previously is that I added "stop".
<Ztyx> The cookbook contains examples for this for pre-start, but I can't find anything like this for post-start. Also, I've tried both "exit 1" and "exit 2" since http://paste.ubuntu.com/7120379/ seem to use both. Still nothing.
<Ztyx> Anyone else with some input as to why my application isn't stopped? Is this supported?
<esperegu_> I would like to start a program after pulseaudio is started. there is not upstart script for pulseaudio but only a script in /etc/init.d/ does that also get monitored and if so what should be the condition for the on start entry?
#upstart 2014-03-20
<Ztyx> Good morning - anyone with any idea as to why https://gist.github.com/JensRantil/9644545 is not stopping my process after 10 seconds?
<Ztyx> Seems like noone here has any idea why https://gist.github.com/JensRantil/9644545 isn't stopping. Is there any mailing list where I could ask about this?
<Ztyx> I posted a question about my issue here: https://serverfault.com/questions/583426/why-is-this-upstart-script-not-stopping-my-process
<xnox> Ztyx: there is mailing list pointed at in the topic - http://bit.ly/ooeNVv
<xnox> Ztyx: can you start that job, and then compare the pid retrieved with $ sudo status myapp, and grepping / finding the pid using e.g. $ ps
<xnox> Ztyx: if they don't match, upstart is tracking the wrong pid. 
<xnox> Ztyx: also your job appears to be invalid.
<xnox> Ztyx: it should be: 
<xnox> chdir /my/directory
<xnox> exec java -jar /srv/my.jar
<xnox> as both are just stanzas.
<xnox> Ztyx: it's wrong to include them in a script. SO remove lines 8 and 11.
<Ztyx> xnox: thanks for getting back to me on this. I thought the that mailing list was simply for development of upstart. Now I now. I'll have a lok at your recommendations and will get back on this.
<xnox> Ztyx: that mailing list is for any related topics. about upstart, jobs / configs, init discussions, etc.
<Ztyx> xnox: I've applied to incorrect stanzas but my process is still not getting killed. I've verified "status myapp" gives me that same pid as the running process. I've added the conf and the shell input/output to the gist: https://gist.github.com/JensRantil/9644545
<Ztyx> Any more ideas? Please refer me to the mailing list if you are getting tired of my questions ;)
<xnox> Ztyx: i don't think i can think of anything else, off the top of my head. Do send an email to the mailing list, other developers may help you more.
<Ztyx> Aight. Will do. Thanks!
#upstart 2014-03-21
<gena2x> My job stops during pre-stop script and can't handle signal anymore. Is it possible to tell the upstart that job is already stopped and there is no need to send a signal?
<gena2x> Better to say - 'any way to handle this situation without errors'. I.e. tell upstart that it doesn't need to produce any errors in case if process exit during the pre-stop.
<gena2x> oh, nevermind, problem were that app retuned code !=0 on exit
<xnox> gena2x: in $ man 5 init
<xnox> gena2x: you can read about "normal exit" stanza
<xnox> gena2x: where you can specify "normal" exit return cores and signals.
<xnox> gena2x: normal exit 0 1 TERM SIGHUP
<xnox> gena2x: e.g. such that it's considered "normal" for the process to finish with exit codes "0" "1" and signals "SIGTERM" and "SIGHUP" (signals can be specified with or without SIG prefix)
<xnox> gena2x: this will result in job not getting respawned.
<gena2x> xnox, thank you, i already understood that i made mistake and my problem were in wrong exit code.
<gena2x> xnox, now all fine
<xnox> gena2x: fair enough =)
<gena2x> how to get rid of "main process (pid) killed by TERM signal" in the logs?
#upstart 2014-03-22
<optimusn_> anyone know where I might be able to locate the documentation for 0.6.5 verions of upstart? 
<optimusn_> trying to track down some nasty issues in my Cent distro
#upstart 2015-03-16
<afournier> http://upstart.ubuntu.com/wiki/ ???
<afournier> am i the only to see this on the wiki "A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred." ?
#upstart 2015-03-18
<snappy> I'm writing a daemon in python. I'm thinking about how I would write the upstart to control when it starts/stops/reloads. The PID is managed by the process including stale detection and locking.
<snappy> Can upstart determine if the actual daemon process fails to start (perhaps failure to acquire the lock). The daemon does a double fork, setting a session id, so the immediate parents return exit code 0, whereas the final process may return exit code 1 when trying to start .
<mantsid> hey guys
<mantsid> is there any options to start multiple "workers" of process, like supervisord' numproc?
<Pwnna> I have service, A, that start on starting B. When I run status B in pre-start of A, i see A is start/starting. However, when I run status B in the main script, i see start/running process <pid>?
<Pwnna> s/i see A/i see B
<Pwnna> anyone around?
<Pwnna> is the event filesystem guarenteed to be before the event runlevel?
<exobyte> if I spawn instances of a job from a parent job, they die when the parent job dies, unless there isn't a script/exec block.  Is there a way to get this behavior if there *is* a script block?
#upstart 2015-03-19
<marrusl> fwiw, I have a a 3-4 meeting which might end early.  hard to say yet.  but I have a little time after that.
<marrusl> haha.  wrong window.
<marrusl> doh
#upstart 2016-03-23
<gerow> Hi folks, qq: Is there some way I can detect from the environment if upstart is expecting my daemon to SIGSTOP -- as in it has the 'expect stop' stanza.
<gerow> I know I could just define an environment variable to do that in the config itself...
<gerow> but I was just wondering if such an indicator was provided automagically
