7

I have a cronjob in my crontab.

When I specify the job to be executed in 2minutes, I wait, and then I can see files created by the job, I can see the process with ps. The job takes at least 10minutes to complete.

But, if I specify the job to be executed in 2minutes, and then I log out, I come back a few minutes thereafter, and it seems that the job has not been executed (no files created, and process not in ps).

When I look to the /var/log/syslog I can see that the job 'started', but immediately (at the same second) cron tries to send a mail. Probably the mail with the result. (well, sendmail is not correctly configured but this should not be the root cause).

Do you have any idea ?


Here are some concrete example : (python is the name of my machine)

I edit the crontab using crontab -e.
Here is the crontab :

user@python:~$ crontab -l
[...]
# m h  dom mon dow   command

50 9 * * * /home/user/scripts_automated/crontab1.sh

It should run at 9:50

Here is the content of the /var/log/syslog :

[...]
Nov  6 09:48:02 python crontab[30913]: (user) BEGIN EDIT (user)
Nov  6 09:48:18 python crontab[30913]: (user) REPLACE (user)
Nov  6 09:48:18 python crontab[30913]: (user) END EDIT (user)
Nov  6 09:50:01 python CRON[30936]: (user) CMD (/home/user/scripts_automated/crontab1.sh)
Nov  6 09:50:01 python sendmail[30938]: sA68o1a4030938: from=user, size=347, class=0, nrcpts=1, msgid=<201411060850.sA68o1a4030938@python>, relay=user@localhost
[...]

As you can see in the log, I edited the crontab at 09:48:02, then I logged out. I come back on the machine (with ssh), and the job did not produce any files it should have produced.

Here is the content of the script :

user@python:~$ cat scripts_automated/crontab1.sh


#  0  ------------------------------------------------------

datenow=`date +%F_%H-%M-%S`
/home/user/scripts_automated/script_1_cisco_grab.sh > /home/user/scripts_automated/crontab/run_${datenow}_.txt 2>&1 &
echo $! > /home/user/scripts_automated/crontab/pid_${datenow}.txt
ln -s /home/user/scripts_automated/crontab/pid_${datenow}.txt /home/user/scripts_automated/crontab/pid_last_run.txt

and no file is produced. I would at least expect the file pid_${datenow}.txt to exist with the pid of the background command. But nothing. If I don't log out, then scripts executes, produces output files, pid_${datenow} file, and so on ...

7
  • How do you specify the job to be executed? Please give concrete examples, do edit the crontab file and change the two fields?
    – Anthon
    Nov 6 '14 at 10:50
  • Could you add the script to your question? Nov 6 '14 at 10:51
  • I edited my question with a concrete example
    – Stef
    Nov 6 '14 at 11:17
  • 4
    Does the user have an encrypted home directory? If so, it will be unmounted and unavailable when logged off.
    – Useless
    Nov 6 '14 at 11:18
  • 1
    @Stef You can use mount to see what is mounted /home/stef (e.g.) or /home. You don't need to decrypt your home directory, just copy the executable file somewhere that is not encrypted, as I indicated in my answer. Decrypting a home dir is possible, but you should make a new question for that, with details about your system (what Linux version, what encryption etc).
    – Anthon
    Nov 6 '14 at 13:44
6

You should put your script in a separate directory, that for sure is available while the cron job is running, e.g. /usr/local/bin/.

It is also good custom to write crontab entries like this:

M H * * *  test -x /usr/local/bin/myscript.sh && /usr/local/bin/myscript.sh

so the crontab doesn't even try to execute the script if it is not available.


You suspected the logout being the problem, what you should have tried as well is logging out and then back in in-time for the crontab to run and then observe. That way you could have narrowed down if the logging out was the problem or the being not logged in.

4
  • I tried this. I really made a lot of tries. Even unlogging after the scripts started, and I can see that the process stoped.
    – Stef
    Nov 6 '14 at 13:59
  • It should be && and not || I think
    – Luca
    Jun 17 '21 at 21:38
  • @Luca I think you are right
    – Anthon
    Jun 18 '21 at 6:23
  • yes it should be && because that would mean if-and-only-if the previous command exits successfully, then execute the next. It's opposite would be ||, which only executes if the first failed
    – Lorenzo
    Oct 25 '21 at 19:51
0

The log file shows that the crontab job was fired:

Nov  6 09:50:01 python CRON[30936]: (user) CMD (/home/user/scripts_automated/crontab1.sh)

And a moment later, an email message was sent:

Nov  6 09:50:01 python sendmail[30938]: sA68o1a4030938: from=user, size=347, class=0, nrcpts=1, msgid=<201411060850.sA68o1a4030938@python>, relay=user@localhost

The next line in the log file would almost have certainly been the complementary half to this one, showing where it went.

Why the relevance of the email? CRON captures stdout and stderr from every job it fires. If either is non-empty then it sends an email message to the user's local email account containing the text it captured. In user's case this will be have been to user's local email account. (If you have an email subsystem configured it might then be forwarded off-site but let's assume not for now.) Local email usually gets written to the file /var/mail/$USER or /var/spool/mail/$USER. It's a text file and newer messages are simply appended, so you can use more or less or even cat to view the file. The last message would have been the one you wanted to read.

Looking at the script you've created, I would suspect that in your case the error message generated would have been something like this,

-sh: /home/user/scripts_automated/crontab1.sh: Permission denied

If that's the case it's because you're trying to run crontab1.sh as a program but you've omitted to make it executable. Fix that with chmod a+x /home/user/scripts_automated/crontab1.sh.

Other errors can relate to missing environment variables, including PATH not being set as you expect. This is because cron has a very restricted environment and does not use startup files such as .bashrc, .profile, etc. Another possibility is that your home directory may be encrypted when you are not logged on. In this case cron won't be able to find the script to execute so it can only fail. There are many questions (and answers) on https://unix.stackexchange.com/ addressing these type of issue so I won't repeat them here.

The other issue I have with your script generally is that it should start with #! and then a path to its interpreter. If this is bash you'd typically write #!/bin/bash, if it's sh you'd use #!/bin/sh. Starting with # 0 ------------------------------------------------------ doesn't help the system understand how to run your script.

(Six years on, it's going to be an answer for future readers)

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.