[09:30] <froes> hi guys, i used to use init and was able to start 2 XDM instances on my machine. tty0-tty3 was consoles and tty4 and tty5 were gdm consoles. is there a way i can do it on upstart or should i go back to init ?
[09:48] <BlackDex> Hello there
[09:48] <BlackDex> i am trying to create an upstart config so i can start a java application via a screen
[09:49] <BlackDex> but for some reason init has a non running pid as the pid that should be running
[09:51] <BlackDex> if i do status <conf-name> it returns pid 531, but the app is running under pid 534
[09:52] <BlackDex> so now i can't start/stop it any more
[12:25] <JanC> BlackDex: currently upstart is not able to determine the exact PID when a service forks more or less than it expects
[12:25] <JanC> and I guess using screen doesn't make that easier...
[12:27] <JanC> it's probably best to stop & start the application from within the pre-start & pre-stop stanzas...
[12:30] <BlackDex> janC i have figured it out just a few second ago, with some help via the mailing-list
[12:31] <BlackDex> i need to start screen with -D -m, and no console, no expect or what ever, that did the trick
[12:32] <BlackDex> so it looks like this: exec su myapps -c "screen -D -m -S MYAPP java -jar MyApp.jar"
[12:32] <BlackDex> now i can screen -r into it using the user myapps, and i can start/stop etc via service
[19:42] <jMCg> Hello happy people.
[19:43] <jMCg> I'm trying to get a daemon running via runit which won't daemonize by itself, and which needs to run as a specific user, but can't setuid() itself.
[19:45] <jMCg> My pathetic atempts: http://dpaste.com/524600/ look like this, both of which do not work.
[19:46] <jMCg> With start-stop-daemon it records the wrong pid, and with su it doesn't really start.
[19:49] <ion> expect fork *definitely* won’t match the behavior of that main process.
[19:49] <jMCg> Won't?
[19:49] <jMCg> hmnn.. I thought.. it would match with start-stop-daemon
[19:49] <ion> Can you make it not daemonize and not use ‘expect’?
[19:50] <jMCg> Can you reduce the negations in that sentence, thereby making it more understandable, please.
[19:51] <ion> Make your main process not daemonize. Don’t use ‘expect’.
[19:51] <jMCg> ACK.
[19:52] <jMCg> Okay. Now how do I get rid of this state:
[19:52] <ion> Reboot or use the nasty kluge at http://heh.fi/tmp/workaround-upstart-snafu
[19:52] <jMCg> tibemsd start/killed, process 4694
[19:52] <ion> workaround-upstart-snafu 4694
[19:54] <jMCg> tibemsd start/running, process 4702
[19:54] <jMCg> Even though it's not.
[19:55] <jMCg> Does that workaround-upstart-snafu still work in that case?
[19:56] <ion> Does ‘stop tibemsd’ fail?
[19:57] <jMCg> Nope.. it just hangs.
[19:58] <jMCg> So, yes, it sortof fails.
[19:58] <ion> I mean, does it get stuck in …/killed (because of incorrect use of ‘expect’)? If it does, workaround-upstart-snafu should nudge Upstart back into a good state.
[19:58] <ion> A future release will have more robust code to track forks.
[19:59] <jMCg> ion: yes, it does.
[19:59] <jMCg> ACK, so I'll just clean stuff up with workaround-upstart-snafu.. I seem to have spend a lot of time.. "testing".
[19:59] <jMCg> tibemsd stop/waiting
[20:00] <jMCg> w00t.
[20:00] <jMCg> tibemsd start/running, process 4723
[20:00] <jMCg> tibco     4723     1 TS   19 20:58 ?        00:00:00 /opt/apps/tibco/ems/5.1/bin/tibemsd64
[20:01] <jMCg> exec chpst -u tibco:tibco -U tibco:tibco /opt/apps/tibco/ems/5.1/bin/tibemsd64
[20:01] <jMCg> That's what I'm using right now, and it works out fine.
[20:02] <jMCg> ion: I really hope a next release will be able to handle that itself :-/
[20:03] <jMCg> Or should I say: Is there anything I can do to help a next release do that itself?
[20:07] <ion> You could test http://upstart.at/git/?p=scott/intendant.git with any programs you want, e.g. tibemsd with daemonization. git clone git://upstart.at/scott/intendant.git, build it, sudo ./intendant some-command. No child process should be able to escape it. Please email the logs (no matter if it works correctly or not) to Keybuk at scott@netsplit.com
[20:08] <ion> That’s a test program that implements the method Upstart will use at some point in future.
[20:10] <jMCg> ion: How do I generate the configure? autoreconf -i complains it's missing an m4 dir.
[20:11] <jMCg> s/.*//
[20:16] <jMCg> I did a /opt/bw/sbin/itedant /opt/bw/sbin/vsftpd and got a shitload of: cgroup notify closed on us?! 
[20:16] <jMCg> as result.
[20:16] <jMCg> Not quite sure why.
[20:16] <ion> Not a problem.
[20:16] <ion> All results are useful.
[20:17] <ion> The main thing is that it shouldn’t lose track of any of the child processes.
[20:18] <jMCg> hehheheh
[20:19] <jMCg> Also: how do I start something with params?
[20:20] <jMCg> No man pages.
[20:20] <jMCg> brb, need to pick up dinner.
[20:20] <jMCg> Like.. half an hour ago.
[20:20] <ion> Just add them on the command line.
[20:28] <jMCg> Ah.. right.. makes sense.. had a typo.
[20:28] <jMCg> sudo /opt/bw/sbin/intendant /opt/bw/sbin/vsftpd /etc/bw/vsftpd/vsftpd.conf
[20:28] <jMCg> Now works out fine.
[20:28] <jMCg> Well, until I Ctrl+C, that is, then I get the same cgroups stuff again.
[20:29] <ion> Not a problem.
[23:04] <Keybuk> jMCg: when you ^C, do all the processes of vsftpd go away again?
[23:15] <jMCg> Keybuk: it's just one, so, yes.
[23:22] <ion> % bzr pull
[23:22] <ion> Using saved parent location: bzr+ssh://bazaar.launchpad.net/%2Bbranch/upstart/
[23:22] <ion> Conflicting tags: 1.0