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?

Vlastimil Burián
  • 28,462
  • @thrig I completely forgot to tell you what Linux I am on. I have edited my question. I am on Mint 17.3. – Vlastimil Burián Apr 06 '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 06 '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 06 '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 06 '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 06 '16 at 17:13
  • @derobert To test it I decided to set it for 19:00 and this is output Apr 6 19:00:01 vb-nb-mint CRON[12549]: (root) CMD (/home/vlastimil/Development/bash/full-upgrade.sh) Apr 6 19:00:25 vb-nb-mint CRON[12548]: (CRON) info (No MTA installed, discarding output) – Vlastimil Burián Apr 06 '16 at 17:15
  • @burian.vlastimil that sounds like it worked, but you might want to install an MTA (mail-transfer agent, i.e., a mail server) so that cron can send you the stderr of whatever you run. – derobert Apr 06 '16 at 17:18
  • @derobert yeah I would like to have it logged, how do I do this, shall I post another question? – Vlastimil Burián Apr 06 '16 at 17:22
  • @burian.vlastimil Installing an MTA will get it mailed to you. If you want it logged, the easiest way is to pipe it to logger, or redirect it to a file. I suspect we already have examples of both on the site... – derobert Apr 06 '16 at 17:24
  • http://unix.stackexchange.com/questions/207/where-are-cron-errors-logged – derobert Apr 06 '16 at 17:24

1 Answers1

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...)

thrig
  • 34,938