3

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?

  • you can do in this way "grep PATH /etc/crontab" – c4f4t0r Jun 12 '15 at 13:02
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.

  • I wonder why /usr/local isn't considered clean and minimal whenin the crontab of a unprivileged user. – John Bachir Jun 12 '15 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). – Josip Rodin Jun 12 '15 at 16:44
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.