#upstart 2007-05-28
<inful> Hi
<inful> I am trying to write upstart-scripts for starting mythbackend/mythfrontend and mtd
<inful> These are supposed to run as the user mythtv, but I keep running into trouble
<inful> This is the /etc/event.d/mythbackend script:
<inful> start on mysql-start
<inful> stop on mysql-stop
<inful> respawn
<inful> script
<inful>         mkdir -p /var/run/mythtv
<inful>         chown -R mythtv /var/run/mythtv
<inful>         su mythtv -c "exec mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log --pidfile /var/run/mythtv/mythbackend.pid"
<inful> end script
<inful> running start mythbackend works, but stop mythbackend doesnt make it stop
<inful> Any pointers?
<inful> Ok, I fixed mythbackend and mtd, but I still have problems with mythfrontend
<inful> fixed:)
#upstart 2007-05-29
<esr> Anybody home?
* AlexExtreme might attempt to have a go at doing a basic implementation of with the profiles
<AlexExtreme> umm
<AlexExtreme> damn enter key
* AlexExtreme might attempt to have a go at doing a basic implementation of the profiles spec this week
<AlexExtreme> there :p
<Keybuk> heh
<Keybuk> I've managed to simultaneously ground myself in both complex-event-config *and* fixing the configuration handling
<AlexExtreme> :)
<Keybuk> though I think there's a light at the end of the c-e-c tunnel
<AlexExtreme> great :)
<ion_> :-)
<Keybuk> it may, of course, be a train
<Keybuk> but that will be welcome relief too  ;)
<foxiness> hi,Is the use of such rccof not impact on the stability of systems? Also I would like to know what happened to inittab?
<Keybuk> foxiness: I'm not sure I understand your question, sorry
<Keybuk> Upstart has never had an /etc/inittab file, it uses a directory of job definitions instead
<foxiness> Okay, I want to use the tool to manage the services, what used to be?
<Keybuk> I'm still not sure I understand, sorry
<Keybuk> are you talking about Upstart on a particular distribution?
<foxiness> am ubuntu user who need tool to control and view service.
<Keybuk> use whatever you have previously used
<Keybuk> Ubuntu doesn't use native Upstart jobs yet
<foxiness> Thanks a lot scott,I also want u to know ,I admire the idea behind upstart.
#upstart 2007-05-30
* AlexExtreme looks through his logs to find that profiles discussion
<AlexExtreme> oops
<asdaf> hello, I have a question, is there any way to prevent script stanzas to be executed by a shell with -e option?
<ion_> Why would you not want -e?
<AlexExtreme> you can easily prevent the script from terminating if a certain command fails by putting || true after the command
<asdaf> ion_, sometimes is a bit constraining
<asdaf> you may want to let something fail ignoring the failure
<AlexExtreme> <AlexExtreme> you can easily prevent the script from terminating if a certain command fails by putting || true after the command
<AlexExtreme> you can ^^
<asdaf> AlexExtreme, that's what I'm doing
<asdaf> but it's not very elegant to put a lot of ||true  in the scripts :)
<asdaf> I agree -e should be the normal behaviour
<asdaf> but I think it may be useful to have a way to switch off this option
<asdaf> say an option in the job description
<AlexExtreme> or do like this:
<AlexExtreme> pre-start script nofail
<AlexExtreme>    blah
<AlexExtreme> end script
<asdaf> Is this an already implemented option?
<AlexExtreme> no, i'm saying an example of how it could be implemented :)
<AlexExtreme> if it were implemented i would have told you in the first place :)
<asdaf> AlexExtreme, ok :) this would be nice 
<Keybuk> why not just put "set +e" at the top of the script?
<Keybuk> pre-start script
<Keybuk>     set +e
<Keybuk>     # broken stuff
<Keybuk> end script
<AlexExtreme> hmm. that's a point
<AlexExtreme> i'm forgetful sometimes ;)
<asdaf> Keybuk, right, that's the easiest way :)
<asdaf> but i like the syntax AlexExtreme proposed :)
<AlexExtreme> well, if there's a way to do it already a new syntax would be pointless
<asdaf> AlexExtreme, it's just semantic sugar, but maybe putting it into the script declaration would be more explicit
<AlexExtreme> maybe
<Keybuk> I don't really see the need for the semantic sugar
<Keybuk> -e is a sensible default, and sh gives you a mechanism to turn it off
<rgl> hi
<rgl> on ubuntu edgy upstart is not installed by default?
<AlexExtreme> it is
<rgl> mine is not :|
<rgl> I've upgraded from previous version.
<AlexExtreme> did you upgrade from an older version?
<AlexExtreme> ah
<rgl> oh, but I did an aptget update, and now it wants to install upstart
<Keybuk> the Ubuntu release notes recommend the dist-upgrader tool over apt-get
<Keybuk> what's happened is APT has refused to remove the previously Essential sysvinit
<Keybuk> without taking into account that sysvinit is no longer Essential, and has been replaced by Upstart
<rgl> oh, I see.
<rgl> why is the need for anther tool? :|
<rgl> humm, but after this apt-get dist-upgrade, the sysvinit was removed, and replaced with upstart.
<rgl> humm, not when I do an "apt-get install" it says: 0 upgraded, 0 newly installed, 0 to remove and 29 not upgraded.
<rgl> but how can I see the "29 not upgraded"?
<rgl> how, they show up when I do: apt-get -s dist-upgrade ...
<rgl> how can I see the reason for holding back a package?   the 29 packages are all python-* ones
<rgl> is there a upstart manual?  some place that shows what events are availble?
<Keybuk> any event you emit with initctl is available
<rgl> but where are the standard ones defined? 
* rgl "initctl emit " does not work with 0.2.7
<Keybuk> they aren't at this point
<Keybuk> Upstart is still in development, as are the sets of "standard" events
<rgl> oh ok.
<rgl> the "restart" stanza restarts the daemon if it dies, correct?   and "exec" only starts it once?
<AlexExtreme> it's respawn
<rgl> oh yes.  "respawn", my bad hehe
<Keybuk> you shouldn't use "respawn SOMETHING"
<Keybuk> use
<Keybuk> respawn
<Keybuk> exec /sbin/daemon
<Keybuk> -- 
<Keybuk> otherwise you'll be bitten when you upgrade to 0.3.x (which only permits respawn on its own line0
<rgl> Keybuk, oh, I saw the respawn line on "logd", and it has no exec :|
<Keybuk> sure, because the same file in 0.3.x has two lines
<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?
<rgl> I can just "exec /bin/true" on "php-fastcgi", and "start on php-fastcgi" on the "php-fastcgi-N"?
<Keybuk> why do you want to do that?
<rgl> I want to start several PHP FastCGI instances without having to start each one by hand.
<esr> Keybuk: Sounds like you're an upstart core dev.
<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.
<Keybuk> are the instances different in configuration?
<Keybuk> esr: s/an/the/ :-)
<rgl> Keybuk, they are.  each one open a different unix domain socket.
<Keybuk> ok; yeah you could do pretty much what you describe
<Keybuk> though the exec /bin/true would terminate and you couldn't stop them with the same command
<rgl> how? :)
<rgl> yeah, I've did that.  and it just fails to start the other PHP instances *G*
<Keybuk> you're using 0.2.7?
<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 :(
<rgl> Keybuk, yes.  0.2.7 on edgy.
<Keybuk> try start on php-fastcgi/started
* Keybuk tries to remember the syntax
<Keybuk> there's an interesting use case for instances here
<rgl> Keybuk, like http://pastie.caboo.se/66161  ?
<Keybuk> yes, though it'll stop pretty quick
<Keybuk> since "/bin/true" doesn't last long
<rgl> yeah.  so, no good
<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.
<AlexExtreme> if you use 0.3 you can simply define a job without any exec for the main job iirc
<Keybuk> rgl: we have those ;-)
<rgl> ah cool :) :)
<Keybuk> oh
<Keybuk> random bug on your paste
<Keybuk> you need "runlevel-2" and "runlevel-1"
<rgl> Keybuk, oh, thats a bug on the wiki page then! *G*
<Keybuk> the wiki documents 0.3.8
<rgl> actually, http://upstart.ubuntu.com/getting-started.html
<rgl> is there a backport of 0.3.8 to edgy?  or I can just recompile, and go with it?
<AlexExtreme> you'd be better off upgrading to feisty IMO
<Keybuk> you can probably just download the packages from feisty and install them
<Keybuk> (YMMV, NUSPIS, WVIR)
<rgl> AlexExtreme, I can't right now.
<rgl> can I go away with just upgrading the upstart package?  or do I have to upgrade all upstart-* ?
<Keybuk> all
<Keybuk> upstart, upstart-compat-sysv, system-services, startup-tasks, etc.
<rgl> "etc" is "upstart-logd"? :)
<Keybuk> right
* Keybuk postulates
<Keybuk>     instance
<Keybuk>     for file-exists /etc/event.d/php-fcgi-*
<Keybuk> (err, /var/run/php/fcgi.*)
<Keybuk>     exec /usr/bin/php5-cgi -b $FILE
<Keybuk> bit sticky, but that might work in 0.5
<rgl> oh:
<rgl> dpkg: regarding upstart_0.3.8-1_i386.deb containing upstart, pre-dependency problem:
<rgl>  upstart pre-depends on libc6 (>= 2.5-0ubuntu1)
<rgl>   libc6 is installed, but is version 2.4-1ubuntu12.3.
<Keybuk> oh
<Keybuk> meh, you'd have to rebuild then
<Keybuk> crappy packaging system
<rgl> but the damn think installated the other packages ... oh oh
<Keybuk> you should find packages to downgrade to in /var/cache/apt/archives
<Keybuk> if not, download them again
<AlexExtreme> dpkg is crappy or just the dependencies? ;)
<Keybuk> AlexExtreme: both :p
<AlexExtreme> :)
<Keybuk> actjal,
<Keybuk> actually
<Keybuk> dpkg is crappy
<Keybuk> since the packages *do* have dependencies, that doesn't stop dpkg from overwriting the old ones though
<rgl> Keybuk, what do you mean with "0.5"?
<Keybuk> rgl: 0.5 is the version of upstart I'm working towards at the moment; it has a few interesting features
<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.
<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
<rgl> Keybuk, humm, so I can't make it work with 0.3.8?
<Keybuk> rgl: you can do it your way with 0.3.8 (have a master job, and use it to start/stop other jobs)
<Keybuk> esr: so we'll always ship jobs that run the legacy sysv-rc script
<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
<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.
* AlexExtreme currently runs a system with absolutely no /etc/rc.d at all ;)
<esr> It's pure bash plus sed.  There's a man page.
<Keybuk> esr: it'd certainly make sense to have it packaged in Ubuntu
<esr> That's what I'm thinking.  I'm running Ubuntu and it's the environmrnt I wrote chkconfig for.
<AlexExtreme> hmm, dot compiled with pango and cairo support makes the state machine diagram look so much better :P
<esr> Keybuk: Where should I mail the code and man page for your consideration?
<AlexExtreme> upstart-devel@lists.ubuntu.com
<Keybuk> AlexExtreme: got a patch?  I can fix our graphviz <g>
<AlexExtreme> hold on
<AlexExtreme> http://ftp.frugalware.org/pub/frugalware/frugalware-current/source/xapps-extra/graphviz/FrugalBuild << the necessary depends and compile options are in there
<Keybuk> could you mail that me (scott@ubuntu.com); I'm in the middle of three things right now :-/
<AlexExtreme> sure
<AlexExtreme> done
<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.
<Keybuk> thanks
<rgl> Keybuk, so, you are working on 0.5, but is there a 0.4? :D
<rgl> Keybuk, humm, as of 0.3.8, the logd service still uses respawn /sbin/logd
<Keybuk> no, there's no 0.4
<rgl> ACK :D
<AlexExtreme> <curiousity>why not?</curiousity>
<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 :-(
<rgl> it stays at prompt waiting for something (stdin?)
<AlexExtreme> you need to put the service keyword in the job file
<AlexExtreme> otherwise initctl assumes that it needs to wait for something to finish ;)
<rgl> what service keyword? :D
<AlexExtreme> just write a line saying 'service' in the job file
<rgl> humm, but what is initctl waiting for?  there is no exec line, so, why not assumer "service" automatically?
<AlexExtreme> well
<rgl> AlexExtreme, that did the trick.  thx :D
<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
<rgl> you are talking chinese to me hehe
<AlexExtreme> heh ;)
<rgl> there is a "start", a "stop", but well, no "restart", howcome? *G*
<rgl> (comand line utility that is ;)
<AlexExtreme> if you want a restart, simply write a script :)
<AlexExtreme> #!/bin/bash
<AlexExtreme> stop $1 && start $1
<rgl> why not follow the route of red-hat with "service start service-name"?
<AlexExtreme> :)
<rgl> OT: how do I extract the number from the string "php-fcgi-1" using bash? :|
<rgl> echo php-fcgi-1 | sed 's,.*-(\\d+),\\1,g' does not seem to do the trick :(
<rgl> how do I get the name of the service file from within a "script" block?
<rgl> got it... its the UPSTART_JOB env variable (read from http://upstart.ubuntu.com/wiki/JobEnvironmentVariable)
<rgl> how, why do I need to have a "service" keyword on the service file? :|
<rgl> can't make this work :(
<rgl> can you look at http://pastie.caboo.se/66237 ?
#upstart 2007-05-31
* Starting logfile irclogs/upstart.log
* AlexExtreme wonders whether it would be better to define profiles in seperate files for each profile rather than a single file
<AlexExtreme> it would be much easier to work with IMO
<Keybuk> profiles are interesting
<Keybuk> one could almost define them as a state in their own right
<AlexExtreme> yes
<Keybuk> which means you'd be able to turn them on/off during system runtime
<AlexExtreme> if I were to use seperate files for each profile, what would be a good directory name for the profiles to live in? i thought /etc/bootprofiles.d, but a) it's a bit long b) profiles wouldn't just be used during boot :)
<AlexExtreme> hmm, just a random thought: how about a directory structure like this for upstart:
<AlexExtreme>  /etc/upstart
<AlexExtreme>          |-----> profiles.d/ - Profiles defined here
<AlexExtreme>          |-----> jobs.d/     - Jobs defined here
<AlexExtreme>          |-----> states.d/   - States defined here
<AlexExtreme> So instead, everything would live under /etc/upstart/something rather than scattered in many directories in /etc
<Keybuk> I've been thinking of that, yeah
<AlexExtreme> and /etc/event.d is incorrectly named anyway, since they aren't events really, they're jobs and states ;)
<Keybuk> yeah
<Keybuk> I'd thought of /etc/init instead of /etc/upstart
<AlexExtreme> maybe
<AlexExtreme> shall I write a spec for a new directory structure? ;)
<Keybuk> I don't think it needs one at this point ;)
<Keybuk> it's a one-line code change <g>
<AlexExtreme> :P
* Keybuk debates the ".d"
<AlexExtreme> the .d is unnecessary, really
<AlexExtreme> it'd only be necessary really if there was something like: /etc/upstart/jobs - some static file, and /etc/upstart/jobs.d - a directory to do with that static file
<AlexExtreme> since that static file is not there, and most likely won't ever need to be there, the .d is unnecessary
<Keybuk> yeah that's what I thought
<Keybuk> though it does fit other standard naming
<Keybuk> e.g. /etc/udev/rules.d
<Keybuk> and upstart will actually support single-conf-files
<Keybuk> (I'm gonna push for 0.3.9 at the weekend, while my partner is away <g>
<AlexExtreme> cool
<AlexExtreme> so what super-duper-cool features are we gonna have? ;)
<Keybuk>  - portability fixes
<Keybuk>  - bug fixes
<Keybuk>  - works when there's no console support by default (openvz, etc.)
<Keybuk>  - internal rework of Event
<Keybuk>  - multiple configuration file and directory support
<Keybuk>  - "reload" support for configuration
<Keybuk>  - new initctl commands to replace use of signals
<Keybuk>  - new config layout
<Keybuk> that lot
<AlexExtreme> <Keybuk>  - new config layout << what's that one?
<Keybuk> see above ;)
<Keybuk> we just agreed on that, no? :p
<AlexExtreme> oh
<AlexExtreme> i thought that was this one: <Keybuk>  - multiple configuration file and directory support
<AlexExtreme> anyhow, sounds good :)
<Keybuk> that one is the code support in cfgfile to support tracking what config directories/files have been parsed, and which jobs were found in them
<Keybuk> looks something like
<Keybuk>   cfg_source_new (NULL, "/etc/init/jobs.d", NULL);
<Keybuk>   cfg_source_new (NULL, "/etc/init/states.d", NULL);
<Keybuk>   cfg_reload ();
<AlexExtreme> ah
<AlexExtreme> whoo, written my basic profile parser :p
<rgl_> Keybuk, 0.3.9 will work inside a linux-vserver guest?
<Keybuk> rgl: in theory
<rgl> Keybuk, it will use syslog instead of /dev/console ?
<Keybuk> no
<Keybuk> it reopens /dev/console properly
<rgl> Keybuk, humm, but there is no /dev/console 
<Keybuk> there's always a /dev/console
<rgl> no there isn't ;)
<rgl> you have to either link it to /dev/null, or start up syslog-ng to create a pipe at /dev/console
<rgl> (linux-vserver does not have a virtualized /dev/console)
<Keybuk> it still exists in the kernel
<rgl> sure.  but last time I've checked, its not advised to export it to guests.
<Keybuk> syslog won't be running, because this is init :)
<rgl> humm, good point *G*
<AlexExtreme> well, what does sysvinit do? :)
<rgl> by default, a linux-vserver does not start init.  it just runs /etc/init.d/rc
<rgl> but we can make it run init.  but last time I've tried, I failed to make upstart work at all :-(
<Keybuk> AlexExtreme: opens /dev/null
<AlexExtreme> rgl: then what is the parent of all the processes? surely when rc exits it'll drop dead since process #1 has died
<rgl> AlexExtreme, there is a "virtual" #1.   the guest will stay awake until all its processes die.  (and not when #1 dies)
<AlexExtreme> ah
<Keybuk> what reaps children?
<rgl> I think its that "virtual" #1.
<rgl> but I don't known for sure.  there is some magic/vudu out there *G*
<rgl> anyways, last night, I couldn't make upstart 0.3.8 do what I want :-(
<rgl> can you guys look at http://pastie.caboo.se/66469 and tell me if I'm doing something wrong?
<rgl> namely, when I "start php-fcgi", the "php-fcgi-1" does not start at all.
<Keybuk> I don't see why that shouldn't work
<Keybuk> run in another window
<Keybuk> "sudo initctl events"
<Keybuk> then do "start php-fcgi" and paste the output of initctl from the other window
<rgl> OK.  give me a sec to fireup vmware. :D
<rgl> Keybuk, odd.  it now works!
<rgl> Keybuk, do I have to restart upstart after I add a new service file or something like that?
<Keybuk> shouldn't need to
<Keybuk> 0.2.7 had bugs where it didn't notice
<Keybuk> 0.3.8 should work just fine
<Keybuk> if you have experienced bugs, we'd like to get them fixed :p
<rgl> I can't reproduce the problem I had yesterday.  but sure, if I found some bug I'll let you known.
<rgl> I found one quirk that is bugging me, if a process fails to restart for five(?) times in a row, upstart never tries to launch it again, it that normal?  can I config it?
<Keybuk> right
<Keybuk> you'll see a "respawning too fast" type warning
<Keybuk> I think it's attempting to respawn 5 times in 10 seconds
<Keybuk> it's configurable
<Keybuk>   "respawn limit COUNT PERIOD"
<Keybuk> e.g.
<Keybuk>   respawn limit 100 10
<Keybuk> (stop job if it respawns more than 100 times in any 10s period)
<rgl> ah nice :D
<Keybuk> if either of them are 0, then the respawn catching is disabled
<rgl> works on 0.3.8? :D
<Keybuk> most things work on 0.3.8
<rgl> cool :D
<rgl> what you mean respawn catching is disabled?  the service is always restarted?
<Keybuk> yeah
<Keybuk> service is allowed to restart as many times as it likes
<Keybuk> why were you hitting the respawn limit out of interest?
<Keybuk> usually that means that the thing you're exec'ing is dying
<Keybuk> which is bad, no?
<rgl> yes it is a bad thing :D
<Keybuk> why was it dying?
<rgl> I was trying it :D
<rgl> to see how upstart reacted when the service dies
<Keybuk> ah right
<Keybuk> a few notes from scrollback
<Keybuk> "service"
<Keybuk> and "start" doesn't exit
<Keybuk> Upstart has two basic types of jobs
<Keybuk> Tasks and Services
<Keybuk> Tasks are things like "run fsck", or "backup my home directory", etc.
<Keybuk> Services are daemons and stuff
<Keybuk> for tasks, "start" deliberately doesn't exist until it's complete (and events they "start on" aren't deemed finished), since the task is not successful until it exists
<Keybuk> s/exist/exit/
<Keybuk> for services, you want "start" to exit (and events to finish) when it is running, since that's when it's successful
<Keybuk> (a successful fsck is a finished one, a successful web server is a running one)
<Keybuk> they're otherwise identical in configuration
<Keybuk> Upstart jobs default to being tasks
<Keybuk> if you want them to be services, you need to put either "service" or "respawn" in the config
<rgl> woah, thx!  that explains things :-)
<Keybuk> there's a third option as well
<Keybuk> but this is not fully implemented yet
<Keybuk> (supervision on processes that fork into the background)
<Keybuk> -- 
<Keybuk> why failing services still say "started"
<Keybuk> this is because from Upstart's point of view, it has started -- the script is running
<Keybuk> there's no internal way (yet) for the service to notify Upstart that it is, in fact, really running and really ready
<Keybuk> there's two planned improvements here:
<Keybuk>  1 - better catching of exec() failures.  Right now Upstart forks the child and assumes it's running; exec() failures aren't special.  This will change so that the exec() has to finish before Upstart moves the job out of the spawned state (and thus can move directly into stopping if the exec() failed for some reason)
<Keybuk>  2 - libupstart readyness notification.  services that take a while to be ready will be able to use libupstart to notify upstart that they're accepting connections, etc.  if this fails to happen, they can be considered failed, killed, and restarted
<rgl> I see.  thx for the explanation :-)
<rgl> are you also planning on having monit alike-features? :D
<Keybuk> no
<Keybuk> no particular reason to, since monit already has those features
<Keybuk> you can use monit to do the monitoring, and have it tell upstart to restart services, etc.
<rgl> ah ok.
<rgl> maybe monit could be enhanced to do real time monitoring by listening to upstart events.
<Keybuk> I'm a full believer in the "do only one thing well"
<Keybuk> exactly
<Keybuk> same for heartbeat, et al
<Keybuk> it makes no sense for upstart to grow the ability to communicate across serial ports, etc.
<Keybuk> it makes far more sense for the services that already can do that to link to libupstart and emit events, or even start/stop processes themselves
<Keybuk> if you look at initctl, it's just a wrapper around libupstart
<Keybuk> so any process can do whatever it can do
<Keybuk> (ie. list services, start/stop them, emit events, etc.)
<rgl> makes sense :)
<rgl> what is libupstart?
<rgl> I mean, I see no libupstart package
<Keybuk> the IPC library
<Keybuk> see upstart/message.h in the source code
<Keybuk> it's not separately packaged yet, because the API isn't anywhere near stable
<rgl> ah, so its not yet packed as a .so file.
<Keybuk> right, it's an .a file in the source linked to by initctl
<Keybuk> anything initctl does is through libupstart messages
<Keybuk> e.g. "initctl version"
<Keybuk> that's done by something like:
<Keybuk>   int sock = upstart_open ();
<Keybuk>   NihIoMessage *msg = upstart_message_new (NULL, UPSTART_INIT_DAEMON, UPSTART_VERSION_QUERY);
<Keybuk>   nih_io_message_send (msg, sock);
<Keybuk>   msg = nih_io_message_recv (NULL, sock, NULL);
<Keybuk>   upstart_message_handle (NULL, msg, { UPSTART_VERSION, my_func }, NULL);
<Keybuk> my_func (..., const char *version, ...) {
<Keybuk>    printf ("%s\n", version);
<Keybuk> }
<rgl> sweet :D
<rgl> what is NIH?   (not invented here? *G*)
<ion_> NihIoMessage *msg = upstart_message_new (NULL, UPSTART_INIT_DAEMON, UPSTART_I_NEED_CAFFEINE_NOW);
<Keybuk> yes
<Keybuk> ion_: UPSTART_EVENT_EMIT, "i-need-caffeine" :p
<ion_> :-)
<Keybuk> rgl: libnih is my "Copy & Paste" code library
<Keybuk> that stack of code that most developers have of useful bits and pieces that don't quite exist anywhere else
<Keybuk> it's roughly akin to glib, or the hackerlab lib, etc.
<rgl> ah, good old misc. utils lib :D
<Keybuk> I should put that in the FAQ?
<Keybuk> "Q. Why do you use libnih and not glib?"
<Keybuk> "A. typedef int gint"
<ion_> Hehe
<rgl> whats the pun? :D
<Keybuk> pun?
<rgl> I didn't get the answer *G*
<rgl> so I suppose its a pun or something like that
<Keybuk> glib provides alternate names for all of the C standard types
<Keybuk> allegedly for portability
<Keybuk> so instead of "int", you have "gint"
<Keybuk> and instead of "char", you have "gchar"
<rgl> so what?
<Keybuk> it's silly
<Keybuk> "gpointer is easier to use than void *"
<Keybuk> no it's not
<rgl> its like having DWORD, UNIT and the like, no? :D
<Keybuk> it's longer to type, and it's not very C-ish
<Keybuk> DWORD makes sense, since it varies between platforms
<Keybuk> and needs to be defined differently in different circumstances
<rgl> the "WORD" is "DWORD" is different for each CPU I guess.  so its like silly too.  unless WORD is not as in CPU WORD.
<Keybuk> glib tries to hide C from the programmer
<Keybuk> you don't program in C, you program in "glib"
<Keybuk> this strange OO-ish variant of C
<Keybuk> this, to me, seems silly
<rgl> C with gobjects :D
<rgl> why do jobs default to task instead of service?
<ion_> Id expect most of the jobs to be tasks eventually.
<Keybuk> rgl: had to pick one
<rgl> why not make it explicit?  
<Keybuk> if "service" was the default, you'd need a "task" stanza
<Keybuk> and then you'd have the issue where you'd have to error if both "task" and "respawn", or "task" and "daemon" were specified
<Keybuk> with "task" as the default, there's no need for any conflicts checking - "service", "respawn" and "daemon" are all possible options; and any of them implicitly enable "service" if not already specified
<Keybuk> explicit is the likely end-point, yeah
<Keybuk> but then that's icky, because you'd need "file doesn't state any of 'task', 'service', 'respawn', 'daemon', 'state', 'profile'" etc.
<Keybuk> another option is to configure them in different directories
<Keybuk> /etc/init/tasks.d
<Keybuk> /etc/init/services.d
<rgl> or "unknown job type" *G*
<ion_> In the long run, multiple directories might be good, as the number of jobs will go up.
<Keybuk> of course, multiple directories has the namespace issue
<ion_> True.
<Keybuk> /etc/init.d/task.d/foo
<Keybuk> /etc/init.d/service.d/foo
<Keybuk> which wins?
<rgl> humm, havin different directories means you'll have different event namespaces?  that is, how you'd wait for a task/service?
<rgl> yeah *G*
<ion_> Neither. Upstart gives an error and doesnt use either one.
<rgl> or foo.task foo.service *G*
<Keybuk> rgl: ick
<Keybuk> :p
<rgl> hehe
<rgl> one thing I would like is "nested" services, that is, php-fcgi, php-fcgi/1, etc :D
* rgl hides
* AlexExtreme deserves to be slapped right now. i spent half an hour figuring out why my profile parser was segfaulting, then realised i wasn't putting braces round the else block so only the first line was being run for it, the rest would always be run ><
<Keybuk> rgl: we kinda have that <g>
<Keybuk> your php-fcgi is an excellent use case for something else we've been thinking of
<Keybuk> and let me explain by first talking about that
<Keybuk> right now we have /etc/event.d/tty[1-6] 
<Keybuk> 6 files, all of which do the same thing, with different arguments
<Keybuk> and each one would need something like
<Keybuk>   while tty-added tty1 until tty-removed $TTY
<Keybuk>   exec /sbin/getty 38400 tty1
<Keybuk> eurgh
<Keybuk> it would be better to have one getty job that runs 6 times, with different arguments
<Keybuk> we have this kind of thing already
<Keybuk> "instance" jobs
<Keybuk> if you put the "instance" keyword in the config file, then every "start" will spawn off a new instance
<Keybuk> so "status php-fcgi" would return as many lines as "start" has been called
<Keybuk> likewise for events
<Keybuk> so, we could have a single getty job:
<Keybuk>   instance
<Keybuk>   while tty-added tty[1-6]  until tty-removed $TTY
<Keybuk>   exec /sbin/getty 38400 $TTY
<Keybuk> that'd get run 6 times, since six matching "tty-added" events would occur
<Keybuk> and each one would run until its associated tty was removed
<Keybuk> your example would work very well with file events
<Keybuk>   instance
<Keybuk>   while file-exists /var/run/php/fcgi.*
<Keybuk>   exec /usr/bin/php5-cgi -b $FILE
<Keybuk> you'd get as many events as you had matching files, and thus as many instances of that job
<Keybuk> "status" would show them all
<Keybuk> "start" would have to specify which file it wanted to start with ...
<Keybuk>    # initctl start php-fcgi FILE=/var/run/php/fcgi.foo
<Keybuk> "stop" would have to specify which instance to stop; or "stop php-fcgi" would stop them all
<rgl> hum, so to start an instance we just need to touch a file?   and to stop it we just need to rm it?
<Keybuk> yeah
<rgl> all FS have notifications? 
<Keybuk> inotify is in the VFS layer, so yeah
<rgl> you are targetting linux only?
<Keybuk> absolutely
<Keybuk> Upstart is unashamedly dependant on features of the Linux kernel
<rgl> okay :D
<Keybuk> I think the above is a pretty elegant solution, what do you think?
<rgl> its pretty neat :D
<rgl> at least for this particular use-case :-)
<rgl> can I have it now? ;-)
<Keybuk> soon
<Keybuk> the instance bit works now
<Keybuk> the tying instances to events bit depends on complex-event-config
<Keybuk> and you'd want file events as well, which are todo
<rgl> cool :D
<AlexExtreme> bah
<AlexExtreme> Keybuk, can you help me with NihList quickly? :)
<Keybuk> sure
<AlexExtreme> hang on
<AlexExtreme> http://frugalware.org/paste/1453 << ok, that's my code. it's probably really ugly, but anyway :) the loop at the bottom goes through each of the things i've added to the list and prints them out, but it prints out complete rubbish and uses the wrong value for disabled. so obviously i'm adding stuff incorrectly. it's mostly based on what i've seen from notify.c in upstart
<AlexExtreme> s/disabled/enabled/
<Keybuk> style: "NihList entry" is nominally the first thing in a struct
<Keybuk> (nothing assumes this, but it's just a style point)
<AlexExtreme> heh
<AlexExtreme> well
<AlexExtreme> that kinda fixed it :p
<Keybuk> you don't need NIH_LIST_FOREACH_SAFE
<Keybuk> just NIH_LIST_FOREACH will do
<Keybuk> aha!
<Keybuk> yes, the iter points you're getting are pointers to the entry member
<Keybuk> so you can't just cast them to upstart_profileentry_t
<Keybuk> (this is the reason I always put the NihList entry first <g>)
<AlexExtreme> :)
<AlexExtreme> well
<AlexExtreme> now i'm getting this
<AlexExtreme> [14:09:35]  [ alex in ~/Frugalware/work/upstart/profile ]  $ ./profile default 
<AlexExtreme> Parsing profile default...
<AlexExtreme>  * Everything will be enabled by default but can be overridden
<AlexExtreme>  * network will be enabled no matter what
<AlexExtreme> but, it doesn't seem to recognise the fact that there is also an apache entry there somewhere
<AlexExtreme> [14:10:39]  [ alex in ~/Frugalware/work/upstart/profile ]  $ cat default 
<AlexExtreme> * = y
<AlexExtreme> apache = y
<AlexExtreme> network = n
<Keybuk> you free the job in the loop ;)
<AlexExtreme> oops
<AlexExtreme> :p
<AlexExtreme> [14:11:22]  [ alex in ~/Frugalware/work/upstart/profile ]  $ ./profile default 
<AlexExtreme> Parsing profile default...
<AlexExtreme>  * Everything will be enabled by default but can be overridden
<AlexExtreme>  * apache will be disabled no matter what
<AlexExtreme>  * network will be enabled no matter what
<AlexExtreme> yay \o/
<AlexExtreme> thanks ;)
<AlexExtreme> now to make it check against files in /etc/event.d
<rgl> "stop on runlevel [!1] " is that a stop on runlevel not 1 ?
<Keybuk> yes
<rgl> is so, why the []  ?
<Keybuk> fnmatch()
<Keybuk> standard UNIX glob(7) syntax
<rgl> the runlevel arg is a glob?
<Keybuk> yes
<rgl> ah alright :D
<Keybuk> arguments to events in "on" are globs
<rgl> I can have: stop on runlevel 1 2 3 ?
<Keybuk> so that means stop on any runlevel event with a single-character argument that is not the character "1"
<Keybuk> no
<Keybuk> stop on runlevel [123
<Keybuk> stop on runlevel [123] 
<Keybuk> the runlevel event has a single argument, the runlevel being entered
<rgl> ACK :)
<Keybuk> I realised the other day that the runlevel event should have a RUNLEVEL and PREVLEVEL environment variable
<Keybuk> then I could do away with all of the code in the rc jobs
<Keybuk> runlevel would update utmp and emit the event itself
<Keybuk> err, telinit would
<Keybuk> then I could do away with runlevel --set
<rgl> how do I make sure the admin does not start an service because another one is not running?
<rgl> something like dependencies.
<rgl> oh well, scrap that.  if it depends on other, and that one is not started, the start of the service will eventually fail because of that.  so the admin will notice that somehing is not right.
<Keybuk> how do you mean
<Keybuk> right
<AlexExtreme> hooray! http://frugalware.org/paste/1454
<rgl> Keybuk, what is the behaviour of jobs that are symlinks?   I mean, I have a symlink: php-fcgi-3 -> php-fcgi-1 and when I change php-fcg-1 job file, and do a: stop php-fcgi-3 ; start php-fcgi-3;  upstart does not reload the job file.  Is that intended?
<Keybuk> err
<Keybuk> yes :-)
<AlexExtreme> iirc inotify has some bugs with symlinks
<Keybuk> either we need to handle symlinks specially, or inotify needs to handle them specially
<Keybuk> use hardlinks for now :o)
<rgl> ok :D
<AlexExtreme> kernel command line arguments that the kernel doesn't use are passed to init, right?
<Keybuk> AlexExtreme: foo=bar arguments are set in init's environment
<Keybuk> AlexExtreme: anything else is an argument, yes
<AlexExtreme> ah, cool. so if i were to do what my profiles spec says on the kernel command line, i'd get the requested profile in the environment?
<Keybuk> right
<Keybuk> except upstart doesn't pass those yet (bug)
<rgl> Keybuk, ouch, even hardlinks do not work *G*
<Keybuk> heh
<Keybuk> really?
<Keybuk> interesting
<rgl> yup, really.  I had to touch the file to upstart to reload it.
<Keybuk> that's odd
<Keybuk> since touching the file is the same effect as editing it, no? :p
<Keybuk> maybe it's touch-by-name
<rgl> the point is.  if I edit the config file (say, on hardlink 1), I have to touch all the other hardlinks too.
<rgl> so I really need that "instance" feature you've talked yearlier, or else I might be biten in the arse someday heheh
<AlexExtreme> i don't need upstart to pass them to the jobs, i need it from upstart itself :)
<AlexExtreme> (the environment vars)
<AlexExtreme> hmm
<AlexExtreme> is the profile override on the kernel command line thing that I put in the profiles spec really necessary? I can't really think of a valid use case for it
<Keybuk> dunno, I can't remember what it was for?
<AlexExtreme> The profile can be overridden at boot-time by specifying extra kernel command line arguments, like the example below. It tells upstart to use the "noserver" profile but overrides what the profile defines should be done with mysql and postgresql:
<AlexExtreme>     *
<AlexExtreme>       bootprofile=noserver override=mysql:no,postgresql:no
<AlexExtreme> it's just the override part i'm referring to
<Keybuk> oh right
<AlexExtreme> you should definitely be able to change the profile at boot :)
<Keybuk> and after booted? :p
<AlexExtreme> yes, of course :P
<AlexExtreme> actually
* AlexExtreme rewrites the spec ;)
<Keybuk> which begs the question, do the jobs respond to the events, and just not start
<Keybuk> so when you re-enable the profile, they start immediately
<AlexExtreme> IMO they shouldn't immediately start
<Keybuk> why not?
<Keybuk> if I enable multiuser, shouldn't things like getty start? :p
<AlexExtreme> true
<AlexExtreme> that, of course, makes life a lot harder :) (at least, afaik)
<AlexExtreme> http://upstart.ubuntu.com/wiki/Profiles << how's that?
<rgl> I have to ask this.  why a file and not a directory with the jobs you want on a profile?
<AlexExtreme> huh?
<AlexExtreme> the file only lists the names of the jobs
<rgl> and the directory would too.  you just need to have a file named after the job name.
<rgl> that way, its easier for a package to add a job into a profile.  (it doesn't need to edit a file).
<AlexExtreme> there would be a utility to do that
<AlexExtreme> so the packages would just call a utility
<AlexExtreme> and you wouldn't be able to do the * with that, nor disable jobs easily
<AlexExtreme> and it requires you to use symlinks
<rgl> I like the directory better.  *G*
<rgl> if you don't want a job in a profile, that create a file for it.
<rgl> if you don't want a job in a profile, don't create a file for it.
<AlexExtreme> i don't see why it's better, all i can see are disadvantages
<rgl> *srug*
<rgl> maybe the command should be named "profile" as in "initctl profile new-profile-name"?
#upstart 2007-06-01
<ribo> how do I get a proper serial console with upstart?
<asdaf> Hi all
<Keybuk> hi
<reppel> Hi, is it possible to define something i call "systemup" which should be emited when two jobs are finished?
<reppel> for instance "networking and fs"
<Keybuk> within upstart?  not directly
<Keybuk> you can obviously run "initctl emit systemup"
<reppel> yes but how do i know when both net and fs jobs have finished?
<Keybuk> that's being worked on at the moment
<reppel> ah ok thank you
<AlexExtreme> hmm that profile syntax looks better ;)
<Keybuk> heh
<Keybuk> the primary advantage would be you can parse it with one function call and a table :)
<Keybuk> and then we could have /etc/init.conf
<Keybuk>   profile foo
<Keybuk>     enable *
<Keybuk>     disable bar
<Keybuk>   end profile
<Keybuk>   job bar
<Keybuk>     ..
<Keybuk>   end job
<Keybuk> if we wanted
<AlexExtreme> yeah
<AlexExtreme> i knew nothing about nih/config ;)
<Keybuk> AlexExtreme: it's the code upstart uses for its own config file
<Keybuk> seemed sensible to libraryfy it
<AlexExtreme> yeah
<Keybuk> at that point, you just need two functions, cfg_stanza_enable and cfg_stanza_disable ;)
<Keybuk> and look at cfg_stanza_description for the code you need inside
<AlexExtreme> cool, thanks
<Keybuk> (call nih_config_next_arg () to get the job name, then nih_config_skip_comment () to guarantee no more args and move to the next line)
<AlexExtreme> i'll play with it tomorrow
<Keybuk> did you think much about the default or multi-profile stuff?
<AlexExtreme> not much, i've been quite busy this afternoon
<AlexExtreme> had one of my machines drop dead, needed to fix it up
<Keybuk> badness
<AlexExtreme> brb, dinner
#upstart 2007-06-02
<ion_> Why not make enable * implicit in the Profiles spec?
<AlexExtreme> ion_, you mean, everything enabled by default?
<ion_> Just as if theres enabled * at the beginning of each profile, just make it implied. To override it, add disabled * at the beginning.
<AlexExtreme> yes, in the test parser I wrote, if no value for * was explicitly defined, it would imply "enable *"
* AlexExtreme should write that on the spec
<AlexExtreme> added
<ion_> In this example every job file would be taken into account apart from apache. The enabled * line should be removed from that one, right?
<ion_> Or add a comment that the line isnt really needed.
<AlexExtreme> changed
<ion_> Nice
<Keybuk> hi-ho
<wasabi> howdy long time no seen
<Keybuk> howdy
<Keybuk> stranger
<Keybuk> ;)
<wasabi> so how's upstart been going. ;)
<Keybuk> still stuck on complex-event-config
<Keybuk> lol
<wasabi> heh
<wasabi> I dunno, everytime I come to this I think maybe it is too complex. :)
<Keybuk> loll
<Keybuk> we think that it would be nice if you could have one single getty job
<Keybuk>   instance
<Keybuk>   respawn
<Keybuk>   while tty-added tty[1-6]  until tty-removed $TTY
<Keybuk>   exec /sbin/getty 38400 $TTY
<wasabi> Maybe a simple service dependency thing is the best.hmmm
<wasabi> oops
<Keybuk> ? :)
<wasabi> didn't mean to send that line. it was sitting in my buffer
<wasabi> I was going to delete it. ;)
<Keybuk> lol
<wasabi> Nothing to see here, move along
<wasabi> I don't really see why having one job for that is any better than 6
<Keybuk> a) neatness
<Keybuk> b) solves the Xen problem (tty2-6 don't ever exist!)
* Keybuk resumes attacking config file reloadin
<Keybuk> this is trickier than it seems
<Keybuk> since you need a list of configuration directories,
<Keybuk> and for each of those a list of configuration files,
<Keybuk> and for each of those a list of jobs you found there.
<AlexExtreme> hmm
<AlexExtreme> my new profile parser using nih/config seems to work
<AlexExtreme> http://frugalware.org/paste/1475
<Keybuk> shiny
<ion_> (offtopic) I bought a camera today. http://heh.fi/tmp/kuplaraama
<wasabi_> Keybuk: Did you ever really come to some sort of conclusion about how tracking levels (period between events) works when reloading Upstart, or installing new job files?
#upstart 2007-06-03
* AlexExtreme wonders if NihHash would be a better storage type for the list of profile entries
<rgl> hi
<rgl> AlexExtreme, why is this """When a job is disabled by the current profile, it still responds to events, it'll just not actually start. If the system is currently in a state when it can be running, and the profile is changed to one which allows it to be run, it'll start.""" ?
<rgl> why to refuse to start a job?
<AlexExtreme> because that's what disabling a job is?
<rgl> I mean, if the admin wants to start a job that is not in the current profile, why should he be refrained from starting it anyways?
<rgl> for me "disabling" is "disabling the service from being automatically started"
<AlexExtreme> rgl, it would only be disallowed from starting if the profile specifically states that that job is disabled, and even then it could still be started manually
<rgl> yes, I understood that.  what I don't understant is why :D
<rgl> "why you want to do that"
<AlexExtreme> <rgl> for me "disabling" is "disabling the service from being automatically started"
<AlexExtreme> that's exactly what it does...
<Keybuk> sounds like you're both arguing for the same thing :)
<AlexExtreme> you can still start it manually
<rgl> ah :-)
<rgl> sorry for the confusion :D
<Keybuk> that makes the most sense to me as well
<Keybuk> "disabled" jobs don't react to events, but still show up in lists, and can still be manually started/stopped
<AlexExtreme> yeah
<AlexExtreme> hmm
<AlexExtreme> in terms of profiles, i'll be doing lookups by name quite often, both when parsing a profile and starting a job. so a hash would be more efficient
<AlexExtreme> and i hadn't thought of using wildcards for job name matching. hrm
<rgl> ah, so my email has something useful? :-)
<AlexExtreme> yep :p
<Keybuk> the interesting thing about Profiles, compared to the original Flags idea, is that Profiles are defined separately to Jobs
<Keybuk> for Flags, the idea was that a Job listed the states it was enabled/disabled in
<Keybuk> the thing I like about Profiles is that it's up to the sysadmin how Jobs are grouped
<AlexExtreme> yes
<AlexExtreme> IMO it's much more flexible
<Keybuk> so this has got me thinking a bit
<Keybuk> Profiles are fundamentally groups of Jobs
<Keybuk> "these are the jobs that do things with networking"
<Keybuk> "these are the jobs that do multi-user things"
<Keybuk> "these are the jobs when the machine is acting as a web-server"
<Keybuk> (I often used runlevel 3 in sysvinit for the latter, so I could turn on/off apache/postgresql/etc. which were expensive to run)
<Keybuk> does that sound kinda right?
<AlexExtreme> yeah
<Keybuk> an interesting side-effect of the "disable means no auto-start" functionality is that if you disabled udev, then you inherently disable all jobs that react to udev events
<Keybuk> so that's quite nice
<rgl> can we please have multiple profiles active? :D
<rgl> though, that goes against the word "profile", so maybe we should have job groups *G*
<rgl> ("job groups" the name)
<AlexExtreme> side note: i noticed the kbdrequest event earlier - what exactly is it useful for?
<Keybuk> AlexExtreme: I think it's supposed to be "spawn a new getty" *shrug*
<Keybuk> rgl: yeah, that's what I've been thinking
<Keybuk> since a Profile basically acts as a group of Jobs
<Keybuk> maybe we don't need to specify enable/disable in a profile
<Keybuk> instead it just needs to include jobs by name
<Keybuk> and then you can enable/disable a profile
<AlexExtreme> this profiles idea gets more complicated by the day *g*
<rgl> and have a directory with all the jobs in the profile (instead of a file;  like I've said some of this day hehe) *G*
<AlexExtreme> no
<AlexExtreme> i will never, ever have that. it'd be a complete mess. we might as well just go back to /etc/rc*.d...
<Keybuk> rgl: why would a directory be good?  then a job couldn't be in multiple profiles
<AlexExtreme> that'd be possible, of course, with nice symlinks all over the place
<Keybuk> AlexExtreme: well, if a profile is just a list of jobs, and enabled/disabled, you just need to check whether any of the profiles the job is listed in are disabled
<Keybuk> eww, symlinsk
<Keybuk> symlinks are evil as a configuration mechanism
<rgl> you chould just touch the file.
<rgl> (no symlink)
<Keybuk> empty files?
<Keybuk> that's just as bad <g>
<AlexExtreme> there'd be still little files everywhere
<Keybuk> very djb-ish
<AlexExtreme> yeah
<AlexExtreme> that's what i hated with djb/runit :P
<rgl> djb-ish is good for ya!
<rgl> I love it :D
<AlexExtreme> service == directory and scripts/files inside
<AlexExtreme> why not just one file?
<Keybuk> my Profiles musing went a bit further ,.. <g>
<Keybuk> if a profile is a list of jobs, and if a profile can be disabled or enabled
<rgl> its easier to admin using regular CLI tool?  touch/rm vs using a command to parse the file and do that.
<Keybuk> then you could link profiles to a state <g>
<AlexExtreme> rgl, how is it easier? it'd be a complete nightmare for the distro developers
<rgl> AlexExtreme, nightmare?  why?
<Keybuk> touch vs vi is pretty even
<Keybuk> the modify command approach is better, since it can guarantee integrity
<Keybuk> (what is the behaviour if you touch the name of a job that doesn't exist?)
<rgl> Keybuk, its the same has using vi and inserting it in the profile file ;)
<Keybuk> rgl: exactly, there's no admin difference
<rgl> Keybuk, there is.  to enable a service you have to use upstart-profile-enable-service service vs touch something
<Keybuk> ?
<Keybuk> no, you can use vi
<AlexExtreme> or easier:
<AlexExtreme> echo "enable myjob" >> /etc/init/profiles.d/myprofile
<rgl> Keybuk, why did debian decide to use enabled-sites/ directories instead of using "Include" in the file?
<rgl> AlexExtreme, and to remove? :D
<AlexExtreme> sed -i '/enable myjob/d' /etc/init/profiles.d/myprofile
<rgl> AlexExtreme, my point is, you have to use a command for doing it.  but its a mater of taste *shrug*
<rgl> AlexExtreme, obsioly, thats not that simple.
<AlexExtreme> you have to use a command if you've got directories too
<rgl> AlexExtreme, you have to skip comments, etc.
<rgl> lets not paint the bikeshed anymore ;-)
<Keybuk> rgl: how do you comment out the disabling of a service with your method?
<rgl> Keybuk, humm, I was not thinking of disabling jobs.  this was a "enable only" thing.  if you want to disable the job, just rm the job from the profile.
<AlexExtreme> take this as an example:
<AlexExtreme> if a distro developer provided a job with a package and wanted that job enabled in all profiles by default
<AlexExtreme> they'd have to go through each profile and add it in
<Keybuk> rgl: no, I just want to comment it out for a while
<Keybuk> you can't do that with the file technique
<Keybuk> and you can't document why it's removed
<Keybuk> # keybuk - think this is breaking networking - 02jun07
<AlexExtreme> surely it would be easier to just put it in /etc/event.d or whatever and have the profile "enable/disable *" lines handle it
<Keybuk> # ntpdate
<rgl> AlexExtreme, document?  use a automated thing to administer your box? :D
<rgl> err
<rgl> that was for Keybuk :D
<AlexExtreme> huh?
<AlexExtreme> what has an "automated thing" got to do with anything?
<rgl> AlexExtreme, with the "document" part that Keybuk said.   
<AlexExtreme> i still don't get what it's got to do with that
<AlexExtreme> brb, lunch
<Keybuk> anyway, it's my bikeshed, and we're using configuration files; not directories-o-symlinks or djb madness <g>
<rgl> I was just saying that the "document" part could be addressed by your automated tool.  (if you don't use one, yeah, it sux, and you can't document)
<Keybuk> you can't document in the model you suggest though
<rgl> Keybuk, fair enough :-)
<Keybuk> you'd need another directory of documents about why things aren't in another one
<AlexExtreme> btw Keybuk, it'd make sense to put all the profile stuff into a seperate source file (like profile.{c,h}) rather than sticking it onto the parsing stuff in cfgfile.c, right? if i were to put it in cfgfile.c it'd allow you to put job stanzas in profiles and vice-versa, which isn't what i want, really ;)
<Keybuk> it should have a separate stanzas list, yes
<AlexExtreme> k
<Keybuk> that file is a little mixed up
<Keybuk> since it has the parsing and watching code too
<Keybuk> (which should be shared)
<AlexExtreme> hmm, profile.c written. now to plug it in to the rest of upstart ;)
* Keybuk keeps hitting namespace problems
<AlexExtreme> with what?
<Keybuk> right now we're relying on the filesystem to provide the namespace
<Keybuk> if we allow people to define multiple jobs in one file, how do we enforce that?
<Keybuk> (likewise for profiles)
<AlexExtreme> hmm
<Keybuk> obviously we have to solve this if we want people to be able to register jobs over the initctl socket
<AlexExtreme> i'm not quite sure i understand
<Keybuk> well
<Keybuk> let's say I make /etc/init/jobs.d/foo
<Keybuk> and I also make /etc/init/upstart.conf and put
<Keybuk>   job foo
<Keybuk>     ...
<Keybuk>   end foo
<Keybuk> in it
<Keybuk> which gets priority?
<Keybuk> (and how do we stop them both fighting)
<AlexExtreme> hrm
<AlexExtreme> i would say the one in upstart.conf gets priority
<AlexExtreme> take this as an example:
<Keybuk> so the first one parsed?
<AlexExtreme> a distribution provides a job called foo, and the user wants to override that job with their own version without editing the one provided by their distro
<Keybuk> (assuming upstart.conf is registered first)
<AlexExtreme> they could put their version in upstart.conf
<AlexExtreme> and it would get priority
<Keybuk> ok, and self-registered would take priority over that?
<AlexExtreme> they could easily revert to the distros version by simply commenting out their version
<AlexExtreme> yes
<Keybuk> that makes it easy then
<Keybuk> a Job just needs to know which CfgSource it was registered with
<Keybuk> and when loading a job from a source, check the source is the same
<Keybuk> though this means you can't move a job from one source to another
<Keybuk> if you delete /etc/init.d/upstart.conf, the jobs.d/foo one wouldn't show up unless touched
<AlexExtreme> it's not that big a problem, and if it could be solved by touching the other one, then it's a minor problem
<Keybuk> I'd prefer it to be solved internally
<Keybuk> we'd need a JobName structure that tracked, for a given name, what was available from each source, and whether each of those things had replacements
<Keybuk> that's a bit sucky, since we'd need the same for Profile and State
<AlexExtreme> hmm
<AlexExtreme> say a job has been disabled in a profile, yet the sysadmin has started it manually. should the job respond to stop events?
<rgl_> I think it should.
<AlexExtreme> me too
<Keybuk> yes
<Keybuk> profiles should just affect start events
<Keybuk> cf. job is running, and sysadmin disables the profile, it should still stop later
<Keybuk> maybe it should stop immediately too
* Keybuk tries to come up with a sensible filename for "job definition parsing"
<Keybuk> in theory, we should be able to use the same pattern for "state definition" and "profile definition"
<AlexExtreme> you mean source file name?
<Keybuk> yeah
<AlexExtreme> parser.c ? :P
<Keybuk> doesn't say "job" though
<Keybuk> so we'd have to put state and profile parsing in the same file
<AlexExtreme> jobparse.c
<Keybuk> and stateparse.c and profileparse.c ?
<AlexExtreme> hmm.
<AlexExtreme> a bit long :p
<Keybuk> heh
<Keybuk> I didn't realise there was a length limit <g>
<AlexExtreme> meh ;)
* AlexExtreme usually tries to keep it short and sweet
<AlexExtreme> well, that's a start
<AlexExtreme> the profile code compiled ;)
<AlexExtreme> i'll test it in a minute :P
<Keybuk> <g>
<Keybuk> you're supposed to write the tests *first* :p
<Keybuk> (not that I ever do)
<AlexExtreme> :P
<wasabi> Heh. I've never found TDD works on a budget.
<Keybuk> I find that about 75% of my coding time is spent refactoring test cases
<Keybuk> which is about the same amount of time I spent figuring out how I broke things
<AlexExtreme> heh
<AlexExtreme> ok, brb. if i don't come back, you'll know it hasn't worked :p
<Keybuk> the net gain of course, is that the 75% now happens *before* I ship the tarball
<Keybuk> AlexExtreme: just comment out the bits of main.c that assume pid()==1 :p
<AlexExtreme> yeeep, i broke it :P
<Keybuk> lol
<AlexExtreme> somehow i'm getting an assertion failure on line 521 in string.c
<AlexExtreme> how, i don't know, because i'm never calling the function that's it
<AlexExtreme> *in
<Keybuk> lol
<Keybuk> what's the backtrace?
<AlexExtreme> where does that come from? :p
<AlexExtreme> core dump?
<Keybuk> yeah
<AlexExtreme> hmm
<AlexExtreme> it would help if the FS was read write
<AlexExtreme> hang on :p
<Keybuk> test_cfgfile.c is annoying long
<AlexExtreme> hmm
<AlexExtreme> well the core dump was officially useless
<AlexExtreme> init was compiled without debug symbols :P
<AlexExtreme> ahhhh
<AlexExtreme> i see what i did wrong :p
<Keybuk> --disable-compiler-optimisations --disable-linker-optimisations --enable-warnings
<Keybuk> :P
<AlexExtreme> profile_get_job_status (job) << usually it helps to pass job->name to that function
<AlexExtreme> let's try again ;)
<wasabi> Keybuk: Yeah, which is great, when you're not on a budget. ;)
<wasabi> Otherwise shipping the 75% is acceptable. Heh.
<AlexExtreme> so it appears i'm managing to do something weird to job->cause
<AlexExtreme> brb, dinner
<Keybuk> woo, test passes
<Keybuk> now to fix valgrind
<Keybuk> easy; just a couple of "returning without freeing if -ENOMEM" bugs
<AlexExtreme> it's interesting to note that i still get this assert failed if i revert all my changes
<rgl_> how you guys test upstart?  using UML?
<Keybuk> odd
<Keybuk> rgl_: "make check"
<rgl_> how do I run upstart without being proc #1?
<AlexExtreme> let's try the completely vanilla tree
<Keybuk> rgl_: you can't at the moment, without patching the code
<rgl_> Keybuk, so make check tests a running upstart?
<AlexExtreme> no, it tests the code
<Keybuk> rgl_: no, it's a suite of stuff that tests the code
<Keybuk> unit tests, basically
<rgl_> ah, no integration tests yet. ok.
<AlexExtreme> ok, i'm getting this bug with a vanilla tree
<AlexExtreme> Keybuk, want a backtrace?
<Keybuk> sure
<Keybuk> rgl_: define integration tests, in this case
<AlexExtreme> Keybuk, http://frugalware.org/paste/1480
<Keybuk> I've never been clear exactly where unit and integration testing are supposed to be different
<Keybuk> since pure unit testing supposes you can test just one function
<Keybuk> (which you never can)
<Keybuk> AlexExtreme: which upstart version?
<AlexExtreme> it's latest bzr
<AlexExtreme> 0.3.8 works fine
<Keybuk> ah, interesting
<Keybuk>         * init/event.c (event_new): Start off with NULL args and env, to
<Keybuk>         match job (saves a few bytes).
<Keybuk>         (event_match): Watch for NULL arguments!
<Keybuk>         * init/tests/test_event.c (test_new): Check for NULL not alloc'd
<Keybuk> heh
<rgl_> Keybuk, test the whole shebang as a blackbox.  like, have some jobs, kill a job, see if its restarted, and stff like that.  also, test the "problem" I've mention a days before: edit job, start a service that is a symlink, and see it does not work.
<Keybuk> AlexExtreme: if statement on job.c 1372 needs "&& job->cause->info.args" added
<Keybuk> rgl_: that's System Testing
<rgl_> Keybuk, isn't that the same as integration tests?
<rgl_> (though, its the first time I've heard of system testing hehe)
<Keybuk> well
<Keybuk> usually you're supposed to have
<Keybuk> Unit Testing -> Integration Testing -> System Testing
<Keybuk> unit supposes you can test each individual function
<Keybuk> integration is where you join functions together, and run scenarios through it
<AlexExtreme> ok, let's test that
<AlexExtreme> brb
<Keybuk> system is when you have the finished system, and apply checks to make sure it works
<Keybuk> the Upstart test suite is something of a combination of Unit (where possible) and Integration
<Keybuk> frequently tests are running much of the Upstart code
<Keybuk> e.g. we have tests to set up a socket, and all of the code to listen to it, then we poke commands into it and see how the states of jobs change, and what events are emitted, etc.
<rgl_> ah alright :D
<Keybuk> System Testing is when I install and reboot
<Keybuk> and if it fails, then I don't get to my desktop, so I can't upload the tarball <g>
<rgl_> hehe
<rgl_> though, using UML could facilitate that (but for sure you known it hehe)
<Keybuk> I don't know UML
<Keybuk> or do you mean User-Mode-Linux?
<AlexExtreme> I use VMware for that kinda thing :p
<rgl_> oh yes, sorry.  yes.  user-mode-linux
<AlexExtreme> mental note: it helps to apply the fix before testing it
<Keybuk> yeah, I use vmware for some stuff
<Keybuk> though mostly I just install it and see what happens
<AlexExtreme> Keybuk, what line was it on (the if block to change)?
<Keybuk> 1372
<Keybuk> is it bad to push incomplete code to main? :p
<AlexExtreme> as long as i don't bzr pull :p
<Keybuk> lol
<Keybuk> you wouldn't be able to, you're diverged now, no?
<AlexExtreme> true
<AlexExtreme> if it works this time i'll commit it to a new branch
<AlexExtreme> brb
<AlexExtreme> OMG
<AlexExtreme> It worked :P
<AlexExtreme> bbl
<AlexExtreme> https://code.launchpad.net/~alex-extreme2/upstart/profiles
<AlexExtreme> night
#upstart 2009-05-26
<ion_> keybuk: Oh, btw, i finally got around to subscribing to LWN a few days ago. :-)
<Keybuk> ion_: \o/
<Blanchy> if I would like to have fewer virtual terminals on my xubuntu 9.04 box, do I just need to remove (or rename??) /etc/event.d/ttyX files?
<sadmac2> Blanchy: remove
<Blanchy> is there a config file somewhere that I need to update when I add/remove ttyX files?
<Blanchy> similar to inittab
<sadmac2> Blanchy: nope
<Blanchy> thanks
<ion_> keybuk: Any interesting decisions at UDS so far? :-)
<Keybuk> ion_: nothing on upstart
<Keybuk> other than "will do more of it"
<Keybuk> the new branch has a name now though
<Keybuk> "upstart-nl"
<ion_> Ok
<ion_> Next... lactation?
<Keybuk> it's better than "ng" :p
<JamesB192> nederlands? j/k 'next locus' right?
<sadmac2> Nice and Luscious
<viric> Hello
<viric> I have some problems with an old upstart...
<viric> Anyone willing to help a poor user with an old version?
<viric> Soo I'm dealing with the halt sequence
#upstart 2009-05-28
<quitte> hi. so once again i might give upstart a try. is it finally in a state where it can work without any sysv style init?
<sadmac_> quitte: depends on what you do with it
<sadmac_> quitte: it doesn't propose a cohesive alternative to that though.
<quitte> sadmac_: if i don't install the upstart-compat-sysv package it will ignore all the rc* ?
<sadmac_> quitte: what distro is this?
<quitte> debian sid
<sadmac_> dunno what that package does on sid. I'm guessing the answer is yes though, but I'm not sure your system would boot afterward
<quitte> i'd really like to get rid of sysv init. but every time i checked upstart was did nothing but be compatible to sysv.  i would really have preferred if no time had been wasted on compatibility, but maybe i'm missing some good reason there.
<quitte> anyhow - i think it's the same on ubuntu - shouldn't dpkg continue working even if it can't find update-rc.d?
<sadmac_> its hard :) upstart has been redesigned at pretty much every major release. we haven't gotten it right yet
<quitte> i hope you finally got the compatibility complete enough to be able to not work on that anymore then
<sadmac_> next release will be right
<quitte> hahaha
<quitte> sorry, but i don't believe you
<quitte> but i sure hope so
<sadmac_> patches and thoughts welcome :)
<quitte> sadmac_: ok. I'll make a debian live system without sysv and then look into the current state. and i'll keep complaining. glad you guys are actually listening
<sadmac_> we try
<quitte> sadmac_: the thing about dpkg was a serious suggestion. make it easy to get rid of sysvinit as completely as possible. so that it becomes easy to work on the other parts. fixing the other packages to work with upstart, even when sysvinit is gone.
<quitte> if i have to keep sysv-rc around packages won't complain when they depend on update-rc.d
<sadmac_> quitte: dunno, I'm the fedora guy :) RH has ISVs to think of. They'll probably make us keep the sysv interfaces around for awhile
<quitte> isv? some vendors i guess
<sadmac_> got the v right :)
<sadmac_> independent software vendors
<quitte> hi again. i'm not sure if upstart actually started after the initramfs finished. doesn't it give any message at all?
<sadmac_> quitte: not if its working right
<quitte> sadmac_: ok. so not getting a message may or may not mean it's working right?
<sadmac_> quitte: you can add init=/sbin/init -v to the kernel arguments to get it to make noise
<quitte> i guess i need to add " to that?
<sadmac_> ...I didn't think so. maybe.
<quitte> found it despite the keyboard layout
<quitte> ok. upstart is working. would be nice if it gave some feedback without explicitly asking, though
<sadmac_> its left to the individual scripts to make noise, just like in sysv
<quitte> sysv says something like sysvinit version blablabla
<sadmac_> does it?
<quitte> yes
<sadmac_> hmm
<quitte> will upstart be part of the early root someday? i still haven't seen a way of waiting for the device containing the rootfs to appear and mounting it that seemed completely right.
<sadmac_> up to distributors
<sadmac_> Fedora says no. Ubuntu will do it because Scott is making those decisions there. Debian I don't know.
<quitte> debian didn't decide what to do with upstart it seems
<sadmac_> wait until its good for something like the rest of us :)
<quitte> now that's encouraging to hear. upstart still isn't good for anything?
<sadmac_> quitte: http://ftp.heanet.ie/mirrors/fosdem-video/2009/maintracks/upstart.xvid.avi
<sadmac_> best you have all the background
<quitte> i even considered switching to bsd once, so that i could play with launched
<sadmac_> is mainstream BSD doing that now? thought that was still an apple thing
<quitte> nah. i think it was a gsoc project or just a for fun project. it was dead the last time i checked
<quitte> great! the replacement initscripts are gone
<jort> Where can I find up-to-date docs for upstart? I found Scott Remnant's blog (which is GREAT! help), but any official docs?
<jort> sorry, I meant to add "for setting up jobs"
<jort> upstart.ubuntu seems to be 0.2 versions behind
 * jort looks around the room
<jort> anyone alive here?
 * jort pokes ubuntulog with a stick, to see if it's alive
 * jort examines the pool of blood under soren's lifeless corpse
<quitte> my impression is that you already found all the docs.
<jort> is that all there is? No up-to-date list of stanzas and their options?
<quitte> i don't know. but if you find one please tell me
<quitte> oh. also this is a channel, not a room
 * jort takes a ferry across the channel
 * quitte tries to make a joke about ferries in his room
 * jort starts reading the definitive documentation - the sourcecode
<jort> yay opensource!
<quitte> jort: please keep the wiki open and add your findings
<keesj> Hi
<ion_> LWN day :-)
<Keybuk> indeed
<keesj> subscribers?
<LLStarks> yo.
#upstart 2009-05-29
<quitte> I'm watching the fosdem talk right now. Now I'm wondering how usable upstart is from the early root.
<quitte> does it keep any files open or could I actually make it the very first process? so that it manages the early root all the module loading and such and once / is in place it is basically reconfigured?
<sadmac2> quitte: you should be able to. early root is one of Keybuk's goals
<quitte> keybuk is Scott Remnant?
<sadmac2> quitte: yes
#upstart 2010-05-31
<abadr> What's the right way to update the runlevels in this job file? http://wiki.nginx.org/Upstart
#upstart 2010-06-01
<akamaus> greetings
<akamaus> I'm looking for a way to periodically run a job (chef-client) on ubuntu-9.10
<akamaus> can upstart be used for that?
<akamaus> or I should run a service through cron job?
<ion> Use cron for now. Cron-like functionality is in TODO.
<akamaus> ion, thanks
<akamaus> I've setup a cron job to run a script containing "/usr/bin/service chef-client start &>/tmp/log" command. As a result I'm getting "exec: 129: start: not found". 
<akamaus> what might be the reason?
<akamaus> "/usr/bin/service chef-client start" runs ok from the root shell
<akamaus> does upstart need setting a specific environment?
<Keybuk> /sbin not in $PATH
<akamaus> Keybuk, thanks for suggestion. Actually, I messed the things up. One should run "start chef-client" not "service chef-client start"
<Keybuk> either works
<akamaus> Keybuk, only if you have old style script in /etc/init.d
<akamaus> I was too lazy to write one )
<mgoetze> i'm having trouble with an ubuntu 10.04 server "sometimes" not starting the tty1 .. tty6 jobs. has anyone heard of something like that?
<Keybuk> yes, there's an open bug
<Keybuk> but without any solid information about what causes it
<Keybuk> just wild theories
<mgoetze> ok is there anything i could do to help you find information? (would e.g. a login on such a system help?)
<mgoetze> also if you have the bug number i'd appreciate it
<Keybuk> I'm not actively investigating it at the moment
<mgoetze> some legacy init scripts seem to be affected as well, e.g. xinetd isn't running on this boot (on another boot xinetd was running but ttyX wasn't)
<Keybuk> that is consistent with the reported problem
#upstart 2010-06-02
<hazmat> besides --debug is there any other way to debug upstart when it hangs on boot?
<hazmat> i guess more to the point if i don't have file systems mounted before upstart hangs, can i just echo from an upstart script to the console
<JanC> hazmat: I think stdout gets redirected to /dev/null, but I suppose you can write to /dev/tty1 
<JanC> or use beeps or keyboard lights or whatever  ;)
<plautrba> JanC: with "console output" is stdout connected to /dev/console
<JanC> ah, right
<hazmat> JanC, thanks, but i gave up and just reinstalled....
<hazmat> although beeps FTW next time
<tstone> hi, i've just successfully got upstart support into ptxdist http://git.pengutronix.de/?p=ptxdist;a=summary but it needs some more polish so i have some questions...
<tstone> is there a reason that the dbus-daemon is started with the -fork option?
<tstone> i thought that upstart is much happier without that option, nevertheless does ubuntu lucid has this option.
<tstone> Also what is the most straight forward way to shutdown a system with upstart (i am not talking about runlevels here)?
<tstone> bye
#upstart 2010-06-03
<AnAnt> Hello, I have this in /etc/init/usb-blaster.conf: 
<AnAnt> script exec mount --bind /dev/bus /proc/bus ln -s /sys/kernel/debug/usb/devices /proc/bus/usb/devices
<AnAnt> end script
<AnAnt> erm, bad pasting
<AnAnt> exec & ln -s are in different lines
<AnAnt> now, when I do sudo start usb-blaster, only the mount is done, but not the ln -s, why is that ?
<AnAnt> nevermind, it worked
<sadmac> Keybuk: have you ever looked at the wayland source?
<Keybuk> sadmac: no, why?
<sadmac> Keybuk: He does some marshalling stuff a lot like what nih_dbus does, but with libffi instead of generated code
<halfline> sadmac: are you thinking of my branch of wayland? 
<halfline> i don't think that ever landed on krh's branch
<halfline> (that stuff is here http://cgit.freedesktop.org/~halfline/wayland/log/?h=dbus-attempt)
<sadmac> halfline: its not dbus itself. Some aspects of his implementation of the wayland internal protocol could be applied to nih_dbus to remove some of the generated code though.
<sadmac> oh yeah, and I should publish my wayland branch
<halfline> oh i see what you mean
<sadmac> halfline: actually libnih might be something I suggest to him to get rid of things like wl_hash and the linked list stuff.
<sadmac> halfline: right now I'm just plastering the source with documentation to get familiar
<halfline> gotta go catch a bus
<sadmac> do that :)
#upstart 2010-06-04
<jefimenko> where are the docs for upstart
<jefimenko> i have a daemon that runs on a typical /etc/init.d script
<jefimenko> to ensure better availability in case it does crash
<plautrba> jefimenko: man 5 init
<jefimenko> i'd like it to restart automatically
<jefimenko> plautrba: thanks, i've been playing around with things after reading those docs
<jefimenko> how can i source a config file
<jefimenko> like a /etc/default/servicename
<jefimenko> to set environment variables, etc.
<derosa> Hi, I have a service that must be run at shutdown/reboot. Before upstart I just used a init script in rc[06].  As my sript depends on dbus, the rc[06] solution is no longer valid, as dbus is stopped before my script runs. I tried a little config file that just runs the script when dbus is about to be stopped (start on stopping dbus), but it doesn't seem to be running at all. I appened the "--debug" flag to the kernel but it doesn't help to me. Any hints?
<derosa> Hi, I have a service that must be run at shutdown/reboot. Before upstart I just used a init script in rc[06].  As my sript depends on dbus, the rc[06] solution is no longer valid, as dbus is stopped before my script runs. I tried a little config file that just runs the script when dbus is about to be stopped (start on stopping dbus), but it doesn't seem to be running at all. I appened the "--debug" flag to the kernel but it doesn't help to me. Any hints?
<Keybuk> you mean "stop on stopping dbus" surely?
<derosa> My "service" is in fact just a command that doen's daemonize, so I thought it would be starting
<derosa> I thought "stop" would only stop something that has previously been started
<Keybuk> ah right
<Keybuk> then yes, use "start on"
<Keybuk> you'll also want to add "task" - that tells Upstart to block D-Bus from stopping until your command completes
<derosa> like this?
<derosa> description "nfssyncd final"
<derosa> start on stopping dbus 
<derosa> task
<derosa> exec nfssyncd-plymouth-final-sync
<Keybuk> right
<derosa> so, that should block until my cmd finiches, right?
<derosa> *finishes
<Keybuk> right
<derosa> it blocks when testing with "service dbus stop", but it doesn't when rebooting with "reboot" or using GDM applet
<Keybuk> there should be no difference between the two
<Keybuk> it may be that on reboot, other things that your task needs aren't around anymore
<derosa> I'll take a deeper look, thank you
<AnAnt> Hello, I have the following code in /etc/init/usb-blaster.conf: http://pastebin.com/SnPtBur2
<AnAnt> the problem is that sometimes the symlink is created, and sometimes not
<AnAnt> what could be the possible problem ?
<Keybuk> AnAnt: two "exec" lines
<Keybuk> only the first will be run
<Keybuk> between script...end script is just shell
<Keybuk> just drop both "exec"
<AnAnt> oh ! silly me
<AnAnt> thanks !
<mezcalero> Keybuk: btw, it's not a very grown-up move not to accept the comment i posted a week ago on your latest blog story, while accepting later ones...
<Keybuk> mezcalero: ?
<mezcalero> Lennart says:
<mezcalero> Your comment is awaiting moderation.
<mezcalero> May 31, 2010 at 5:35 pm
<Keybuk> hmm, I don't see anything in the pending queue
<Keybuk> let me check spam
<Keybuk> ah, found it
<Keybuk> it's not a very grown-up move to accuse someone of foul play without even asking them ;-)
 * Keybuk clears a couple of others stuck in spam too
<mezcalero> I still a kid inside ;-)
<mezcalero> add an "am" there
<magcius> uggh
<magcius> somehow I knew this would happen
<Keybuk> magcius: I knew it would to
<magcius> Keybuk: thoughts?
<Keybuk> the only thing we can do is fight
<magcius> Keybuk: the thing is that the article is half wrong
<Keybuk> the one about the aliens?
<magcius> Keybuk: nah, systemd
<magcius> oh wait
<magcius> yeah, that's the one too
<magcius> Keybuk: it says a lot about manual configuration of rules and stuff
<Keybuk> Lennart doesn't "get" Upstart
<magcius> Keybuk: but, as I understand it, that's all low-level stuff to make it easy for the system to parse at boot-time, right? There's a higher level
<magcius> language/compiler thing, right?
<magcius> Keybuk: sshhh, he's in this room.
<Keybuk> I know ;-)
<magcius> Keybuk: and I'm surprised at that.
<magcius> Keybuk: and we're now falling back to letting D-Bus starting things too
<Keybuk> D-Bus bus activation is an important part of the plan
<magcius> yep
<Keybuk> it does for Linux what Mach IPC does for Apple
<magcius> oh of course
<Keybuk> (though Apple seem to change their mind on a release by release basis about whether frameworks should use Mach IPC or UNIX sockets)
<magcius> Keybuk: so, from what I've heard, the rules files were to make it easy to parse, and were done by hand at first
<Keybuk> the current upstart config?  right
<magcius> Keybuk: wait, I thought there was a compiler that took a map and generated the rules
<Keybuk> I don't know what you mean by that
<magcius> Keybuk: for some reason, I thought there was a higher-level language, and a compiler that took conditions and optimized for them
<Keybuk> in Upstart?  no
<Keybuk> that'd be the wrong approach anyway
<magcius> Keybuk: like, on an SSD, the compiler would generate different rules than an 6100 RPM HDD
<magcius> Keybuk: so how do you handle system services?
<magcius> Keybuk: like Apache, etc. etc.
<Keybuk> I'm not sure I know what you're asking
<magcius> Keybuk: I must be thinking of another init system
<magcius> Keybuk: but if I have a service like httpd to start at boot time
<magcius> Keybuk: and I install the package, what rules get put into place to ensure that it does?
<Keybuk> a configuration file in /etc/init
<magcius> Keybuk: and is this a sh script that uses the Debian start-stop-daemon stuff?
<Keybuk> no
<magcius> ok, so, there's a /etc/init/httpd.rule or something
<Keybuk> right
<magcius> and it has "d-bus-started" as a dependency?
<Keybuk> Upstart isn't a dependency-based system
<Keybuk> (and why would a web server need D-Bus?! :p)
<magcius> Keybuk: does anything start before d-bus?
<Keybuk> lots of things
<magcius> ok
<Keybuk> some things start in parallel with D-Bus too
<mezcalero> magcius: for example if you plug in mod_dnssd into apache it would talk to avahi via dbus to register its services
<magcius> Keybuk: the systemd blog post mentioned things like the conditionals in Upstart. Do you know how systemd handles these things WITHOUT them?
<magcius> ah
<Keybuk> magcius: through launchd-like functionality
<Keybuk> one service makes an open() or connect() call to the other, which blocks
<magcius> mezcalero: are you talking about Upstart or systemd?
<mezcalero> magcius: that sentence was about neither
<Keybuk> the init daemon has prepared the socket in advance, so when it polls, starts the service and passes the socket along to it
<Keybuk> thus services are started by demand
<mezcalero> Keybuk: actually often enough it wouldn't even block, i.e. in the case of syslog
<Keybuk> Dave calls this pay-as-you-go
<mezcalero> Keybuk: it would just enqueue and go on
<Keybuk> mezcalero: indeed
<mezcalero> Keybuk: and no, services are not started on-demand, generally
<mezcalero> you can do that
<mezcalero> makes little sense though except in very few cases such as ssh or cups
<mezcalero> in the general case this is used to parallelize startup
<mezcalero> not to do things on-demand
<mezcalero> doing things on-demand simply delays things
<magcius> mezcalero: uh, why would you ever want to not start sshd on boot?
<Keybuk> mezcalero: I was referring to launchd there
<mezcalero> Keybuk: same for launchd
<Keybuk> I'm not sure how you're going to do things with systemd in Fedora
<magcius> exactly
<mezcalero> magcius: why would you? only every other month people to tend to log into their laptops with ssh
<Keybuk> magcius: it's not a matter of "not starting" ... sshd is "possible to start" on every boot
<magcius> mezcalero: so
<mezcalero> magcius: so it is sufficient to have the port open, so that people can connect and then start it on demand
<magcius> mezcalero: if I want to ssh into my home computer from a remote location
<Keybuk> magcius: then connecting to the open ssh port (opened by init) would result in sshd starting, and being passed your connection (actually the listening socket)
<Keybuk> the first connection would take longer due to the overhead of starting ssh
<magcius> Keybuk: yeah, gotcha
<mezcalero> magcius: from the clients' perspective little changes... the port is open with or without it
<magcius> Keybuk: I forgot that systemd held control of sockets
<mezcalero> but anyway, for stuff like dbus or syslog we don't do on-demand loading
<Keybuk> but then sshd would be running (until a quit time of its own choosing) so subsequent connections while running would be normal
<mezcalero> we start all that in parallel
<magcius> does systemd hold all sockets or just the standard <1024
<mezcalero> Keybuk: actually for sshd we chose to do it like macos, and do it in inetd-like per-connection mode
<mezcalero> Keybuk: but thats the only daemon where we do that
<Keybuk> mezcalero: makes sense, since then you can isolate each login
<magcius> about networkmanager, here's another thing I hate
<mezcalero> Keybuk: yepp, it's really nice actually because you get a seperate cgroup named after the connection parameters for each instance
<magcius> if you have no wireless, you can't connect to localhost
<mezcalero> Keybuk: o.e. the cgroup carries the clients ip addresses and such
<magcius> so you have to go in and uncheck "Enable Wireless"
<Keybuk> magcius: yes you can
<Keybuk> if you can't connect to localhost, you have a bigger problem
<magcius> Keybuk: last time I tried, it returned E_AGAIN
<magcius> Keybuk: I believe it was either gethostbyaddr or getaddrinfo that failed
<Keybuk> sounds like your box is misconfigured
<magcius> it was a fedora box :P
<Keybuk> magcius: I don't really know much about Fedora, sorry
<Keybuk> while recently there's been some movement towards making things like Fedora and Ubuntu more similar
<Keybuk> recent events mean it's more likely they're going to become very different again, possibly even incompatible
<mezcalero> Keybuk: hey, you are welcome to adopt systemd in ubuntu too, to work against that! ;-)
<Keybuk> mezcalero: not going to happen ;-)
<mezcalero> Keybuk: tss, just admit it, deep in your heart you want it too!
<Keybuk> mezcalero: it'd certainly make my life much easier
<Keybuk> but then we'd have to rename our distro to Ubuntu Lennarx
<mezcalero> i am a humble man, no need for that ;-)
<mezcalero> Keybuk: btw, have you seen how i love ubuntu and now am a facebook fan of ubuntu? if that's not proof that i don't hate ubunut i don't know what could be proof enough ;-)
 * Keybuk has one of the "I am Fedora" t-shirts
<Keybuk> can we make out now?
<mezcalero> nope, sorry, not into dudes. Also, I have more Suse shirts than Ubuntu shirts...
<mezcalero> but otoh i have more ubuntu pens than any other distro pens
<sadmac> mezcalero: ...so who does that leave you making out with?
<mezcalero> but in regards to usb keys mandriva i love the most
<mezcalero> sadmac: Suse is a german girl's name...
<sadmac> mezcalero: also wasn't it Novell that inserted that cute Linux girl into the I'm a Mac/I'm a PC commercials?
<Keybuk> oh, usb keys I'm totally for ubuntu
<Keybuk> we have boxes full of them at the office
<Keybuk> I never need to pay for portable storage again
#upstart 2010-06-05
<Mekzholan1> Hi, what's the correct upstart trigger to wait wait for (start on ...) if I need to wait till all networking interfaces are ready, including DHCP?
<oliv3r> Hi, i'm trying to build upstart from bzr and after autoreconf -i only ./configure --help works. I'm getting: upstart$ ./configure ./configure: line 2663: syntax error near unexpected token `[Copyright' ./configure: line 2663: `NIH_COPYRIGHT([Copyright Â© 2010 Canonical Ltd.])' every other time. What suggestions? (I suppose I could edit line 2663, but would it still be an issue next time i check out the trunk
<ion> You probably donât have libnih installed.
#upstart 2010-06-06
<oliv3r> ion: of course I have libnih installed, ./configure doesn't even get far enough to check libnih's headers or anything :)
<oliv3r> making a comment from 2663 continues fine with the installation btw
<mastamind> is dbus required for upstart?
#upstart 2011-06-01
<ewoerner> hi, what's the state of upstart socket activation? rejected/planned/implemented/released?
<MarcWeber> Is the logging feature gone? Is upstart -v the only way to debug state changes now?
#upstart 2011-06-02
<td123> hi
<td123> is upstart still going to be developed for future releases? or will ubuntu switch to something like systemd
<Keybuk> I believe that Ubuntu will be continuing to develop Upstart and use it for at least the forseeable future
#upstart 2011-06-03
<SpamapS> ewoerner: the version of upstart in Ubuntu 11.04 and later has socket activation. I believe there is an ongoing effort to bring it into the 1.x series as well.
<ewoerner> SpamapS: okay, thank you
 * Keybuk grins manically
<Keybuk> boot-complete 5.650s
<mbiebl> does that include bios and desktop session :-)
<Keybuk> yes
<Keybuk> both
<mbiebl> nice
<Keybuk> we time from power button, not from "after the boot loader has started the kernel"
<Keybuk> so I printed the CrOS boot sequence on a giant chart and hung it on the wall
<Keybuk> everyone keeps stopping and staring at it
<JanC> Keybuk: why are you using a BIOS ?  :P
<Keybuk> JanC: because it's hardware
<Keybuk> EFI is still BIOS
<JanC> well, I'd call it a firmware or something like that
<Keybuk> JanC: mbiebl called it bios, not me
<JanC> right, so this is some decent firmware that doesn't take 10-20 seconds   ;)
<JanC> or more
<Keybuk> right
<JanC> OTOH, Asus EEE managed to get a BIOS to finish in ~1 second by not doing any hardware detection
#upstart 2011-06-04
<wasabi1>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<wasabi1>     1 root      20   0 3263m 705m  296 R   80 77.8   1:45.73 init
<wasabi1> In case anybody was curious. :)
<wasabi1> 3868m
<wasabi1> 4009m
<wasabi1> System is going down shortly I suspect. ;)
<wasabi1> Hmm. Killed what was causing it... and it's stablized on the memory space... it's still spinning 100% CPu though
<wasabi1> mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
<wasabi1> Tjat
<wasabi1> That's all it's doing
<wasabi1> Can't even reboot. Fun.
<wasabi1> Oh it hit the maximum size of it's virt memory space.
<wasabi1> And there's not really much error handlnig for that, is there?
#upstart 2012-05-28
<djszapi> slangasek: why is that if I have two upstart jobs, like triggered for this event: start on stopped udevtrigger and none of those beings if one of the usb-serial port they depend on not available ?
<djszapi> I would kinda hope for, just one of them fails.
#upstart 2012-05-29
<jMCg> trafficserver start/killed, process 12099
<jMCg> Soo... uhm.. why not restart it then, if it's killed?
<jMCg> one would assume that trying to stop a killed job would be as easy as transitioning the status to stopped...
<tcr> Hi there! Is it possible (and if so, can you point me to the right direction), to make upstart grovels job files /etc/init/foo/*.conf as well?
<tylerflint> anybody know where I can find the source code for this project?
<tylerflint> since ubuntu has stubbornly stated it will not be using systemd, and I'm sick of doing crap like this: initctl start my-process-reload
<tylerflint> if I want to send a custom signal to my-process
<tylerflint> bazaar!? are you kidding me?
<tylerflint> haha, thanks everyone, you've been helpful
<axisys> is there a template I can use to convert this ugly redhat init script http://paste.ubuntu.com/1013541/ into a upstart?
<axisys> i went through most of the /etc/init/*.conf files and got some idea.. but before I dive in, I like to hear some suggestion
<axisys> i have written one upstart script for ssh tunnel with autossh.. so I have experience with upstart
<axisys> this devmon script is a while(1) loop perl script
<axisys> devmon: http://paste.ubuntu.com/1013590/
<axisys> essentially I just want this devmon perl script to start and run forever
<axisys> in solaris I have the init script lot simpler 
<axisys> http://paste.ubuntu.com/1013601/
<axisys> i probably should forget the redhat init script and start a upstart job (service) from scratch
<axisys> ok, I started with a very simple one.. but failing to start
<axisys> http://paste.ubuntu.com/1013609/
<axisys> doh!
<axisys> root@xymon { /etc/init }$ cp devmon devmon.conf
<axisys> root@xymon { /etc/init }$ start devmon 
<axisys> devmon start/running, process 877
<axisys> $ status devmon
<axisys> devmon stop/waiting
<axisys> what gives?
<axisys> http://paste.ubuntu.com/1013617/ <-- it does not survive
<axisys> I get this log
<axisys> http://paste.ubuntu.com/1013639/
<axisys> when start devmon
<axisys> but it does not survive
#upstart 2012-05-30
<erikh> hello friends, I have a simple question -- I'm managing a daemon that needs a somewhat complicated set of signals to do a graceful restart (unicorn, for what it's worth). How would I accomplish this in upstart?
<erikh> It doesn't seem I can specify a specific command for restart or reload events -- but maybe I'm missing something in the docs.
<axisys> I got it working.. there was a ``-f'' switch to run devmon in foreground.. that did the trick
<axisys> erikh: https://improvise.wordpress.com/2012/05/30/run-devmon-using-upstart-script/
<axisys> erikh: oops.. wrong window.. 
<erikh> np
<SpamapS> erikh: unfortunately you can't customize reload/restart in upstart yet
<SpamapS> erikh: one thing you can do is write a small daemon to translate HUP to whatever you want. restart is always stop/start in upstart..and I doubt that will change.
<SpamapS> erikh: probably best to just scold the unicorn devs for not handling HUP properly if they don't, and use a separate program to send the occasional SIGUSR1 or whatever is the "graceful" thing when you need that.
<mrvn> moin. Can anyone help me get upstart to talk? I have  --debug --verbose in the kernel command line but all I get is [   46.171081] init: Failed to create pty - disabling logging for job
<xnox> mrvn: what's the upstart version? recently it started to spew per job logs.
<mrvn> precise
<mrvn> whatever version that is
<mrvn> /var/log/upstart is empty
<mrvn> Under Lucid I get "init: Handling startup event" and tons of tons of other evnts. Those have disapeared too.
<xnox> jodh: ^^^^
<xnox> mrvn: based on the http://upstart.ubuntu.com/cookbook/#debugging can you try adding both '--verbose' and '--debug' and check the syslog?
 * xnox is guessing here.
<mrvn> syslog isn't running so /var/log/syslog isn't any help
<xnox> true.
<xnox> slangasek: might know. I haven't done upstart debugging much yet. I've debugged individual jobs, but that's past boot. 
<mrvn> I've used --debug / --verbose under lucid but with precise upstart simply stoped outputing anything.
<xnox> There is a bug that /var/log/upstart is missing on cloud images. https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/990102
<xnox> but I don't see a bug about what you describe.
<mrvn> I've got the dir, it just is empty.
<jodh> mrvn: are you running upstart on a system with no initramfs?
<jodh> mrvn: the error you get occurs when upstart fails to create a pty, possibly due to /dev/pts not being mounted.
<slangasek> that was about to be my question :)
<jodh> mrvn: for now, either arrange to have an initramfs or boot with '--no-log'. If /dev/pts gets mounted at a later part of the boot (by mountall), those pesky messages will disappear (and you'll see logs in /var/log/upstart/ potentially).
<jodh> mrvn: the fix for this issue is for upstart to mount /dev and /dev/pts itself.
<mrvn> jodh: /dev/pts is mounted, the messages persist
<jodh> mrvn: how many messages do you get? you should get 1 / job that is failing to be logged.
<mrvn> sounds about right
<jodh> mrvn: so does the system boot? have you tried booting with '--no-log'?
<mrvn> --no-log hides the problem. But I would rather have it fixed.
<jodh> well, we need to understand what is triggering it for you as the only scenario I am aware of is where there is no initramfs.
<mrvn> posix_openpt() is triggering it. It sets errno=2 (No such file or directory).
<mrvn> crw-rw-rw- 1 root tty    5, 2 May 30 16:43 ptmx
<mrvn> devpts on /dev/pts type devpts (rw,gid=5,mode=0620)
<mrvn> The question is why? What else does it try to open?
<erikh> SpamapS: thanks for your advice.
<mrvn> And it still doesn't help in getting upstart debug messages back to the console. They now seem to silently disapear in dmesg and later in syslog.
<jodh> mrvn: is this a standard Ubuntu Precise x86/amd64 system?
<mrvn> not quite
<mrvn> it boots via nfs-root, which requires some changes
<jodh> mrvn: changes to what?
<mrvn> e.g. mountall doesn't work so I have to mount stuff myself.
<jodh> mrvn: I think you should raise a bug on this with full details. Ultimately, if posix_openpt() fails, there isn't much Upstart can do aside from disabling job logging for the job in question. And thats exactly what it does.
<mrvn> The error should come for any job with "console output" in it right?
<jodh> mrvn: actually, no - it'll be for every job that either doesn't specify "console" or does specify "console log" explicitly. See http://upstart.ubuntu.com/cookbook/#console-log, http://upstart.ubuntu.com/cookbook/#command-line-options, http://ifdeflinux.blogspot.co.uk/2012/05/job-logging-in-upstart-big-upstart.html
<mrvn> Ok, one more thing to the PTY problem: If I "telinit u" to restart ubuntu then the problem goes away.
<mrvn> Why isn't it enough to mount /dev?
<SpamapS> mrvn: telinit u loses a lot of state in upstart
<SpamapS> mrvn: not advisable on a running system
<kevmo> Hi all, I created an upstart conf file in /etc/init/ and want to modify it, but the changes revert back to the original after a reboot.  Also, if I delete the file, it comes back after a reboot.  What am I missing here?
<mrvn> kevmo: some form of netboot or initramfs based system
<kevmo> Not doing a netboot.   not sure what initramfs us
<kevmo> is
<qkslvrwolf> Is there a way to start an upstart job on desktop-start and connect to the display?
<qkslvrwolf> I'm attempting to start selenium grid no virtual machines.  I'd like to do this via upstart, but I need a way to allow the grid process access to the display.
<JanC> qkslvrwolf: you would have to start it from inside the X session so that you know what display to connect to?
<qkslvrwolf> JanC: I got it working, just not as cleanly as I'd like
<qkslvrwolf> I actually used lubuntu autostart
<JanC> hm, I wonder if the display manager passes DISPLAY=foo with the desktop-session-start event...
<qkslvrwolf> that's good thought
<qkslvrwolf> that would be nice
<qkslvrwolf> although it would also need to pass the magic cookie or whatever
<qkslvrwolf> unless I ran this as a user upstart job
<qkslvrwolf> which I could also look into
<qkslvrwolf> I would prefer to do it with upstart because then it would (theoreticlly) work for any version of ubuntu.
<JanC> you could emit your own event on session startup and pass all variables you need
<soren> qkslvrwolf: Do you actually need a real X server?
<soren> qkslvrwolf: Why not just use xvfb?
<soren> qkslvrwolf: Or, if you ever need to connect to it, use xpra.
#upstart 2012-05-31
<twb> I'm not sure if this is an ubuntu or an upstart question.
<twb> I have a 12.04 chroot environment that I am installing packages into, as part of building a live image.  When I install a daemon package (e.g. cron), it tries to start itself by talking to upstart.  This fails (because it's chrooted).
<twb> In sysvinit I would simply write a policy-rc.d that said "exit 101", which tells invoke-rc.d not to ever start such daemons.
<twb> How can I get the same effect for upstartized daemons?
<twb> In the past, it seems the least-worst approach was to diver initctl and put /bin/true in its place during the build.
<twb> http://bugs.debian.org/571054
<twb> OK, never mind.  I just tried writing a policy-rc.d and it seems that approach works now.  Yay!
<tcr> Is seems like "start on" does not actually specify a prerequisite for a job to be started, but a pattern of events that if fullfilled will make the job be started automatically. Is that correct?
<jodh> tcr: yes - see http://upstart.ubuntu.com/cookbook/#start-on and http://upstart.ubuntu.com/cookbook/#upstart-s-design-why-it-is-revolutionary
<tcr> I have a job definition which contains "start on", "stop on" and a "pre-start script" - that's it. I'd have thought that creates a forever-running job, but it seems not to (status $job reports "Unknown job")
<tcr> I want to create a job that perform some action, and if the action was successful, remains in the started state (so an attempt to start it again will be a NOP)
<JanC> unknown job means exactly that: there is no job with that name
<JanC> so either your job definition contains syntax errors, or you misspelled its name...
<tcr> other jobs were started that depend on it. Is a .conf file checked for syntax errors before or while it is being processed?
<xnox> tcr: .conf jobs are loaded when upstart starts and are not reloaded.
<tcr> sorry how does that answer the question? :)
<xnox> sorry, as far as I know syntax is checked on loading, but I'm not sure with respect to buggy shell snippets and what not
<SpamapS> tcr: if you have Ubuntu 11.04 or later you can use init-checkconf /ec/init/foo.conf
<SpamapS> xnox: upstart jobs are reloaded if they change, and the filesystem supports inotify
<xnox> SpamapS: ok. I had wrong impression. still learning upstart.
#upstart 2012-06-01
<tcr> Let's say I'm polling for the existence of a file in a pre-start script. When I try to stop the job when it's polling, it changes to stop/pre-start. I want it to stop doing the polling if it receives a stop event.
<jodh> tcr: hmm - that doesn't sound right. Can you raise a bug with some more details here: https://bugs.launchpad.net/upstart/+filebug. To work around the issue, you could put  your poll code into the main "script" section. Polling for files isn't ideal though - what is creating that file?
<tcr> A configuration process. The file should always be there except before first time configuration
<jodh> tcr: why the poll then? wouldn't it make more sense to have the pre-start check for the config file and if not found, call "stop" to ensure the service does not start?
<tcr> I want the service to start once the file is there
<JanC> probably best use something like inotify in a helper job then
#upstart 2012-06-02
<sage1> are there best practices for making a task that starts/stops multiple daemon instances?  i see lots of examples how to make a foo-all.conf that starts several instances, but nothing about making 'stop foo-all' work...
#upstart 2013-05-27
<blackdog> g'day all - not entirely sure if this is the right place to ask, but here goes. I have a service running under upstart. I need to change some settings in /etc/security/limits.conf for a particular user. They work fine if i log in with a login shell, but it seems that upstart just runs setuid. Is there an approved way of getting PAM to run those for services?
<SpamapS> blackdog: PAM is not for services. You can set those limits in the upstart job.
<SpamapS> blackdog: see 'man 5 init' , the 'limit' stanza lets you set any of those limits but without the baggage of PAM.
<blackdog> SpamapS: righto, thanks.
#upstart 2013-05-28
<helmut> hi. I based on discussion on debian-devel (https://lists.debian.org/debian-devel/2013/05/msg01453.html) I would like to ask you, supporting some of the interfaces of systemd in upstart would make sense.
<helmut> specifically upstart and systemd use different mechanisms for socket activation and daemon completion signalling. at least the former needs explicit support from the daemon.
<helmut> consolidating these interfaces would remove a lot of work (on the side of daemon implementations), and I guess that even though systemd came late to the party, upstart could adopting some of systemd's interfaces.
<helmut> not because systemd's interfaces are better, but because consolidated interfaces are a benefit in themselves (and systemd devs are notoriously hard to work with when it comes to interoperability)
<Neozonz|Disc> i've setup a script to launch a daemon
<Neozonz|Disc> but after start daemonname
<Neozonz|Disc> it just hangs
<SpamapS> Neozonz|Disc: hard to respond without seeing the job file.
#upstart 2013-05-29
<jadams> hey, so I have a problem where a command I start in a subshell in an upstart script won't die on service stop.  Some discussion around the problem is here: https://github.com/ddollar/foreman/issues/97
<jadams> essentially, the command I ran after the && in my "su - foo -c "a && b" won't stop
<jadams> in that example, stopping the service would kill a but not b
<xnox> jadams: correct you should have a second upstart job to run b which is "started on stopped a" (sequential)
<xnox> jadams: also see "setuid" and "setgid" stanzas which may possibly replace "su" for you.
 * SpamapS wishes we could have setuid per-executable
<SpamapS> so that pre-start can be root
<jadams> xnox: yeah, so it ultimately seems to come down to this problem: https://gist.github.com/knewter/5671928
<jadams> xnox: so ultimately, I'm dealing with a ruby app on a deploy, and so my foo actually modifies the current environment (it's an rvm script runner), so I actually just want to run it before running the second command
#upstart 2013-05-31
<diimdeep> hello, ii have trouble with shutting down service 
<diimdeep> here is http://i.imgur.com/CEIscjv.png
<diimdeep> config of service
<diimdeep> starting is fine, when trying to stop it says that Unknown instance
<jodh> diimdeep: firstly, there is no "shutdown" event at the moment. We have discussed adding "event aliases" in the past though (https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033402.html). For the list of available events, see "man upstart-events". For shutdown you probably want "stop on runlevel [016]".
<jodh> diimdeep: you will probably find the reason you cannot stop the job is because lmgrd forks so although the lmgrd daemon starts, Upstart cannot know its final pid and hence cannot stop it. See http://upstart.ubuntu.com/cookbook/#expect
<jodh> diimdeep: and http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count
<diimdeep> jodh, thank you
<jodh> diimdeep: also, if you decide you need to use "respawn", please read the warning at the top of this section: http://upstart.ubuntu.com/cookbook/#respawn
<diimdeep> jodh, thanks. do i need to use  expect daemon ?
<jodh> diimdeep: I don't use lmgrd, so you will need to "establish the fork count" (see link above). If lmgrd forks once, specify "expect fork". If it forks twice, specify "expect daemon". All the information you should need is in the links above.
<diimdeep> thanks, do't know about forking.. need to learn that
<diimdeep> jodh, what it process forks 4 times >
<diimdeep> ?
<diimdeep> *if
<jodh> diimdeep: https://wiki.xkyle.com/Upstart_Script_For_lmgrd_%28FlexLM%29
<hkeide> I want to run a pre-start script as root, but then run the exec itself as an unprivileged user. Is there any way to do this except running the unprivileged job with "su -c command user"?
<jodh> hkeide: yes - put the pre-start logic into a separate job such that it will run as root. You can then specify setuid+setgid in the "main" job and have that main job "start on stopped pre-start-job RESULT=ok". Or, you could have the pre-start-job explicitly start the main job if appropriate.
<hkeide> hmm ok, I guess I'll go with the single-file approach, I want it to be self contained if at all possible
<hkeide> jodh: but thanks anyway
<soheilpro> in order to run node.js as a service which approach is better? executing node or using start-stop-daemon?
<stgraber> xnox: so that's kubuntu, lubuntu and xubuntu updated for user session support. Looking at ubuntu gnome and ubuntu studio now.
<stgraber> xnox: the current plan is to switch all of those on by default in 2 weeks or so
<SpamapS> user sessions are neato, but is anybody going to fix "ptrace sucks" ? :-/
#upstart 2013-06-01
<xnox> SpamapS: we'd like to use cgroups.... but it's well haven't been done yet.
#upstart 2014-05-26
<joelmo> how do I enable users config files in ~/.config/upstart when logging in using another window manager, I log in to i3 from LightDM
<Speed> hi, so I'm having a weird issue with upstart on ubuntu 12.04, ran inside a vagrant vm: none of my custom init scripts (that worked half a year ago) seem to work
<Speed> everything seems to silently fail with no log output whatsoever
<Speed> so I created a test script: http://pastie.org/private/lt5u84qz6p31ydcuivda
<Speed> put it under /etc/init/test.conf
<Speed> sudo start test
<Speed> nothing. there's no file created in /tmp, there's no log output in /var/log/upstart/test.log
<Speed> any ideas?
<Speed> correction, I am using 13.04
#upstart 2014-05-27
<bsdbandit> good morning im trying to convert my startup script over to upstart not sure is this is right just wanted to see if someone can check out this script that i wrote and give me some poiters http://pastebin.com/T9Lv0C9Y
<bsdbandit> good morning im trying to convert my startup script over to upstart not sure is this is right just wanted to see if someone can check out this script that i wrote and give me some poiters http://pastebin.com/T9Lv0C9Y
<bsdbandit> ?
#upstart 2014-05-28
<nicksloan> I wrote an upstart job that runs a rails app with unicorn. I have setuid deploy in my job configuration. I'm getting an error that '~' cannot be expanded. upstart 1.12. any ideas?
<soren> nicksloan: Check your environment. Expanding ~ requires $HOME or $USER to be set (typically). Upstart job environments are (intentionally) very clean.
<nicksloan> soren: thanks for the response. I figured that out eventually. Had to manually set $HOME. Probably not the best idea, but it worked
<soren> nicksloan: Nah, a system level daemon like that should probably not rely on $HOME, but you do what you have to do, right? :)
<nicksloan> soren: exactly.
#upstart 2014-05-29
<daveb__> Can I add custom options to grub that set a variable or something to that affect so that I can access that variable from upstart or a loginshell?
<daveb__> What I ended up doing was just adding a keyword to the kernel command line, and then accessing /proc/cmdline from a login shell
#upstart 2014-05-30
<q5p4k0> can anyone help explain why daemon (from /etc/init.d/functions) is not displaying OK or FAILED properly?
#upstart 2014-06-01
<orbisvicis> i've installed ubuntu to usb hdd, which isn't properly spun-down on shutdown. 
<orbisvicis> so I want to run "scsi-spin -d /dev/sda" during shutdown, after unmount
#upstart 2015-05-26
<Grynn> what's the stanza for start when (another job finishes with success?)
<Grynn> if there's such a thing
#upstart 2015-05-28
<schnuffle> hello, I'm setting up a java based upstart service which spawns a sub process on each job it gets. we need to capture the stdout from that process to a file. When I launch the service manually or wirh a init.d script there's no problem to get stdout. Using upstart the capture of stout fails. Has anybody a hint what could be the problem. CentOS6 uses upstart 0.65
<schnuffle> Okay, problem solved, it was the difference of umask between the two, in upstart the process inherits 022 from root, which leads to the problem
#upstart 2015-05-29
<xSmurf> hello, is there a way to make two jobs mutually exclusive? that is if one is started the other one should not try to launch. and/or to check for a running program before respawn
#upstart 2016-05-30
<inersha> When I run `sudo service jobname start`, I get the reply "jobname start/running, process 16583", but it immediately stops.
<inersha> How can I find out what the problem is?
<inersha> I've been doing the same thing on my local computer with no problems, but the service keeps stopping on my server.
<chras> inara: anything in logs ? 
<chras> oop, wrong person, that person left
<chras> sorry!
#upstart 2016-06-02
<flaf> Hi @all. I have a question: https://gist.github.com/flaf/cb3656e3de8b9d3ac08b20bb312c1fba <= can you confirm to me that it's a bug of upstart?
#upstart 2016-06-03
<flaf> Hi @all. In fact, this is not a bug of upstart above but a bug of "mountall" used by upstart to mount filesystems in fstab. I have made a bug report here: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1588594
<frew> if I wanted to set an envvar for all services (as opposed to having to put env FOO=1 in each one) is there a way to do that?
<chras> not without implementing it yourself in some form, like doing an environment file that you source, or passing or when you run initctl start $job KEY=VAL
<frew> ok.
<frew> oh well.
<frew> would be nice
<chras> but there isnt like a global default environment thing
<frew> right.
<chras> that aim aware of
<AnrDaemon> frew: Can you tell us, why you want to do that?
<frew> sure
<frew> we want our services use /mnt/tmp instead of /tmp
<frew> setting TMPDIR to that is sufficient
<AnrDaemon> Fail.
<frew> but doing that in every unit sucks
<AnrDaemon> Mount /tmp where you want it, problem solved.
<chras> well
<frew> have you done this before AnrDaemon?
<AnrDaemon> http://refspecs.linuxfoundation.org/fhs.shtml
<frew> because some early boot stuff uses tmp
<AnrDaemon> Nothing critical, to my knowledge.
<frew> so you haven't done it then.
<frew> "Fail."
<frew> :P
<AnrDaemon> And if it uses /tmp before / is mounted, well, what can i say?
<chras> frew: is it your desire to have your TMPDIR be somewhere other then temp, for everything?
<frew> chras: well, of course it gets worse
<chras> like i would be cautious about doing that
<frew> chras: I was wanting it to be somemthing some units would opt out of
<chras> i think its a little safer / cleaner to just set your TMPDIR per application/service
<frew> so like, ssh I'd manually set TMPDIR back to /tmp
<frew> yeah
<frew> for sure safer
<AnrDaemon> Overcomplication. Maintenance headache.
<frew> a non-trivial amount of things need tmp to be on the same partition as root
<chras> like simply from the stance of creating unexpected behaviour
<frew> so those would need it to be the regular /tmp
<frew> chras: sure.
<chras> one option you could do is
<chras> you could have one event which spawns the other ones with initctl start ${otherjob} TMPDIR=${new_temp_dir}
<chras> should work with emit too
<frew> yeah I considered exactly that
<AnrDaemon> frew: What I see from here is that you're solving problem with wrong tools. If you want isolation, get LXC or Docker, or what else suits your needs.
<frew> sounds a little rube goldberg-y for this kind of thing
<chras> iirc initctl emit start_all_my_junk TMPDIR=${tmpdir}
<chras> should work 
<frew> right
<frew> yeah maybe
<chras> adn then all your other things can just start on start_all_my_junk
<frew> right.
<frew> chras: thanks; I'll look into doing that
<chras> personally, i just source /etc/event.functions to get my common functions/environment/etc
<frew> that's a good idea.
<frew> I should just make a thing all of our stuff uses
<chras> and my source file also includes in /etc/event.functions.d/*
<chras> so if you need to add in extra variables in a new package/service/whatever
<AnrDaemon> Except sourcing anything is not an option. You can't set-env if a job runs with setuid.
<chras> it can be added without modifying existing things
<frew> AnrDaemon: ...what are you talking about?
<chras> AnrDaemon: why not?
<AnrDaemon> Why not what? Why it doesn't work? I don't know.
<frew> ugh
<AnrDaemon> + initctl set-env USER=php-fpm
<AnrDaemon> initctl: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
<frew> AnrDaemon: he means source in the script.
<AnrDaemon> Sourcing is not an option. You have to set these variables to the job to exec your service.
<frew> whatever dude
<AnrDaemon> Else upstart will not track the right PID, or get stuck if you try and use "expect fork/daemon".
<frew> script\n. $to_source\nexec foo\nend script # <-- look; it works ma
<chras> AnrDaemon: i only ever do stuff with foreground processes, so thats not a concern for me
<frew> same.
<frew> forking is for chumps
<AnrDaemon> That' swhat I've tried to do last week.
<AnrDaemon> Spawning per-user FCGI daemons without using master running as root.
<chras> but yes, it would be nice if set-env worked for all of upstart, and not just user/session jobs
<AnrDaemon> exec /usr/sbin/php5-fpm --fpm-config="/etc/user-fcgi/$USER.conf" --pid="/run/$USER/php-fpm.pid" $INIFILE -d open_basedir="$HOME" --nodaemonize
<frew> chras: I think if I *really* wanted to make that work, I could tell the kernel to add en env var
<frew> chras: but I'm not gonna reboot ;)
<chras> right
<AnrDaemon> And every variable I need to set in instance pre-start.
<frew> though upstart might clear the env, which is reasonable
<AnrDaemon> It does.
<chras> variables set in pre-start wont appear in other contexes
<chras> only in pre-stat
<AnrDaemon> chras: man initctl | grep -A7 set-env
<frew> AnrDaemon: if you want to get env vars, you have to use script like I was saying.
<frew> (from a file)
<chras> AnrDaemon: yes, if you read the docs it says specificly, that set-env is ONLY for session / user jobs
<AnrDaemon> And upstart will track wrong PID.
<chras> NOT jobs managed by upstart pid=1
<AnrDaemon> Nice suggestion, dude, I TOLD YOU that's not an option.
<frew> gracious
<chras> AnrDaemon: with all honesty, you need to chill out on the attitude a little
<AnrDaemon> set-env works if job is run as root.
<AnrDaemon> (Which counts as user job, from upstart POV)
<chras> well i'll test this
<AnrDaemon> I love upstart. I really do. But these caveats is what driving the bar down.
<frew> chras: btw not sure if you are the right person to mention this to, but the link to the upstart revision control here (http://upstart.ubuntu.com/development.html) is broken.
<AnrDaemon> It was broken for years since announcement that Debin switched to systemd.
<AnrDaemon> Debian anyway.
<frew> I think it just needs to be ~upstart-devel instead of ~scott
<chras> frew: im just a user
<chras> trying to help other people out
<frew> gotcha
<chras> so they dont have to drown in systemd
<frew> hah
<AnrDaemon> Speaking of which. May be it isn't new for you, but I just recently found https://wiki.ubuntu.com/SystemdForUpstartUsers
<chras> [t] 17:15:22 root@t-nfs04a:/etc/event.d# initctl set-env TEST2=chris
<chras> initctl: Not permissible to modify PID 1 job environment
<AnrDaemon> Of course not.
<AnrDaemon> But try it in a single job.
<chras> that means set-env isnt really an option
<AnrDaemon> You can change the JOB's environment.
<AnrDaemon> In pre-start.
<AnrDaemon> And then straightforward exec using these altered variables.
<AnrDaemon> Instead of bugus scripting.
<chras> thats just as much bogus scription
<AnrDaemon> But then upstart will track the PID of the service itself.
<chras> hes looking for an alternative to doing an env=SOMETHING , and you're suggesting doing an env=SOMETHING in essense
<AnrDaemon> With no guesswork.
<AnrDaemon> As I said, he's doing the right thing in a wrong way.
<AnrDaemon> If he want isolation, he should use isolation tools.
<frew> AnrDaemon: I don't think I ever said I wanted isolation.
<AnrDaemon> No, you didn't. But your description clearly pointed to your intentions.
<frew> eh, strain at the tea leaves if you want.
<frew> /mnt/tmp is a sep physical disk
<AnrDaemon> Even better.
<chras> well, arguably tmpspace by design is supposed to be volatile
<frew> yeah, on my laptop I set TMPDIR to /run/shm
<AnrDaemon> I'm running a container that mounting 3 BTRFS subvols directly, that aren't mounted at all on host.
<frew> but ofc if somethign wrote a 30G file there things would go poorly.
<chras> right
<AnrDaemon> Applications that write 30Gb temps usually have configuration for scratch space.
<chras> yeah, that type of thing, especially if it needs to be persistant, should be outside of system tmp most likely
<frew> chras: yeah I'm thinking of giant crash file type things
<django000> Hello everyone, I am trying to write my first configuration file, but I can't figure out what runlevel means?
<django000> Could anyone help me please?
<django000> Thanks
<AnrDaemon> Nothing, you shouldn't use runlevels.
<django000> AnrDaemon: most of the examples I find online have runlevels, I am just curious about its meaning, thanks for helping out
<AnrDaemon> It's an anciet initd concept.
<AnrDaemon> You can easily google the full documentation. But you SHOULD NOT use runlevels. Unless you actually know what you are doing.
<AnrDaemon> If it is a sinmple system service, "start on filesystem" should be enough. If it uses network, "start on filesystem and net-device-up IFACE != lo" would suffice majority of cases.
<AnrDaemon> Details are in the channel title's link.
<django000> I just want to run a python script on the background, It should be running all the time. I did some research and found out about upstart
<AnrDaemon> Oh, and if your service uses forking to drop privileges, you better teach it to forget this bullshit and use setuid/setgid in the script itself instead.
<django000> so yeah, I have just basic understanding for now
<django000> reading the manual :)
<AnrDaemon> Then it's rather straightforward.
<AnrDaemon> Literally, no more than 5 lines of code to start a service.
<AnrDaemon> 2 of them being informational :D
<django000> :), uff I wish I know the other 3 lines to complete my 5
<django000> But I am still curious, sorry
<django000> so I think I will continue with my search
<AnrDaemon> django000: Just a moment.
<AnrDaemon> django000: http://pastebin.com/uqSdZZME
<AnrDaemon> However, if you want it to run as non-root, that's going to be a little more work on the details.
