[10:12] <AlexExtreme> oops
[03:53] <asdaf> hello, I have a question, is there any way to prevent script stanzas to be executed by a shell with -e option?
[04:02] <ion_> Why would you not want -e?
[04:02] <AlexExtreme> you can easily prevent the script from terminating if a certain command fails by putting || true after the command
[04:04] <asdaf> ion_, sometimes is a bit constraining
[04:05] <asdaf> you may want to let something fail ignoring the failure
 you can easily prevent the script from terminating if a certain command fails by putting || true after the command
[04:05] <AlexExtreme> you can ^^
[04:05] <asdaf> AlexExtreme, that's what I'm doing
[04:06] <asdaf> but it's not very elegant to put a lot of ||true  in the scripts :)
[04:06] <asdaf> I agree -e should be the normal behaviour
[04:06] <asdaf> but I think it may be useful to have a way to switch off this option
[04:07] <asdaf> say an option in the job description
[04:07] <AlexExtreme> or do like this:
[04:08] <AlexExtreme> pre-start script nofail
[04:08] <AlexExtreme>    blah
[04:08] <AlexExtreme> end script
[04:08] <asdaf> Is this an already implemented option?
[04:09] <AlexExtreme> no, i'm saying an example of how it could be implemented :)
[04:09] <AlexExtreme> if it were implemented i would have told you in the first place :)
[04:09] <asdaf> AlexExtreme, ok :) this would be nice 
[04:10] <Keybuk> why not just put "set +e" at the top of the script?
[04:10] <Keybuk> pre-start script
[04:10] <Keybuk>     set +e
[04:10] <Keybuk>     # broken stuff
[04:10] <Keybuk> end script
[04:10] <AlexExtreme> hmm. that's a point
[04:11] <AlexExtreme> i'm forgetful sometimes ;)
[04:26] <asdaf> Keybuk, right, that's the easiest way :)
[04:27] <asdaf> but i like the syntax AlexExtreme proposed :)
[04:27] <AlexExtreme> well, if there's a way to do it already a new syntax would be pointless
[04:32] <asdaf> AlexExtreme, it's just semantic sugar, but maybe putting it into the script declaration would be more explicit
[04:33] <AlexExtreme> maybe
[04:34] <Keybuk> I don't really see the need for the semantic sugar
[04:34] <Keybuk> -e is a sensible default, and sh gives you a mechanism to turn it off
[04:36] <rgl> hi
[04:37] <rgl> on ubuntu edgy upstart is not installed by default?
[04:38] <AlexExtreme> it is
[04:39] <rgl> mine is not :|
[04:39] <rgl> I've upgraded from previous version.
[04:39] <AlexExtreme> did you upgrade from an older version?
[04:39] <AlexExtreme> ah
[04:39] <rgl> oh, but I did an aptget update, and now it wants to install upstart
[04:56] <Keybuk> the Ubuntu release notes recommend the dist-upgrader tool over apt-get
[04:56] <Keybuk> what's happened is APT has refused to remove the previously Essential sysvinit
[04:56] <Keybuk> without taking into account that sysvinit is no longer Essential, and has been replaced by Upstart
[05:19] <rgl> oh, I see.
[05:19] <rgl> why is the need for anther tool? :|
[05:21] <rgl> humm, but after this apt-get dist-upgrade, the sysvinit was removed, and replaced with upstart.
[05:22] <rgl> humm, not when I do an "apt-get install" it says: 0 upgraded, 0 newly installed, 0 to remove and 29 not upgraded.
[05:23] <rgl> but how can I see the "29 not upgraded"?
[05:24] <rgl> how, they show up when I do: apt-get -s dist-upgrade ...
[05:25] <rgl> how can I see the reason for holding back a package?   the 29 packages are all python-* ones
[07:30] <rgl> is there a upstart manual?  some place that shows what events are availble?
[07:30] <Keybuk> any event you emit with initctl is available
[07:32] <rgl> but where are the standard ones defined? 
[07:34] <Keybuk> they aren't at this point
[07:34] <Keybuk> Upstart is still in development, as are the sets of "standard" events
[07:35] <rgl> oh ok.
[07:36] <rgl> the "restart" stanza restarts the daemon if it dies, correct?   and "exec" only starts it once?
[07:36] <AlexExtreme> it's respawn
[07:37] <rgl> oh yes.  "respawn", my bad hehe
[07:38] <Keybuk> you shouldn't use "respawn SOMETHING"
[07:38] <Keybuk> use
[07:38] <Keybuk> respawn
[07:38] <Keybuk> exec /sbin/daemon
[07:38] <Keybuk> -- 
[07:38] <Keybuk> otherwise you'll be bitten when you upgrade to 0.3.x (which only permits respawn on its own line0
[07:39] <rgl> Keybuk, oh, I saw the respawn line on "logd", and it has no exec :|
[07:39] <Keybuk> sure, because the same file in 0.3.x has two lines
[07:42] <rgl> how can I do this: have a "php-fastcgi" service that does nothing (it just emits the "php-fastcgi" event) and have several "php-fascgi-1", "php-fascgi-2", etc, that are started/stop when ""php-fascgi" is started/stoped?
[07:43] <rgl> I can just "exec /bin/true" on "php-fastcgi", and "start on php-fastcgi" on the "php-fastcgi-N"?
[07:47] <Keybuk> why do you want to do that?
[07:49] <rgl> I want to start several PHP FastCGI instances without having to start each one by hand.
[07:50] <esr> Keybuk: Sounds like you're an upstart core dev.
[07:50] <rgl> I mean, I want to "start php-fcgi" and let upstart do a "start php-fcgi-N" for all the PHP FastCGI instances I've defined.
[07:51] <Keybuk> are the instances different in configuration?
[07:51] <Keybuk> esr: s/an/the/ :-)
[07:51] <rgl> Keybuk, they are.  each one open a different unix domain socket.
[07:53] <Keybuk> ok; yeah you could do pretty much what you describe
[07:53] <Keybuk> though the exec /bin/true would terminate and you couldn't stop them with the same command
[07:53] <rgl> how? :)
[07:53] <rgl> yeah, I've did that.  and it just fails to start the other PHP instances *G*
[07:53] <Keybuk> you're using 0.2.7?
[07:54] <rgl> the alternative was to have a master one, but if that master dies for some reason, it will brong the other instances down, and then up again.  which is not good :(
[07:54] <rgl> Keybuk, yes.  0.2.7 on edgy.
[07:54] <Keybuk> try start on php-fastcgi/started
[07:55] <Keybuk> there's an interesting use case for instances here
[07:58] <rgl> Keybuk, like http://pastie.caboo.se/66161  ?
[07:58] <Keybuk> yes, though it'll stop pretty quick
[07:58] <Keybuk> since "/bin/true" doesn't last long
[07:58] <rgl> yeah.  so, no good
[08:00] <rgl> I would be nice to have "virtual" services, that is, a service with no "exec" is a "virtual" service;  when you "start" a virtual service it just "remebers" it is started, and so on.
[08:00] <AlexExtreme> if you use 0.3 you can simply define a job without any exec for the main job iirc
[08:00] <Keybuk> rgl: we have those ;-)
[08:00] <rgl> ah cool :) :)
[08:00] <Keybuk> oh
[08:00] <Keybuk> random bug on your paste
[08:00] <Keybuk> you need "runlevel-2" and "runlevel-1"
[08:01] <rgl> Keybuk, oh, thats a bug on the wiki page then! *G*
[08:01] <Keybuk> the wiki documents 0.3.8
[08:01] <rgl> actually, http://upstart.ubuntu.com/getting-started.html
[08:02] <rgl> is there a backport of 0.3.8 to edgy?  or I can just recompile, and go with it?
[08:02] <AlexExtreme> you'd be better off upgrading to feisty IMO
[08:02] <Keybuk> you can probably just download the packages from feisty and install them
[08:02] <Keybuk> (YMMV, NUSPIS, WVIR)
[08:02] <rgl> AlexExtreme, I can't right now.
[08:05] <rgl> can I go away with just upgrading the upstart package?  or do I have to upgrade all upstart-* ?
[08:05] <Keybuk> all
[08:05] <Keybuk> upstart, upstart-compat-sysv, system-services, startup-tasks, etc.
[08:08] <rgl> "etc" is "upstart-logd"? :)
[08:09] <Keybuk> right
[08:09] <Keybuk>     instance
[08:10] <Keybuk>     for file-exists /etc/event.d/php-fcgi-*
[08:10] <Keybuk> (err, /var/run/php/fcgi.*)
[08:10] <Keybuk>     exec /usr/bin/php5-cgi -b $FILE
[08:10] <Keybuk> bit sticky, but that might work in 0.5
[08:13] <rgl> oh:
[08:13] <rgl> dpkg: regarding upstart_0.3.8-1_i386.deb containing upstart, pre-dependency problem:
[08:13] <rgl>  upstart pre-depends on libc6 (>= 2.5-0ubuntu1)
[08:13] <rgl>   libc6 is installed, but is version 2.4-1ubuntu12.3.
[08:13] <Keybuk> oh
[08:13] <Keybuk> meh, you'd have to rebuild then
[08:13] <Keybuk> crappy packaging system
[08:13] <rgl> but the damn think installated the other packages ... oh oh
[08:14] <Keybuk> you should find packages to downgrade to in /var/cache/apt/archives
[08:14] <Keybuk> if not, download them again
[08:14] <AlexExtreme> dpkg is crappy or just the dependencies? ;)
[08:14] <Keybuk> AlexExtreme: both :p
[08:14] <AlexExtreme> :)
[08:14] <Keybuk> actjal,
[08:14] <Keybuk> actually
[08:14] <Keybuk> dpkg is crappy
[08:14] <Keybuk> since the packages *do* have dependencies, that doesn't stop dpkg from overwriting the old ones though
[08:15] <rgl> Keybuk, what do you mean with "0.5"?
[08:15] <Keybuk> rgl: 0.5 is the version of upstart I'm working towards at the moment; it has a few interesting features
[08:16] <esr> Keybuk: Are the System V runlevels going to continue to have any real meaning in an upstart environment?  I'm asking because I've written a workalike of chkconfig that uses update-rc.d as a back end.
[08:16] <Keybuk> esr: we're always going to have to support packages that assume System V, because they'll exist for as long as vendors support them
[08:16] <rgl> Keybuk, humm, so I can't make it work with 0.3.8?
[08:17] <Keybuk> rgl: you can do it your way with 0.3.8 (have a master job, and use it to start/stop other jobs)
[08:17] <Keybuk> esr: so we'll always ship jobs that run the legacy sysv-rc script
[08:17] <Keybuk> esr: I don't think that runlevels make much sense in a pure Upstart environment, since they're pretty arbitrary and poorly defined across even Linux distros
[08:18] <esr> Can I give you a copy of my chkconfig clone to package with upstart, then?  Some third-party apps expecting a System-V like runlevel setup actually depend on it.
[08:19] <esr> It's pure bash plus sed.  There's a man page.
[08:19] <Keybuk> esr: it'd certainly make sense to have it packaged in Ubuntu
[08:20] <esr> That's what I'm thinking.  I'm running Ubuntu and it's the environmrnt I wrote chkconfig for.
[08:25] <AlexExtreme> hmm, dot compiled with pango and cairo support makes the state machine diagram look so much better :P
[08:27] <esr> Keybuk: Where should I mail the code and man page for your consideration?
[08:27] <AlexExtreme> upstart-devel@lists.ubuntu.com
[08:28] <Keybuk> AlexExtreme: got a patch?  I can fix our graphviz <g>
[08:29] <AlexExtreme> hold on
[08:30] <AlexExtreme> http://ftp.frugalware.org/pub/frugalware/frugalware-current/source/xapps-extra/graphviz/FrugalBuild << the necessary depends and compile options are in there
[08:31] <Keybuk> could you mail that me (scott@ubuntu.com); I'm in the middle of three things right now :-/
[08:31] <AlexExtreme> sure
[08:32] <AlexExtreme> done
[08:48] <esr> Keybuk: Code and man page mailed.  And best of luck on the world domination thing -- I think upstart is very elegant, I'd like to see it win.
[08:50] <Keybuk> thanks
[09:08] <rgl> Keybuk, so, you are working on 0.5, but is there a 0.4? :D
[09:15] <rgl> Keybuk, humm, as of 0.3.8, the logd service still uses respawn /sbin/logd
[09:20] <Keybuk> no, there's no 0.4
[09:20] <rgl> ACK :D
why not?</curiousity>
[09:21] <rgl> oh, there seems to be a bug on 0.3.8.  when you do a "start php-fcgi" (my service that does no have a exec), start never ends :-(
[09:22] <rgl> it stays at prompt waiting for something (stdin?)
[09:22] <AlexExtreme> you need to put the service keyword in the job file
[09:22] <AlexExtreme> otherwise initctl assumes that it needs to wait for something to finish ;)
[09:23] <rgl> what service keyword? :D
[09:23] <AlexExtreme> just write a line saying 'service' in the job file
[09:24] <rgl> humm, but what is initctl waiting for?  there is no exec line, so, why not assumer "service" automatically?
[09:24] <AlexExtreme> well
[09:25] <rgl> AlexExtreme, that did the trick.  thx :D
[09:25] <AlexExtreme> a job without anything to run is a state afaik, so initctl will remain running while the system is in that 'state'. once it is stopped initctl will exit
[09:26] <rgl> you are talking chinese to me hehe
[09:27] <AlexExtreme> heh ;)
[09:28] <rgl> there is a "start", a "stop", but well, no "restart", howcome? *G*
[09:28] <rgl> (comand line utility that is ;)
[09:28] <AlexExtreme> if you want a restart, simply write a script :)
[09:28] <AlexExtreme> #!/bin/bash
[09:29] <AlexExtreme> stop $1 && start $1
[09:29] <rgl> why not follow the route of red-hat with "service start service-name"?
[09:29] <AlexExtreme> :)
[09:38] <rgl> OT: how do I extract the number from the string "php-fcgi-1" using bash? :|
[09:38] <rgl> echo php-fcgi-1 | sed 's,.*-(\\d+),\\1,g' does not seem to do the trick :(
[10:00] <rgl> how do I get the name of the service file from within a "script" block?
[10:03] <rgl> got it... its the UPSTART_JOB env variable (read from http://upstart.ubuntu.com/wiki/JobEnvironmentVariable)
[10:12] <rgl> how, why do I need to have a "service" keyword on the service file? :|
[10:23] <rgl> can't make this work :(
[10:23] <rgl> can you look at http://pastie.caboo.se/66237 ?