[SUMMARY] Brain-dead question about shells and cron jobs

From: Michael Steeves [ext 364] (msteeves@applix.com)
Date: Fri May 21 1999 - 10:19:42 CDT

Thanks to all who replied to my mail on this:
Robert Lau <rslau@usc.edu>
David L. Markowitz <David.Markowitz@litronic.com>
Rik Schneider <rik@netasset.com>
Jaewan Kim <jaewan@u1.net>
Danny Johnson <djohnson@nbserv1.rsc.raytheon.com>
Yura Pismerov <yura@base4.com>
David Massey <dmassey@e-one.com>
Ralph Finch <rfinch@dop.water.ca.gov>
Reichert, Alan <aareichert@tasc.com>
Drew Watson <dwatson@ns.encore.com>
Matthew Stier <Matthew.Stier@tddny.fujitsu.com>
James Ford <jford@tusc.net>
Mark Noel <Mark_Noel@cch.com>
Salehi, Michael E <Mike.Salehi@usa.xerox.com>

The answer for this issue is:
> crontab stuff runs as sh. It doesn't look for the users environment
> at all ( as I have lately learned to my chagrin ). You have to
> deliberately source the users environment if you need to use something
> from it.
> You can use an /etc/default/cron file to set defaults, but I've never
> used it.
> man pages do an OK job of explaining this, but it's near the bottom.

Checking the man page for crontab(1), I do see towards the bottom of
the page the following:
     The shell is invoked from your $HOME directory with an arg0
     of sh. Users who desire to have their .profile executed
     must explicitly do so in the crontab file. cron supplies a
     default environment for every shell, defining HOME, LOGNAME,
     SHELL(=/bin/sh), TZ, and PATH. The default PATH for user
     cron jobs is /usr/bin; while root cron jobs default to
     /usr/sbin:/usr/bin. The default PATH can be set in
     /etc/default/cron; see cron(1M).

One other warning I got was:
> You didn't say what OS you're running. Under Solaris 2.6, cron jobs
> won't run if the user's shell does not appear in /etc/shells.

Other suggestions included:
o Changing the passwd field containing the actual user account password
   to something that would disable logins (like *, or a 14-character entry),
   which we do automatically when someone leaves the company
o Migrate the cron jobs to a generic admin account, or an account that
   will never change/leave (like root, lp, or some other generic system
   level account), which we do as we come across the jobs. Unfortunately,
   we don't have the time to spend checking out each system, and instead
   have to check out things as we get a chance between various crises....

My original question was:
> This is kind of a brain-dead question, but I was wondering if there
> would be any problem with cron jobs running properly if I changed a
> user's shell to something like /bin/false. We've got a few admins
> that have since left our employ, but there are still the odd jobs
> that are running from cron that we don't want to break, so changing
> the /etc/passwd shell to /bin/false may allow us to disable the account
> for login purposes (such as the use of 'su'), but not break cron jobs
> and the like.

Again, thanks to all that replied to this.


Michael Steeves, System and Network Administrator (msteeves@applix.com)
"I've got to start listening to those quiet, nagging doubts."
    -- Calvin and Hobbes

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:20 CDT