0

I have setup and cron to check if a port is busy or free and if its free then it sends and email and then start golang api service

send mail is working properly but api server is not getting started

following is my crontab file 

*/2 * * * * /home/ubuntu/sh/projectrun.sh

It runs projectrun.sh file every 2 minute, following is my code in this sh file 

#!/bin/bash
lsof -i :8080 | grep LISTEN || echo "Not listening" | curl "http://mysiteurl.com/serverlog/?s=cron"
lsof -i :8080 | grep LISTEN || echo "Not listening" | tmux new-session -d -s bkapi3_session 'bkapi'

first line is executing properly as I am getting mails regulary but second command is not working, it works if I run this command directly from console like 

lsof -i :8080 | grep LISTEN || echo "Not listening" | tmux new-session -d -s bkapi3_session 'bkapi'

Not sure what is the issue and how to resolve it

Vikram
  • 167
  • 2
  • 10
  • try full path like `*/2 * * * * /bin/sh /home/ubuntu/sh/projectrun.sh` – sanjayparmar Sep 19 '18 at 05:18
  • 1
    PATH in cron is not the same as in your login shell and both in thecronjob as well as the script either use absolute paths to all commands or set the correct PATH explicitly – HBruijn Sep 19 '18 at 05:37
  • My guess would be that tmux needs a proper terminal to work. What do you need it in a cron job for anyway? – Gerald Schneider Sep 19 '18 at 06:01
  • @GeraldSchneider Sometimes my golang api service stops unexpectedly, so I want to run the cron to check the port and if its open means api is not running and restart the api using tmux – Vikram Sep 19 '18 at 06:24
  • Why don't you let just systemd manage it? It restarts failed services automatically. – Gerald Schneider Sep 19 '18 at 06:34
  • I am trying to do it with systemd but it works with services only and api is not a service, not sure how should I make a service – Vikram Sep 19 '18 at 06:42

1 Answers1

-1

Try with full path of sh like -

*/2 * * * * /bin/sh /home/ubuntu/sh/projectrun.sh
sanjayparmar
  • 623
  • 8
  • 18
  • 1
    That's unnecessary, the full path to bash is already in the shebang line. – Gerald Schneider Sep 19 '18 at 06:00
  • @GeraldSchneider You should put full paths in your crontab like `/bin/sh`. That's the safest option.how can you say its unnecessary? – sanjayparmar Sep 19 '18 at 07:20
  • if `.sh` not executable then ? – sanjayparmar Sep 19 '18 at 07:22
  • 1
    The OP states that the first line of the script is executed and only the second line doesn't work. That means the script is executed. That means the script is executable and the shell (bash) is found properly. – Gerald Schneider Sep 19 '18 at 07:38
  • @sanjayparmar It's safer to leave `/bin/sh` out from that command line. The interpreter path belongs in the `#!` line and nowhere else. If you ever decide to switch to another interpreter (maybe `/bin/bash`), you are likely to only update the path in the `#!` line. If any caller is bypassing the `#!` line by passing the file as argument to an interpreter rather than executing the shell, those invocations will at that point be broken because they are using the wrong shell, and it can be difficult to find them all. So better not do that in the first place, and instead use the `#!` line. – kasperd Sep 19 '18 at 13:35