| mreynolds__ | Hey all, upstart newb here trying to debug running Java | 00:08 |
|---|---|---|
| mreynolds | Try that again, sorry. Basically, I'm running this : script | 00:09 |
| mreynolds | exec /home/hub/hub/bin/start-MSR.sh | 00:09 |
| mreynolds | end script | 00:09 |
| mreynolds | But it doesn't seem to kick-off the script. I'm not using nohup for the java process. | 00:10 |
| mreynolds | This is on 12.04, so upstart 1.5 | 00:10 |
| mreynolds | pre-start and post-start work just fine | 00:11 |
| mreynolds | (doing a simple "touch" to make sure it executes) | 00:11 |
| mreynolds | Figured it out. We made it too hard. Removing shell control crap fixed ti. | 00:49 |
| tseliot | xnox: hi, would something like this cause lightdm to wait for the service to complete? http://paste.ubuntu.com/7004530/ | 11:15 |
| tseliot | or would it just make sure that the job starts before lightdm without blocking the latter? | 11:18 |
| tseliot | xnox: ok, it seems to block the latter: http://manpages.ubuntu.com/manpages/trusty/en/man7/starting.7.html | 11:23 |
| === marcoceppi_ is now known as marcoceppi | ||
| === SpamapS_ is now known as SpamapS | ||
| gx | if you were to run an exec script inside an upstart daemon without an expect stanza, could that result in the process being abandoned and not run even though it says it is start/running still? | 19:59 |
| gx | we're having an issue where we have a lot of daemons that are used to run a php file that polls an external API | 20:00 |
| gx | we used to run the script using wget | 20:00 |
| gx | but recently we switched to running the script using php itself | 20:00 |
| gx | and since then, it seems as though the daemons are just dying, but initctl list says theyre still running | 20:01 |
| gx | http://privatepaste.com/5ff87c1bdb | 20:02 |
| xnox | gx: upstart will track the first exec, thus the first exec of php. | 20:08 |
| xnox | gx: can you change exec to "exec bash -c /var/www/ok_market_history.sh" ? | 20:09 |
| gx | i can, what does that do exactly? | 20:10 |
| xnox | gx: what you should achieve is for: status ok_market_history, to give you the pid of your top-level bash. process. | 20:10 |
| gx | ahh | 20:10 |
| gx | so instead of only tracking the first php pid | 20:10 |
| gx | that will track the bash process, and at the very least tell me when it fails? | 20:10 |
| xnox | gx: it adds an extra exec, such that the chain is: bash -> bash -> (loop; exec php) | 20:11 |
| xnox | gx: and upstart should then track the (middle) bash, which should be your shell script. | 20:11 |
| xnox | gx: correct. | 20:11 |
| gx | thanks, i'll give it a shot | 20:12 |
| gx | as far as the daemon failing | 20:12 |
| gx | i apologize for not understanding it well enough at this point- but is there some kind of error log? | 20:12 |
| relisys | xnox: should we be using "expect daemon" and "respawn" stances to run the above posted script as a service daemon | 20:27 |
| relisys | before exec | 20:27 |
| relisys | ? | 20:27 |
| xnox | relisys: no, not really. | 20:28 |
| relisys | ok, tks | 20:29 |
| gx | i guess i'm just trying to figure out why the daemon would be "failing" or stopping on its own, at all | 20:29 |
| xnox | relisys: check the pids thought, "status" should match what you see in "ps" and it should track your bash script. | 20:29 |
| gx | when we were doing wget instead of php -f, none of the daemons ever quit on their own, as far as i can remember | 20:29 |
| gx | unless relisys begs to differ | 20:30 |
| relisys | i don't remember it happening prior to that | 20:30 |
| gx | this has strictly been happening since we started executing the php files directly as opposed to wgetting the url | 20:30 |
| gx | thats why i'm a little confused | 20:30 |
| xnox | relisys: gx: it all looks weird. you are best to have job just calling the php command. | 20:30 |
| xnox | relisys: gx: and have a cron job to do "start foo" every 20seconds. | 20:31 |
| gx | hmm | 20:31 |
| xnox | relisys: gx: that way you only have one instance at the time, every 20seconds. | 20:31 |
| gx | well we have it built into the script to detect if it's running or not | 20:31 |
| xnox | relisys: gx: if that php command runs.... and eventually exits. that your job should declare "task" stanza. | 20:31 |
| gx | if the script is active, it just exits | 20:31 |
| xnox | relisys: gx: see upstart cookbook. | 20:32 |
| xnox | gx: if you have it built into the script, why bother with an upstart job?! | 20:32 |
| xnox | gx: it looks like you only need cron to kick it off || true, every 20seconds. | 20:32 |
| gx | well for a few reasons | 20:32 |
| relisys | we used to have it that way | 20:32 |
| gx | #1 thats what everyone ive spoken with who's knowledgeable on the subject said we should do | 20:33 |
| gx | #2 we're able to better monitor everything with daemons, or so we were told | 20:33 |
| gx | #3 it's easier to start/stop using daemons as opposed to editing crontab, i guess. | 20:33 |
| gx | feel free to argue any of those points | 20:33 |
| gx | i'm still learning | 20:33 |
| gx | ohh right | 20:34 |
| gx | and a big #0 - crons only have resolution of 1 minute | 20:34 |
| relisys | we alos wanted it to run right away again | 20:34 |
| relisys | yeah | 20:35 |
| relisys | xnox seems to have implied otherwise tho... | 20:35 |
| gx | as opposed to running the script multiple times within a php loop, which would cause a whole other headache of problems | 20:35 |
| gx | but regardless we had 0 problems with the way we were doing it, when we were calling wget | 20:35 |
| gx | so i'm trying to understand why executing php directly would all of a sudden cause tehse issues | 20:36 |
| gx | and as far as i can tell, the only benefit we gained is less apache2 processes used | 20:36 |
| xnox | gx: apart from you don't have a daemon. you have a one-shot task, which you want to be periodic. | 20:38 |
| gx | right, it's not something that's opening a socket and listening or anything like that | 20:39 |
| gx | it's a php script that pulls from an api, normalizes some data, and inserts into db | 20:39 |
| gx | but we want it to run every 20 seconds | 20:39 |
| gx | and we have it built in so that if by chance it takes > 20 seconds, it detects that it's actively running, and quits, and will be run at the next free instance | 20:40 |
| xnox | gx: so, three cron jobs exec every minute: sleep 1 && yourscript. sleep 21 && yourscript. sleep 41 && yourscript. | 21:23 |
| gx | xnox i understand we can do that, and we just might- but it still doesnt help me understand why the daemon would be quitting in the first place, after switching from wget to php | 21:29 |
| gx | im more after that information than anything, for my own understanding | 21:29 |
| gx | but yeah it's sounding like we might want to go back to cron jobs | 21:29 |
| xnox | gx: you can do it with two upstart jobs. First job, has script stanza and does the while loop, each time it does "initctl start --no-wait main-job". | 21:31 |
| xnox | gx: and main-job is just straing exec to php, with task stanza. | 21:31 |
| xnox | gx: and without any bash shell wrapper. | 21:31 |
| xnox | gx: this way you have the 20s trigger/controller job, which starts at most one worker. | 21:32 |
| === SpamapS_ is now known as SpamapS | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!