[10:15] <Benkinooby> hi, i don't have a /etc/init.conf file (the upstart man page (== init man page) lists it under FILES). what is it good for? i have all /etc/init/*.conf files which seem to save the start/stop instructions for each service.
[10:20] <Benkinooby> hello?
[14:49] <phretor> hi, this script http://paste.pocoo.org/show/276963/ fires an error due to exec: "Sorry, root is not allowed to run "/usr/bin/Xvfb :99 as foo:bar on host". Any help?
[16:09] <phretor> anybody?
[16:19] <Keybuk> yo
[16:22] <phretor> hey Keybuk
[16:22] <Keybuk> how goes it?
[16:23] <phretor> Keybuk: ah, not bad. Could be better, though
[16:24] <phretor> Keybuk: for instance, I could have my Upstart script working properly :) *that** would be "going good"
[16:24] <Keybuk> :-)
[16:25] <phretor> Keybuk: http://paste.pocoo.org/show/276963/ in case you can spare a few minutes
[16:25] <Keybuk> there are many many problems with that script
[16:26] <phretor> Keybuk: I bet, it's my first one.
[16:26] <Keybuk> "start on startup" is before anything like filesystems are checked or mounted, you better not need to use the disk
[16:26] <Keybuk> you don't specify an Upstart version, in the current the second start on will replace the first
[16:26] <Keybuk> stop on "[016]" doesn't mean anything
[16:27] <Keybuk> there is no "pid file" stanza
[16:27] <Keybuk> everything between script...end script is a shell script
[16:27] <Keybuk> calling exec on the first line means the second won't ever run
[16:27] <Keybuk> there is no "emit" command - did you mean "initctl emit" ?
[16:27] <Keybuk> there's no need to emit an event when a job is running - Upstart takes care of that for you
[16:27] <Keybuk> (on started YOUR_JOB_NAME)
[16:28] <Keybuk> oh, and does Xvfb _really_ fork?!
[16:28] <phretor> Keybuk: it doesn't fork, but from a tutorial I've understood that expect fork has to do with creating a daemon. I felt it wasn't a good idea, but I decided to give it a try.
[16:29] <phretor> Keybuk: (actually, there is a pid file stanza)
[16:29] <Keybuk> there isn't :p
[16:29] <phretor> mh, line 10?
[16:30] <Keybuk> Upstart doesn't recognise it
[16:30] <Keybuk> it was an early idea for doing fork following
[16:30] <Keybuk> but never implemented
[16:30] <phretor> Keybuk: ah, you mean that I cannot use it.
[16:30] <Keybuk> right
[16:30] <Keybuk> at best it'll ignore it
[16:30] <Keybuk> at worst it'll error
[16:30] <Keybuk> I'm pretty sure it'll just error
[16:31] <phretor> Keybuk: this is slightly better, not final, though. http://paste.pocoo.org/show/277005/
[16:31] <phretor> (it doesn't complain on 10.04 server)
[16:31] <Keybuk> right, that's better
[16:32] <Keybuk> stop on [016] should probably be stop on runlevel [016] I'm guessing
[16:32] <phretor> still I'm not sure about sudo - I just need to run Xvfb as worker:worker and keep it running in case it fails (respawn)
[16:32] <Keybuk> since it's clearly a user thing, maybe you mean:
[16:32] <Keybuk>   start on runlevel [2345]
[16:32] <Keybuk>   stop on runlevel [!2345]
[16:32] <Keybuk> ?
[16:32] <Keybuk> yeah, you need sudo or su there
[16:32] <Keybuk> or start-stop-daemon which has insane syntax
[16:32] <phretor> Keybuk: w/o exec?
[16:33] <Keybuk> exec doesn't make much difference there, it'll save a pid though
[16:33] <phretor> I was told not to mix Upstart with start-stop-daemon
[16:35] <phretor> and damn it "Sorry, user worker is not allowed to execute '/usr/bin/Xvfb :99' as worker:worker on hostname"
[16:35] <Keybuk> that's a sudoers issue
[16:35] <phretor> and it clearly won't start
[16:36] <phretor> well, I have "root    ALL=(ALL) ALL"
[16:37] <Keybuk> might be an X issue of course
[16:37] <Keybuk> but that's not an upstart problem :)
[16:39] <phretor> Keybuk: let me try with another command
[16:39] <phretor> Keybuk: "Sorry, user worker is not allowed to execute '/usr/bin/lsof' as worker:worker on hostname"
[16:39] <Keybuk> then it's sudoers
[16:41] <phretor> Keybuk: dear lord :)
[16:41] <Keybuk> maybe it's deciding based on the arguments ?
[16:41] <Keybuk> ie "as worker execute foo" so worker needs permission to execute foo?
[16:42] <phretor> -rwxr-xr-x 1 root root 1688032 2010-07-21 08:53 /usr/bin/Xvfb
[16:42] <phretor> and worker has ALL=(ALL) ALL
[16:43] <Keybuk> no idea
[16:43] <Keybuk> I'm not a sudo expert
[16:45] <phretor> Keybuk: ok, I will look at that. So, Upstart doesn't expose any feature for lowering the privileges, right?
[16:45] <Keybuk> right
[17:19] <phretor> Keybuk: I need to spawn the same server (i.e., same executable) on different ports and have Upstart to respawn each instance if it dies. Do I have to create multiple scripts (one for each port) or what?
[17:19] <Keybuk> no, you can use INSTANCE
[17:19] <Keybuk> though you would obviously need a master script to start each one
[17:19] <Keybuk> e.g. you could add
[17:19] <Keybuk>   instance $DISPLAY
[17:19] <Keybuk> and then
[17:19] <Keybuk> start YOUR_JOB DISPLAY=:100.0
[17:19] <Keybuk> start YOUR_JOB DISPLAY=:101.0
[17:19] <Keybuk> etc.
[17:20] <Keybuk> and you'll get two copies with different $DISPLAY variables
[17:20] <Keybuk> they'll show up in lists as YOUR_JOB (:100.0) ...
[17:21] <phretor> Keybuk: and Upstart will take care of each of them individually?
[17:21] <Keybuk> yes
[17:22] <phretor> so sweet
[17:23] <phretor> Keybuk: and with "start on ls_screen" I will make it starting when my other script ls_screen has started. Right?
[17:24] <Keybuk> err, no, because that will only start one instance
[17:24] <Keybuk> you'd have to have an /etc/init/somejob.conf that had:
[17:24] <Keybuk> start on filesystem
[17:24] <Keybuk> script
[17:24] <Keybuk>   start otherjob DISPLAY=:100.0
[17:24] <Keybuk>   start otherjob DISPLAY=:100.1
[17:24] <Keybuk> end script
[17:24] <Keybuk> etc.
[17:24] <Keybuk> in it
[17:25] <phretor> mh, but I want each otherjob to start as soon as ls_screen is running
[17:25] <phretor> ah ok, I got that
[17:25] <phretor> so I will have to make allotherjobs.conf
[17:25] <Keybuk> right you have one start the other
[17:26] <Keybuk> if you need it to wait, use an event, e.g.
[17:26] <Keybuk>   initctl emit --no-wait start_other_job DISPLAY=:100.0
[17:26] <Keybuk> and then
[17:26] <Keybuk> start on start_other_job
[17:26] <Keybuk>   \ and some_other_event
[17:26] <Keybuk> (you'll get $DISPLAY from the event for free)
[17:26] <phretor> the pool of otherjob is actually a set of firefox instances, and the first job is Xvfb
[17:27] <phretor> so, yes, I need Xvfb to be available before starting the pool of browsers.
[17:27] <Keybuk> right, so you could have the job that starts the others started on xvfb
[17:28] <phretor> so, start browser PORT=1234, start browser PORT=2345, ...,  within script/end script or outside script/end script?
[17:30] <Keybuk> right
[17:30] <Keybuk> within
[17:30] <phretor> Keybuk: and, how do I prevent it to run "spontaneously"? I just omit the start on [...] right?
[17:32] <Keybuk> right
[17:38] <phretor> Keybuk: in this case I am lucky, because if Xvfb dies also firefox dies. But, what if I wanted to make process P2 stop when P1 stops? Is "stop on stopped P1" implemented already?
[17:38] <Keybuk> yes
[17:38] <Keybuk> or on stopping
[17:38] <Keybuk> if you want "stop Xvfb" (explicit) to explicitly wait for the firefoxes to die
[17:39] <phretor> Keybuk: and I can leave the stop on runlevel [!2345] on firefox right?
[17:39] <Keybuk> you can
[17:39] <phretor> I know, it won't ever happen
[17:39] <phretor> because Xvfb stops when !2345 (i.e., before firefox)
[17:42] <Keybuk> same time as ?
[17:42] <phretor> yep
[17:42] <phretor> Keybuk: http://paste.pocoo.org/show/277025/
[17:43] <Keybuk> ok?
[17:44] <phretor> ls_browser PORT=4242 works fine, but for P in $PORTS; do start ls_browser PORT=${P}; done in ls_screen's script/end script won't start themm
[17:47] <Keybuk> err I'm not sure what ls_screen is?
[17:47] <Keybuk> isn't that ls_screen above>