0

I've added a job to root's crontab

# crontab -l | tail -n 1
*/3,13,29,43 * * * * /root/bin/check_network.sh
#

However, it appears to be running as my normal user, rwb.

The rwb account (not the root account) is getting mail about the job failing, and it's failing because

/root/bin/check_network.sh: line 26: iw: command not found

But of course iw is at /use/sbin/iw wchich is on root's $PATH but not rwb's.

What's going on?! How can I run my root cron job?

Update

Changingthe command from iw to /usr/sbin/iw seems to have got it working, so there must be some difference in the $PATH when cron is running compared to a normal bash window.

Richard Barraclough
  • 405
  • 1
  • 5
  • 22
  • 2
    First thing I can think of is that your script is dropping privileges, you probably want to paste it. The fact that it knows about `iw` in the error means that the script has been started, and because it's in `/root` it certainly started with root privileges. – Garo Jun 24 '21 at 08:16
  • 1
    is root aliased to rwb in /etc/aliases? it's a pretty common practice for root's mail to be set to their fist non-system user. check with `grep root /etc/aliases`. Also, check the headers of the mail, particularly headers like `To:` and `Delivered-To:`. – cas Jun 24 '21 at 08:52
  • Yes I have `root:rwb` in `/etc/aliases` which explains why `root`'s mail is going to `rwb`. Ta :) – Richard Barraclough Jun 24 '21 at 08:56
  • OK, that means the cron job is running as root, which also means that the problem is a PATH issue. Remember that the PATH in cron is not necessarily the same as PATH in a login shell. – cas Jun 24 '21 at 08:57
  • 2
    Does this answer your question? [How does cron set the environment variables in /etc/cron.d/\* and /etc/cron.d/?](https://unix.stackexchange.com/questions/479522/how-does-cron-set-the-environment-variables-in-etc-cron-d-and-etc-cron-d) – cas Jun 24 '21 at 09:00

2 Answers2

1

Did you use su to become root when setting up that crontab?

On Debian 10, man crontab says:

Note that su(8) can confuse crontab and that if you are running inside of su(8) you should always use the -u option for safety's sake.

In Debian 10 release, Debian abandoned the old su command from the shadow-utils codebase, and moved into su from the util-linux codebase. This caused a number of subtle changes.

The default set-up of Debian 10 allows multiple people to have root access and still have their own personal preferences take effect while using root privileges if they wish. But as a consequence, using just su or sudo -s will result in an incomplete change of environment variables: for example, after transitioning from rwb to root with a plain su, the USER environment variable will still have a value of rwb. This variable is what some programs and scripts use to identify the user.

So if you go to /var/spool/cron/crontabs and look at the files in there, I bet you'll find your cron job definition is actually in /var/spool/cron/crontabs/rwb, not in /var/spool/cron/crontabs/root. Effectively, you still edited your own personal crontab file, not root's.

If you want to "fully become root", with a complete re-initialization of environment variables, you'll need to use su - or sudo -i.

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • In `/var/spool/cron/crontabs` there are two files: `root` and `rwb` and each of these is identical to the output of `crontab -l` when run as the respective users. – Richard Barraclough Jun 24 '21 at 09:35
0

It seems you have an issue with the environment; specifically the $PATH environment variable in cron. I mess about with 2-3 different distros (mostly Debian), and the environment is not always the same. I use a little trick to get cron to tell me what it's environment is:

Add the following line (or similar) to your crontab:
@reboot /usr/bin/printenv > /home/my/cronenv.txt 2>&1
Compare that against the environment reported from your interactive shell (bash in this case):
pi@4b:~ $ printenv

As you'll likely see, there are substantial diffs between the two environments. There are various solutions for modifying the environment for cron, but for my purposes I find that simply making a habit of calling out the full path to an executable/command eliminates the need for most changes to the cron environment.

WRT root's crontab, it is not the same as your user's crontab:
pi@4b:~ $ sudo crontab -e

This gets you the root crontab that is substantially different from your user crontab. As before, you can run the printenv in the root crontab to examine the diffs in environments. When you need elevated privileges in a cron job, this is the way to go.

Know that this may be handled differently on some systems, but on my Debian-based systems it works well AFAIC. You need not enter sudo for privilege elevation in the root crontab since you are running the cron job/script as root.

Seamus
  • 2,522
  • 1
  • 16
  • 31