crontab entry environment variables [PSARC/2007/503 FastTrack timeo

[Chris Gerhard]

Don Cragun wrote:
>> Date: Mon, 10 Sep 2007 10:23:52 +0100
>> From: Darren J Moffat <Darren.Moffat at sun.com>
>>
>> Don Cragun wrote:
>>> Darren,
>>> 	The concern is that it is not unusual for 3rd party applications
>>> to install crontab entries to perform periodic maintenance on log files,
>>> databases, etc. during off-peak hours.  If someone installs one of these
>>> applications that uses a shared crontab file (e.g., root) after putting
>>> an entry in that shared crontab file that shifts the timezone, this
>>> stuff may start running during peak hours.  I believe the man pages and
>>> release notes should warn people who install software.  The warning
>>> needs to specify that that crontab files may need to be manually
>>> editted if software installation adds crontab tntries to any shared
>>> crontab files if crontab timezone shifting is enabled.
>> Am I correct in my reading of this that you do not object to the feature 
>> as proposed but instead are just recommending clear documentation in the 
>> man pages ?   Exactly what isn't clear about the proposed man pages ? 
>> Do you feel you need to see final wording for this case to complete and 
>> be marked as approved ?
> 
> Darren,
> I do not object to the feature in concept as long as the man pages are
> clear.  When I submitted my first comment there were no man pages in
> the materials directory (in fact there was no materials directory).
> 
> The man pages currently in the materials directory have a few problems
> including, but not necessarily limited to, the following:
>  1.  There is nothing in cron.1m nor in crontab.1 warning users that
>      they should not use the HOME, SHELL, or TZ variables in crontab
>      files that contain entries installed by more than one user or
>      application.

I'm not entirely sure there should be.  The issue is that the crontab 
files are read from top to bottom and so the last set of settings above 
the entry take effect.  If there is a warning then is should only say 
care should be taken.


> 
>  2.  The cron.1m man page says this extension is enabled by setting
>      ALLOW_EXTENSIONS=YES in /etc/default/cron.  The crontab.1 man page
>      says this extension is enabled by setting:
> 		ALLOW_EXTENSIONS="1  \"YES\""
>      in /etc/default/cron.  I assume the latter is a typo, but that
>      entire paragraph in crontab.1 seems to be missing some words and
>      is referencing only one of many standards that specify the
>      behavior of the crontab utility.  Am I correct in assuming that
>      the intent would be more accurately expressed by changing the
>      current text:
>       ``If        the variable  ALLOW_EXTENSIONS  is  set  to  1  "YES"  in
> 	/etc/default/cron allowed  to have a crontab file that does
> 	not conform to the        UNIX standard.''
>      to something like:
>       ``If ALLOW_EXTENSIONS=YES is present in /etc/default/cron each
> 	user's crontab file is allowed to contain lines setting any of
> 	the variables HOME, PATH, SHELL, and TZ in addition to the
> 	comments, standard crontab entries, and command input described
> 	on the rest of this page.''
>      The other reference on the crontab.1 man page to "the UNIX
>      standard" also needs to be changed.  The behavior of crontab is
>      specified in XPG3, XPG4, POSIX.2-1992, POSIX.1-2001, SVID3, the
>      System V ABI, and the SCD as well as SUS, SUSv2, and SUSv3.  I
>      would suggest changing:
>       ``The rest of the lines in the crontab file are comments,
> 	crontab entries, and command input as described in the rest of
> 	this man page.''

that would indeed more accurately express it if we keep the knob.

> 
>  3.  If I have read the man pages correctly, HOME and PATH can be set
>      in /etc/default/cron only, SHELL can be set in crontab files only,
>      and TZ can only be set in /etc/default/init and in crontab files
>      only.  Why can't HOME and PATH be set in crontab files?  If one of
>      these variables is set in more than one location, it isn't really
>      clear which one wins.  I assume that the intent is that for any
>      variable specified to be settable in a more than one of the
>      following:
> 	A. crontab file
> 	B. /etc/default/cron
> 	C. /etc/default/init
>      then a setting in the first one in the list specified to allow
>      settings for that variable determines the value.

HOME, SHELL & TZ can be set in crontab files.  The reason for limiting 
it to those three variables is that all the other settings can be 
achieved in a script run from the crontab line. I would agree that 
allowing shell here is a bit weak since you can just exec another shell.

> 
>  4.  The section in the crontab.1 man page titled "Setting
>      cron Jobs Across Timezones" is not clear as to whether setting TZ
>      in a crontab file overrides setting TZ in /etc/default/init nor
>      whether

O.k. It does. The last TZ setting prior to the cron entry is the one in 
effect.

> 
>  5.  The crontab.1 man page says that the shell is invoked with an arg0
>      of sh no matter what shell is specified by SHELL.  Is this really
>      what is intended?

No. It would have arg0 as the basename of SHELL>

> 
>  6.  The current crontab.1 man page (and the crontab.1 man page after
>      your updates) say that PATH in the environment of crontab is only
>      used to find the location of the default vi.  Shouldn't this
>      instead say that PATH in crontab's environment (not PATH from
>      /etc/default/cron) is used to find the editor used to edit the
>      crontab file no matter whether the editor name is the default,
>      the editor specified by $VISUAL (for /usr/bin/crontab), or the
>      editor specified by $EDITOR (for /usr/bin/crontab and
>      /usr/xpg?/bin/crontab).

quite probably but is not really part of this case.

> 
> 
>> Also do you believe that a configuration knob for this functionality is 
>> necessary to standards reasons ?  I believe the project team and other 
>> arc members (myself included) would rather not have configuration of 
>> this at all and just have it always enabled.
> 
> As long as both the cron and crontab man pages warn that none of these
> extensions should be used in any shared crontab files (a crontab file
> in which more than one user or application makes entries), I see no
> need for a configuration knob.  I think it would also be appropriate to
> add a release note warning people about this issue and referring them
> to the updated man pages.

I would prefer to not have the knob.

--chris