4

On a new Ubuntu install, a user's PATH is:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

But in that same user's cron environment, it is:

/usr/bin:/bin

I looked at all the user's dot files in the home directory, nothing in there is changing the PATH.

What's changing the PATH? Why doesn't cron use that PATH?

1
  • you can do in this way "grep PATH /etc/crontab"
    – c4f4t0r
    Jun 12, 2015 at 13:02

2 Answers 2

3

Regarding the question - why is this so - the manual page that explains it is crontab(5), IOW the one accessible through man 5 crontab (not the default one in section 1). The cron daemon does not try to emulate a shell session, rather it sets up a clean, minimal environment for the cron jobs to run in, and then in turn allows the crontab file to set its own arbitrary environment variables. The newer cron daemon shipped with Debian also has several additional provisions for pam_env etc.

2
  • I wonder why /usr/local isn't considered clean and minimal whenin the crontab of a unprivileged user. Jun 12, 2015 at 16:38
  • 1
    There is no real global default PATH on Unix systems - each user can and does have their own in their own shell settings, which are in arbitrary files that the cron daemon doesn't know about. Granted, /usr/local/bin is in FHS, pathname.com/fhs/2.2/fhs-4.9.html but I'm guessing the more conservative option (without it) is used for backwards compatibility. A related example is how RHEL/CentOS systems omit /usr/local/lib from the default library path, unlike Debian/Ubuntu systems which include it (through the required libc-bin package). Jun 12, 2015 at 16:44
3

Cron does not execute processes in a login shell. Because of this, all the typical scripts are not sourced when a process is executed.

Executing the process from within a login shell should replicate the user's environment.

Put something like this in a crontab and compare the two outputs:

*/1 * * * * /usr/bin/env > /tmp/env                                             
*/1 * * * * /usr/bin/bash -l -c /usr/bin/env > /tmp/bashenv  

As you can see, /tmp/bashenv will have a whole slew of environment variables that /tmp/env does not. This is because env was invoked in a login shell using bash -l.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .