0

I have an application written in Qt that runs on Ubuntu, let's call that application Foo. Foo runs the following script once around once a minute:

./x &  # Run this program in the background
childPid=$!
pkill -x "Foo"
./Foo &
sleep 5
pkill $childPid

This works as expected for the first 14 or 15 "generations" - it runs the x program, closes my Foo program, relaunches my Foo program, and then kills the x program. But, on the 14 or 15th generation/cycle/what have you - the x program keeps running and as far as I can tell, never dies again after that.

I know it's madness, but I more or less have to do it this way (at least, I need to run x, close foo, relaunch foo, close x every n seconds, if there is a better way to accomplish that I am all ears!)

If anyone has any idea at all what could be causing this, I would greatly appreciate the insight. Thank you!

jconder
  • 686
  • 4
  • 9
  • 1
    `pkill` works by name, not by PID. Just use `kill` to work by PID. – Charles Duffy Jan 17 '15 at 00:32
  • Also, I'd strongly suggest using one of the prebuilt scriptlets or 3rd-party tools documented in BashFAQ #68: http://mywiki.wooledge.org/BashFAQ/068 – Charles Duffy Jan 17 '15 at 00:33
  • http://stackoverflow.com/questions/601543/command-line-command-to-auto-kill-a-command-after-a-certain-amount-of-time also contains suggested solutions which don't suffer from the bug given here. – Charles Duffy Jan 17 '15 at 00:35
  • I'd also suggest adding more logging, and perhaps a failure check so you can detect when this is no longer working as designed. You can use `kill -0 "$pid"` to check whether a PID still exists (doesn't actually send any signal, but exits with a zero status if the program is running and a nonzero command if it doesn't), or `wait "$pid"` to block until a process actually exits (since there can be a delay between when you send something a signal and when it finishes handling that signal) and determine its exit status when it does. – Charles Duffy Jan 17 '15 at 00:39
  • Ahhhh, I am idiot - I never thought to just add the timeout to the x program. The rest of your suggestions are good too, thank you very much. – jconder Jan 17 '15 at 00:43
  • This is a late update but, turns out the problem was some rogue program was 'randomly' starting the application. It _really_ confused me and had me in a bind. Since it was a fullscreen program that forced itself always on top all the time, and the only way to not have it do that was exit out of the program using the ESC key - it was a pain in the bum to figure out and fix. – jconder Mar 31 '15 at 18:14
  • FWIW -- I'd consider using sysdig in the future to diagnose that kind of situation; would give you a record of what started what when, and what each process was doing just before/after each such action. – Charles Duffy Mar 31 '15 at 19:57

0 Answers0