0

Is there a log of crontab for me to know if crontab is working fine? I am on Linux Mint 17.3.

What I have done:

  1. ran crontab -e as root
  2. it did not exist, so I chose nano editor and proceeded
  3. entered this line 00 12 * * * /home/vlastimil/Development/bash/full-upgrade.sh
  4. saved and exited

My goal is to automate updates every single day at 12 hours (midday, not midnight). This thread is not about arguing the best way to achieve that.

I created /home/vlastimil/Development/bash/full-upgrade.sh file with content:

#!/bin/bash
apt-get update && apt-get dist-upgrade -y && apt-get --purge autoremove -y

And finally I have set 755 rights to the file.

I don't know how to test it. Will it work?

  • @thrig I completely forgot to tell you what Linux I am on. I have edited my question. I am on Mint 17.3. – LinuxSecurityFreak Apr 6 '16 at 17:04
  • 2
    to simply test cron just replace command part by date >> /tmp/cron-test.log thus, you will now if it work and when. – Archemar Apr 6 '16 at 17:04
  • @Archemar that's really a bad habit to get in to; put the log in ~ instead: /tmp is writable by everyone, and if someone were to notice that cron job, they could potentially at some point place a symlink there, and then (depending on security settings) root could be appending date to an arbitrary file... – derobert Apr 6 '16 at 17:08
  • @derobert, the real way is to look at the log, a dirty, quick and temporary way is as describe above. of course after you know, delete file and line from crontab. – Archemar Apr 6 '16 at 17:10
  • @Archemar that quick and temporary way is made much safer by putting the log file in the user's home directory, not /tmp. "Temporary" things of course have a risk of being forgotten (a file logging the date once a day isn't likely to cause any problems—until someone malicious shows up). – derobert Apr 6 '16 at 17:13
4

Logs probably go to syslog, which varies depending on what syslog daemon is involved and how that is configured to log, start with

grep -r cron /etc/*syslog*

to find where and what is going on on the system, or per derobert under systemd the relevant command is

journalctl -b 0 _SYSTEMD_UNIT=cron.service

Adding a test cron job that touches a file (ideally not in /tmp, unless the vendor makes that per-user private, for security reasons) should also confirm whether cron is working or not, just be sure to eventually remove the test cron job before it fills up a partition or something silly.

Other usability and security pointers: some cron daemons can run scripts directly, in which case you can just copy the script into /etc/cron.daily, though this may not suit something that you do not want to run (with everything else!) at exactly the top of the hour. root running a script under a user's home directory could be very bad, as a compromise of that user account could then be leveraged to root access, or the script could needlessly fail if the home directory is on NFS or encrypted; move the script elsewhere to avoid this (/root/bin, or somewhere under /usr/local or /opt depending on the local filesystem preferences).

Even more pointers fall into the realm of shell script debugging, mostly to note that cron is not the shell; use env or set to see what is set under cron, check that PATH is correct, and etc. (One old and horrible linux kernel bug involved java daemons crashing but only if they were run from cron; that was fun to debug...)

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.