Why are cron jobs not being logged by rsyslog on Debian 10 buster?

Question

(I figured this out, it was multiple problems...I'm leaving this as is and explain the process I took to resolve in my answer to this question)

I'm working on a simple Ruby script that runs as a cron job. I'm using Visual Studio Code and the Remote-Containers extension which makes it easy to spin up a Ruby dev environment which runs in a Docker container.

This Docker container is running Debian 10 (Buster). I have tested the script and it runs okay:

sudo /usr/local/bin/ruby /workspaces/main.rb

I've used crontab -e to add the cron jobs:

* * * * * /usr/local/bin/ruby /workspaces/main.rb
* * * * *  sleep 30; /usr/local/bin/ruby /workspaces/main.rb

At first there wasn't any syslog at all. So I installed rsyslog and logs started going into /var/log/syslog but there were only a few. Those relating to cron where all about edits I was making with crontab:

May 21 14:29:56 cec3901197dc crontab[3347]: (vscode) LIST (vscode)
May 21 14:30:00 cec3901197dc crontab[3362]: (vscode) BEGIN EDIT (vscode)

I edited /etc/rsyslog.conf and changed:

#cron.* /var/log/cron.log

to:

cron.* /var/log/cron.log

I then killed and restarted the rsyslogd process:

sudo kill -9 3056
sudo rsyslogd

I can send a test message to the syslog and see it is running:

logger test

Looking at /var/log/syslog I see the appropriate log entry has been added:

May 21 15:50:29 cec3901197dc vscode: test

I can also see that rsyslog is successfully writing crontab log entries to /var/log/cron.log:

May 21 15:44:15 cec3901197dc crontab[16490]: (vscode) BEGIN EDIT (vscode)
May 21 15:46:27 cec3901197dc crontab[16490]: (vscode) END EDIT (vscode)

But I'm only seeing these sort of crontab entries, nothing about the cron jobs executing. I'm guessing my jobs may be configured incorrectly...and I've tried a few different variations with none providing any log entries.

Still, even if they are configured incorrectly shouldn't cron still log the errors they produce to cron.log?

Is there something else I need to get more verbose messages from cron? Or is there something I can change about the commands that will provide more verbose messages?

Update - 5/21/21

I tried this on my local Ubuntu install. I had to login as root using sudo -i and add to the root's crontab. This worked - I began seeing the logs in my /var/log/ folder.

However, using root on my VSC container didn't work. Based on comparing the logging from my local Ubuntu and the VSC instance I suspect the issue is that syslog is now working fine and the issue is that the cron scheduler isn't actually running...that's why only crontab related entries are showing up in the syslog.

Why isn't cron running?

Answer: The Docker container doesn't start cron by default. Running cron from the prompt will start it running and it will begin logging correctly to /var/log/cron.log.

However, even with the cron job executing it still isn't creating the appropriate current_users or user_changes files at /var/log/.

Configuration Status Now

1. Still using VSC Remote Containers Ruby Docker container.
2. Installed and started rsyslogd.
3. Edit /etc/rsyslog.conf to redirect cron related logging to cron.log (from main syslog)
4. Kill and restart rsyslogd to ensure latest conf is picked up.
5. Use sudo -i to access root.
6. As root add crontab jobs using crontab -e:

* * * * * ruby /workspaces/main.rb
* * * * * sleep 30; ruby /workspaces/main.rb

1. Check that cron is actually running the jobs in cron.log:

May 21 18:41:01 cec3901197dc CRON[45188]: (root) CMD (sleep 30; ruby /workspaces/main.rb)
May 21 18:41:01 cec3901197dc CRON[45190]: (root) CMD (ruby /workspaces/main.rb)

1. Check to see if current_users or user_changes has been updated, nope.
2. Check that script can run correctly at command prompt ruby /workspaces/main.rb. Yup, runs just fine. Creates appropriate files.

So now I'm really confuzzled. The cron job is running the ruby script but it is not creating the files. I can run the ruby script myself and it does create the files. What gives?

Answer 1

This was one of those problems in which there were multiple issues preventing the cron job from running successfully. As I resolved one problem I found another and another...

Problems 1-3: Running a Visual Studio Code Remote-Containers Pre-Built Docker Container

I love VSC Remote-Containers. They make it so easy to spin up a dev environment on your local machine and the editing experience is seamless...except sometimes, like this instance.

I (wrongly) expected my dev env to act essentially like a normal Linux box - but I was mistaken. Some things get stripped out when running Docker containers and need to be added back in...if they aren't the environment experience isn't identical. That is what happened in this case - rsyslog was not installed and cron was not running.

To fix these issues I did the following:

1. Installed rsyslog: sudo apt install rsyslog
2. Edited /etc/rsyslog.conf so that cron related jobs where saved to /var/log/cron.log (this wasn't absolutely essential, but made parsing the logs easier).
3. Killed rsyslog: sudo kill -9 3056 (you'll need to check for the appropriate pid, easy way is using ps aux | grep rsyslog
4. Started rsyslog: sudo rsyslog (why did I kill and restart? so latest config was picked up)
5. Started cron: cron

Problem 4: Not Running cron Jobs As Root

I initially attempted to run the cron job using the default user (vscode, and then sudo for running the command). But this wouldn't work. I'm sure there is probably a way to get it work (and I'd love to hear it) but I used root: sudo -i

Once under the root account I could add the jobs using crontab -e

Problem 5: Not including the full path to Ruby

On my local Ubuntu machine creating a job below worked fine:

* * * * * ruby /workspaces/main.rb`
* * * * * sleep 30; ruby /workspaces/main.rb`

But in the VSC Debian 10 container it didn't work. So I made the path to Ruby absolute:

* * * * * /usr/local/bin/ruby /workspaces/main.rb
* * * * * sleep 30; /usr/local/bin/ruby /workspaces/main.rb

Once I made this change things began working.