Brief description

I have a custom cron script that runs daily on a raspberry pi. It runs each evening at 8pm, but fails every time on a certain command in the script. However, when I login as root (sudo su), and start the script, it always works fine. So I manually can not trigger the error, but have to wait each time for the cron job to run, to troubleshoot it (without success, so far).

Question: What else can I do to better simulate the behaviour and context of the script being run from a cron job?

Some more context

The script mounts an NFS share (hosted on my synology NAS), syncs some IMAP imap accounts to the NFS share, and then commits the new state using mercurial.

me@mango:/etc/cron.daily8pm$ ls -l
total 4
-rwxr-xr-x 1 root root 1722 Jun  6 22:08 backupimaps

Showing the relevant part of the script:

me@mango:/etc/cron.daily8pm$ sed -n '38,47p' backupimaps
echo Performing IMAP backup\(s\)
#use basic interface (=noninteractive, good for cron)
offlineimap -u basic -c /etc/offlineimaprc

if [ $? -eq 0 ]; then
    echo "Committing changes (addremove)..."
    hg addremove --verbose -R $MOUNTDIR                <--- failure on this command
    echo "Committing changes (real commit)..."
    hg commit -u "cronjob $USERNAME @ $HOSTNAME" -m "Autocommit @ $TIMESTAMP" -R $MOUNTDIR

When run as cron job, it always fails on the hg addremove --verbose -R $MOUNTDIR line with an abort: Permission denied... statement, continuing to the next statement. This is part of the emailed cron job output

***** Finished processing account fmklaske
Committing changes (addremove)...
removing fmxxxxx/INBOX.Archief/cur/1439586438_1.7100.voyage,U=3233,FMD5=178b19d5fa680033b330f587796f66de:2,S
adding fmyyyy/INBOX/new/1496858746_2.3294.mango,U=59804,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,
abort: Permission denied: '/mnt/imapbackup/fmxxxxx/INBOX.HOTMAIL OUD/cur/1496858720_0.3294.mango,U=18109,FMD5=7ae3c37de1c6bb870abee958daf1c6f6:2,S'
Committing changes (real commit)...
nothing changed (37 missing files, see 'hg status')

I have no clue why it fails, as when I run the job manually, it completes successfully and commits the changed files as expected. Furthermore, the email message it reports to fail on is not special, and permissions look OK.

For further context:

me@mango:/etc/cron.daily8pm$ sudo tail -n 3 /var/log/cron.log
Jun  7 19:17:01 mango CRON[3231]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jun  7 20:05:01 mango CRON[3284]: (root) CMD ( test -x /usr/sib/anacron/ || ( cd / && run-parts --report /etc/cron.daily8pm ))
Jun  7 20:17:01 mango CRON[3431]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

And my crontab file

me@mango:/etc$ cat crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.


# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
05 20  * * * root  test -x /usr/sib/anacron/ || ( cd / && run-parts --report /etc/cron.daily8pm )

Note: while writing, this I noticed the error in the /usr/sib/anacronpath in the last line. I just fixed it, but this shouldn't have any effect IMO

  • Does ag depend on settings that are loaded during an interactive login? – Jeff Schaller Jun 7 '17 at 19:34
  • I'm curious what the value of $MOUNTDIR at the time of execution as well the current working directory. In the abort message I see '/mnt/imapbackup/fmxxxxx/INBOX.HOTMAIL OUD/cur/1496858720_0.3294.mango,U=18109,FMD5=7ae3c37de1c6bb870abee958daf1c6f6:2,S' and a couple other relative directories. Perhaps when you run it manually you're in a directory that these are relative to, but when executed out of cron, the relative paths are no longer valid because pwd is /root. – Deathgrip Jun 7 '17 at 22:34
  • @jeff: good suggestion. I look around in my bashrc and profile, etc files. But nothing relevant. I don't even have a hgrc file on this system. I also tried this solution (serverfault.com/a/541368) but when triggered manually it works as intended. For Deathgrip: the paths are absolute, not relative, no? – Rabarberski Jun 8 '17 at 19:17
  • see unix.stackexchange.com/questions/56491/… for tips on showing cron's environment, which you can then compare to your interactive (working) environment. – Jeff Schaller Jun 8 '17 at 19:45
  • @JeffSchaller: yes, yesterday evening I tried something like that. No solution. I resetted my mercurial repository, as I am suspecting that there is something wrong with permissions in the repo. Waiting for the answer this evening... – Rabarberski Jun 9 '17 at 7:53

Your Answer

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

Browse other questions tagged or ask your own question.