[02:39] <FourAM> Hello all, I'm on a system with 1.3, and I was wondering if a script I trigger with cron can somehow see env vars of a running job; right now I'm `touch`ing files to use as flags (similar to an /etc/nologin) and I think it feels messy.
[02:42] <FourAM> I know I can pass values with events/when starting and I can start on starting ENV_VAR='something' but when I trigger a job from cron i need to read the state of another job (to decide if i want the cron's job to continue)
[12:08] <bradleyayers> FourAM: just use "status foo"
[16:28] <Kiall> Heya, is there somewhere that upstart keeps some kind of state? Trying to write a job and it keeps stalling while starting .. So.. I deleted the job config, re-ran stop.. and is seems to still know about the job?
[16:28] <SpamapS> Kiall: yes running jobs are kept in memory
[16:29] <Kiall> SpamapS: aha, so what would I need to restart?
[16:29] <Kiall> I was looking for how upstart itself was started, but havent found it yet
[16:29] <SpamapS> Kiall: once you stop a job that has been removed, it should cease to exist
[16:29] <SpamapS> Kiall: upstart is run as the init daemon of the system
[16:30] <SpamapS> Kiall: so its started before *everything else*
[16:30] <Kiall> "stop: Job has already been stopped: .."  yet, the /etc/init/.conf file as been removed. Is that normal?
[16:31] <Kiall> I'm not sure if that means it still knows something about the job?
[16:40] <SpamapS> Kiall: status 'job' will tell you what it knows about the job
[16:41] <Kiall> SpamapS: yea, "graylog2-server stop/killed, process 15009" and "/etc/init/graylog2-server.conf: No such file or directory"
[16:41] <Kiall> (the and part was me doing an ls..)
[16:42] <SpamapS> Kiall: ok, so its waiting for the process, 15009, to die
[16:42] <Kiall> Yea - I had thought that too, but 15009 doesnt exist
[16:43] <SpamapS> Kiall: ahh, you may have used the wrong expect syntax, thats a known evil bug
[16:43] <Kiall> 150* doesnt even exist
[16:43] <Kiall> dooh 
[16:43] <Kiall> Okay, any way to sort it without a reboot? :)
[16:43] <SpamapS> there's a lame workaround
[16:44] <SpamapS> Kiall: you have to get that pid to re-appear
[16:45] <SpamapS> Kiall: so you can do it with a program that just exhausts the pid space
[16:45] <SpamapS> Kiall: not exhausts, but, rolls it over
[16:46] <Kiall> Lol - Any suggestions for a script/tool/etc to do what? or will a while true; do echo "."; done handle that?
[16:46] <SpamapS> Kiall: bug 406397 has a link to a ruby script that does it
[16:46]  * SpamapS is looking for a python version he wrote
[16:46] <SpamapS> Kiall: echo is a bash builtin, so no ;)
[16:47] <Kiall> but the "true" is /bin/true ;)
[16:47] <Kiall> unless bash has that too -_-
[16:47] <SpamapS> Kiall: yeah that might work
[16:47] <Kiall> Found that ruby script anyway, it seems to stop at the right pid etc which is always handy :)
[16:48] <SpamapS> Kiall: even better, just keep spawning status on your job and grepping it
[16:48] <SpamapS> Kiall: while status foo | grep pid ; do : ; done
[16:49] <Kiall> woot - "Unknown Job:" :)
[16:50] <Kiall> and its all fixed+worked.. Thanks :)
[16:50] <Kiall> This would have driven me nuts for hours!
[16:56] <SpamapS> Kiall: yeah its a pretty confusing bug. :(
[16:56] <Kiall> Thats for sure ;)
[16:57] <Kiall> I was wondering why *nothing* i did in the job config would make it work.. Eventually (20-30 mins later) figured some sort of state was being kept ;_