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

[Don Cragun]

>Date: Wed, 12 Sep 2007 19:16:19 +0100
>From: Chris Gerhard <chris at thegerhards.com>
>
>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.

OK.  Now we're back to a standards conformance problem.

If you want to inflict unrequested changes in behavior on strictly
conforming POSIX applications that use crontab -e to add crontab
entries to the end of a crontab file; then you need a knob that enables
this extension only on individual crontab files at the request of the
owner of that crontab file.

Alternatively, you could take John's suggestion and STRONGLY suggest
that the only pragma to be used in shared crontab files is:
#pragma envvariables=singleton
You may remember that I had requested that all of these entries in
crontab files only affect the next crontab entry long, long ago when we
started this discussion.  As long as setting variables doesn't affect
subsequent jobs, there is no standards conformance issue for well
formed crontab files.

>
>
>> 
>>  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.

This makes little sense to me.  HOME, SHELL, and TZ can all be set on
each script line in a crontab file.  The only thing that can't be done
on the command lines is use different TZ settings to control when a
cron job will be started.  But the important point is that your man
pages do not say what happens when these variables (except TZ) are set
in more than one of the current crontab file, /etc/default/cron, and
/etc/default/init.  Your documentation says that SHELL will be set to
/bin/sh in the environment of commands started from the crontab file no
matter what how SHELL is set in the crontab file.  You man page says
SHELL in a crontab file specifies the command interpreter that will be
invoked, but will not affect the environment.  I don't believe this is
what you intend to happen.  If this is not what you want to happen, you
need to fix the man pages.

>
>> 
>>  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>

Then please fix the man page.

>
>> 
>>  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.

I had hoped that you would be willing to fix the man page to correctly
describe the environment used and set up by cron and crontab as part of
your changes to the way cron and crontab handle the environment.

>
>> 
>> 
>>> 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.

Good.  Then please update the way cron and crontab behave such that
standards conforming applications (that are unaware of your extensions)
are not broken by your extensions.

 - Don

>
>--chris