| 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:30 |
|---|---|---|
| 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:48 |
| BlackDex | but for some reason init has a non running pid as the pid that should be running | 09:49 |
| BlackDex | if i do status <conf-name> it returns pid 531, but the app is running under pid 534 | 09:51 |
| BlackDex | so now i can't start/stop it any more | 09:52 |
| 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:25 |
| JanC | it's probably best to stop & start the application from within the pre-start & pre-stop stanzas... | 12:27 |
| BlackDex | janC i have figured it out just a few second ago, with some help via the mailing-list | 12:30 |
| BlackDex | i need to start screen with -D -m, and no console, no expect or what ever, that did the trick | 12:31 |
| 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 | 12:32 |
| === 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 | ||
| jMCg | Hello happy people. | 19:42 |
| 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:43 |
| jMCg | My pathetic atempts: http://dpaste.com/524600/ look like this, both of which do not work. | 19:45 |
| jMCg | With start-stop-daemon it records the wrong pid, and with su it doesn't really start. | 19:46 |
| 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:49 |
| jMCg | Can you reduce the negations in that sentence, thereby making it more understandable, please. | 19:50 |
| ion | Make your main process not daemonize. Don’t use ‘expect’. | 19:51 |
| jMCg | ACK. | 19:51 |
| 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:52 |
| jMCg | tibemsd start/running, process 4702 | 19:54 |
| jMCg | Even though it's not. | 19:54 |
| jMCg | Does that workaround-upstart-snafu still work in that case? | 19:55 |
| ion | Does ‘stop tibemsd’ fail? | 19:56 |
| jMCg | Nope.. it just hangs. | 19:57 |
| 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:58 |
| 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 | 19:59 |
| 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:00 |
| 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:01 |
| jMCg | ion: I really hope a next release will be able to handle that itself :-/ | 20:02 |
| jMCg | Or should I say: Is there anything I can do to help a next release do that itself? | 20:03 |
| 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:07 |
| ion | That’s a test program that implements the method Upstart will use at some point in future. | 20:08 |
| jMCg | ion: How do I generate the configure? autoreconf -i complains it's missing an m4 dir. | 20:10 |
| jMCg | s/.*// | 20:11 |
| 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:16 |
| ion | The main thing is that it shouldn’t lose track of any of the child processes. | 20:17 |
| jMCg | hehheheh | 20:18 |
| jMCg | Also: how do I start something with params? | 20:19 |
| 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:20 |
| 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:28 |
| ion | Not a problem. | 20:29 |
| Keybuk | jMCg: when you ^C, do all the processes of vsftpd go away again? | 23:04 |
| jMCg | Keybuk: it's just one, so, yes. | 23:15 |
| ion | % bzr pull | 23:22 |
| ion | Using saved parent location: bzr+ssh://bazaar.launchpad.net/%2Bbranch/upstart/ | 23:22 |
| ion | Conflicting tags: 1.0 | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!