I have a script that checks to see if port 4000 is open and listening, if it is return true, else start a service that also outputs a logfile. The script runs fine if I execute it as a user, but if I add it as a cron it doesn't run. I'm logged in as root, the script is owned by root, the script has executable permissions, and I am running crontab -e as root.

if lsof -Pi :4000 -sTCP:LISTEN -t >/dev/null ; then
    return 1
    seoserver -p 4000 start > /var/www/vhosts/domain.com/httpdocs/seoserver.log &

And here is my cron

*/5     *       *       *       *       /usr/bin/seoStart
  • you should monitor you cron jobs to see what is actually going on, /var/log/cron might help, also you can redirect output to some file and check as well what is the issue from cron – klerk Feb 24 '15 at 18:35

Cron doesn't start with common environment variables that your user has, including $PATH.

You have the full path in your cron, which is good, but you need to add it to your script as well.

which lsof


which seoserver

will give you the full path. Modify your script to use that instead of lsof and seoserver.

  • Is there any security concern with opening up the path inside of /etc/crontab to include the paths that my user has available, or should I really be doing this within my bash script? – codewizard Feb 24 '15 at 18:36
  • Any security concerns would be pretty minor, but best practice would be to update the script. – rmelcer Feb 24 '15 at 19:04
  • I think that depends on where you're expanding your $PATH to. If it's writable to users or highly nonstandard, use the full path. If it's merely something like /usr/local/bin, that should be safe to add in the crontab and may save you from some future hair-pulling. – Adam Katz Feb 26 '15 at 0:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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