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