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

[Chris Gerhard]

Don Cragun wrote:

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

Actually that is not true.  cron changes directory to HOME prior to 
running the command, so if HOME is unavailable, due to the NFS server 
using a form of secure NFS the job does not run.

As I said SHELL is the weakest of these since you can run a script using 
your preferred shell so it is only the line on the cron entry that is 
effected by it. If the request is to reduce this to only what is 
absolutely required by cron I would not have a problem with not 
supporting SHELL.

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

o.k.



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

I've not said I won't, but this is none the less not part of the 
proposal. That is just a documentation bug.


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

O.k. I should have said if the knob is not required then I would prefer 
not to have it. If it is required, and I am still not convinced it is, 
then a knob there will have to be.

I'm not convinced it is useful as all that will in reality happen is 
that users using this will just set the knob so the standards conforming 
applications still fail.  Even with the singleton approach advocated by 
John this assumes your application adds it's cron entries to the end of 
the file, while this is a reasonable assumption it may not always be 
true. If the assumption is true then adding the lines:

TZ=GB-Eire
SHELL=/bin/sh
HOME=/

To the end of roots crontab in the UK would also suffice to make a 
standards complying application that appends to the crontab file using 
crontab -e happy for root. The same approach would work for any user 
without introducing a knob.

--chris