Crontab can't create logs (Permission Denied)

Question

I have a script that I want to run every hour, and the echo's of that script and other output, I want to be able to read.

Now when I take a look at /var/log/syslog, I see some weird stuff that I can't explain. Please see below.

Would anyone know what my issue is?

Apr 29 22:52:01 raspberrypi cron[408]: (pi) RELOAD (crontabs/pi)
Apr 29 22:52:01 raspberrypi CRON[8189]: (pi) CMD (/home/pi/Projects/test-cron.sh)
Apr 29 22:52:01 raspberrypi cron[408]: 2022-04-29 22:52:01 1nkXar-000288-H2 Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=112 egid=119
Apr 29 22:52:01 raspberrypi cron[408]: 2022-04-29 22:52:01 1nkXar-000288-H2 <= pi@raspberrypi U=pi P=local S=575
Apr 29 22:52:01 raspberrypi cron[408]: 2022-04-29 22:52:01 1nkXar-000288-H2 Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=112 egid=119
Apr 29 22:52:01 raspberrypi cron[408]: exim: could not open panic log - aborting: see message(s) above
Apr 29 22:52:01 raspberrypi exim[8192]: 2022-04-29 22:52:01 1nkXar-000288-H2 <= pi@raspberrypi U=pi P=local S=575
Apr 29 22:52:01 raspberrypi exim[8192]: 2022-04-29 22:52:01 1nkXar-000288-H2 Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=112 egid=119
Apr 29 22:52:01 raspberrypi exim[8192]: exim: could not open panic log - aborting: see message(s) above
Apr 29 22:52:01 raspberrypi CRON[8188]: (pi) MAIL (mailed 6 bytes of output but got status 0x0001 from MTA#012)

I have no idea what exim4 is, I never installed this. I just wanna see some logs from my cron jobs.

More information about my setup:

crontab -e

# Thanks to https://linuxhint.com/check_working_crontab/
# I know this is not every hour; this is just an example to make the job run frequently!
* * * * * /home/pi/Projects/test-cron.sh 

ls -la in /home/pi/Projects

drwxr-xr-x  5 pi   pi   4096 Apr 29 22:42 .
drwxr-xr-x 25 pi   pi   4096 Apr 29 01:24 ..
-rwxr-xr-x  1 pi   pi     13 Apr 29 22:39 test-cron.sh

test-cron.sh

echo "TESTING CRONJOBS!"

---

Now, I would expect if I did something like cat /var/log/syslog | grep "TESTING CRONJOBS!", I would see the results... But I don't!

---

Answer 1

Basically, there are two problems: exim and cron.

Exim is mail. The message:

log file "/var/log/exim4/mainlog": Permission denied: euid=112 egid=119

gives you the reason why exim will not start. As a quick fix, you could

chown -R 112 /var/log/exim4

Cron sends standard-out to the mail, not to the syslog. Because your mail is aborting, you never get this mail. If you want to log to the syslog, use logger, as in

logger "TESTING CRONJOBS works in this way"

Answer 2

The bullseye distribution introduced many changes to cron. If you've used cron previously - or on other distributions - you will need to acquaint yourself with these changes which have flowed down to Raspberry Pi OS from Debian. If you're running bullseye, it can be said that you are now running the Debian version of cron. It's not altogether different, but there are some changes you should be aware of.

If you're new to cron, this is all new anyway, so don't worry :)

Take Note:

Unless you actually prefer to get your cron outputs via email, you should add the following line to your user crontab:

MAILTO=""

Why do this? To disable cron's default behavior for mailing output to the owner of the crontab. See REFERENCE # 1 below.

How can I read the output of my cron jobs?

The typical way this is done is to use the redirection operators that are a part of sh - the default shell used in cron. Using your cron job as an example, this is how it's done:

* * * * * /home/pi/Projects/test-cron.sh >> /home/pi/Projects/test-cron.log 2>&1

Let's break this down:

1. >> /home/pi/Projects/test-cron.log redirects the output of your script to the named file (it can be any name you choose). >> is the append form of the redirect - meaning that each time it writes to the file, a line is added; i.e. your file will grow large over time. You can also use the overwrite form of the redirect: >. In this case, your file will only contain the last line that was redirected to it.

2. 2>&1 is also a form of redirect - it causes the stderr (2) output to redirect to stdout (1). Yes - the syntax may look strange, but it won't seem strange at all after using it a while. What it does is to combine both types of output from your script (stdout & stderr) so that both wind up in your test-cron.log file.

You may find this a bit easier than dealing with a mail client, and/or revising permissions on MTA servers with potentially unintended consequences.

REFERENCE 1. From man 5 crontab:

If MAILTO is defined (and non-empty), mail is sent to the user so named. MAILTO may also be used to direct mail to multiple recipients by separating recipient users with a comma. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the owner of the crontab.