alienth | hey folks, any solution for firing a script that forks 3 times? | 00:19 |
---|---|---|
SpamapS | alienth: sure.. don't do that. ;) | 04:05 |
SpamapS | alienth: why does it need to fork (and exit) 3 times? | 04:06 |
alienth | SpamapS: so, the situation is i'm trying to upstart memcached | 06:01 |
alienth | memcached doesn't take a config file, so it uses a wrapper perl script, which forks, and then calls a daemon | 06:01 |
SpamapS | alienth: heh, that weird perl script is a fail :) | 06:52 |
SpamapS | alienth: there's really no need. Just run memcached directly | 06:52 |
SpamapS | alienth: I actually wrote an upstart job for memcached a few months ago but never got around to getting it into Ubuntu | 06:52 |
dcorbin_work | I have simple upstart script: https://gist.github.com/2405988 In circumstances we haven't figured out yet, jboss is shutting down gracefully, and then appears to restart 10-30 minutes later. How can I verify that upstart is or is not involved in this? | 13:42 |
SpamapS | dcorbin_work: start on starting enttek-inventory | 15:47 |
SpamapS | dcorbin_work: I'd suspect that enttek-inventory is starting back up ;) | 15:47 |
SpamapS | dcorbin_work: I wonder, why don't you 'stop on stopped enttek-inventory ? | 15:57 |
dcorbin_work | SpamapS: I'm sure it could be better. The real issue is figuring out why it's stopping in the first place. Is there an upstart log that tracks the events? | 16:42 |
SpamapS | dcorbin_work: you can do 'initctl log-priority info' and you'll get all the job status changes in syslog | 16:54 |
JanC | also see http://upstart.ubuntu.com/cookbook/#debugging | 16:54 |
SpamapS | dcorbin_work: also if it is stopping gracefully thats not really in upstart's realm. It will only respawn on a non-normal exit. | 16:54 |
dcorbin_work | SpamapS: it is stopping gracefully. But my expectation is that the stopping is no through upstart. I'm just having to track it down. Sadly, we've 40+ servers (and growing) and it's only happend 3 times in the last few months. | 17:01 |
SpamapS | dcorbin_work: you can always change the notion of 'normal exit' to not include '0', so 'normal exit 99' would only not-respawn on exit code of 99. I think. You'd need the 'respawn' keyword too. | 17:04 |
dcorbin_work | SpamapS: The problem we're facing is that it's getting shutdown in the middle of a "process" that won't restart automatically, even if jboss is respawn. i.e., respawning isn't enough to fix it for us. We'll see what logging shows us. | 17:06 |
SpamapS | ahh yeah thats probably not upstart's fault :) I bet you'll see 'exitted with 0 status' | 17:09 |
dcorbin_work | SpamapS: I'm 99% sure it's not upstart, I just don't have any other good places to eliminate yet. :) | 17:12 |
mirth | does anyone know when autovacuuming runs and if it will lock the db if done during production hours? | 18:11 |
SpamapS | mirth: either thats the wrong window, or somebody spliced your upstart man pages with your postgres man pages. :) | 18:13 |
mirth | heh...i typed swapped username and channel name when joining :) | 18:16 |
mirth | usually use 'upstart' as my nick | 18:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!