I read trough 20 questions regarding cron jobs and what not you need to set and I did all that, don't tag this as a duplicate. So my script is this:


openRTSP_process_ids=(`/bin/ps -fu $USER | /bin/grep "openRTSP" | /bin/grep -v "grep" | /bin/grep -v $0 | /usr/bin/awk '{print $2}'`)
echo $openRTSP_process_ids
for i in "${openRTSP_process_ids[@]}"
    if [ -n "$i" ]; then
        echo $i
        kill -1 $i

and my crontab looks like this:


43,41,26,21,16,12,1,7,48,46,33,49,54,57,59,4,9,14,19,24,27,29,32,34,39,44 * * * * bash /home/username/Documents/stop_openRTSP &>> /home/username/stop.log
50,55,0,5,10,15,20,25,30,35,40,45 * * * * /home/username/Documents/start_openRTSP

I tried it with the standard sh shell and the bash shell both doesn't work. I tried redirecting the output to a log file bot using &>> bash redirection and 2>&1 sh redirection, but the log file is just empty. I tried a bunch of things but the proccess never get killed, but they do when I do it via command line.

Additionally to adding path and shell I wrote all commands with their full path. I check if it worked by looking at ps aux | grep openRTPS and looking at the processes open. When I run the script from command line the processes get closed but via cron job they just stay open.

In some versions I had a touch bla at the beginning so I do know that this specific scrip IS getting executed but not all commands.

closed as off-topic by Kusalananda, Michael Homer, G-Man, Satō Katsura, countermode May 24 '17 at 7:09

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Kusalananda, Michael Homer, G-Man, Satō Katsura, countermode
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Are you sure your cron environment sets $USER? – steeldriver May 23 '17 at 16:57
  • Add set -x to the top of your scripts, and then review the log files to ensure that they're doing what you think they're doing. – DopeGhoti May 23 '17 at 16:59
  • OOOOOOOOOOOOMYYYYY GOD. How could I have missed that for about 2h. Damn, thank you it's working :D Today was a too long day. – Hakaishin May 23 '17 at 16:59
  • Can I close my own question? Or do I just delete it now? – Hakaishin May 23 '17 at 17:00
  • 1
    If @DopeGhoti does not post his suggestion as an answer, it would be helpful to future visitors of the site if you posted his suggestion and your actions as an answer, then indicate it as the answer that worked. Thus we get a valid question with correct answer for the site archive. Thanks! – 0xSheepdog May 23 '17 at 17:08

If jobs or scripts are not doing what you expect them to, one very helpful troubleshooting tip is to add set -x to the top of the script, and inspect the output to ensure that the script is doing what you think it's doing. It's quite possible you're making some assumptions or presumptions of your runtime environment which are not borne out in the field.

Not the answer you're looking for? Browse other questions tagged or ask your own question.