From darrenm@sac.sfbay.sun.com Mon Sep 3 06:28:15 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l83DSFgl016505 for ; Mon, 3 Sep 2007 06:28:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l83DPWad021809; Mon, 3 Sep 2007 06:25:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNS00K2CNYKN600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 03 Sep 2007 06:25:32 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNS00FOLNYHE850@nwk-avmta-1.sfbay.Sun.COM>; Mon, 03 Sep 2007 06:25:30 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l83DPT9N009109; Mon, 03 Sep 2007 06:25:29 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l83DSA15016500; Mon, 03 Sep 2007 06:28:10 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l83DS9oV016496; Mon, 03 Sep 2007 06:28:09 -0700 (PDT) Date: Mon, 03 Sep 2007 06:28:09 -0700 (PDT) From: Darren J Moffat Subject: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] To: PSARC-ext@sun.com Cc: chris@thegerhards.com Message-id: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2927 I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible standards impact but I believe based on previous discussions this should be acceptable, if it wasn't for the standards impact this would likely have been self-review. Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: crontab entry environment variables 1.2. Name of Document Author/Supplier: Author: Chris Gerhard 1.3 Date of This Document: 03 September, 2007 4. Technical Description This project proposes support for and use of TZ, SHELL and HOME variables as per crontab(4) entry varaiables, these are the only ones that change the way cron behaves. All others can be achieved via having the entry set the variable (SHELL is the weakest of the three to change as it only saves on exec). HOME solves the problems associated with NFS and cronjobs where a users home directory is not available when the entry runs (as in the case with secure NFS). TZ obviously sets the time zone when the entry is valid. Allowing jobs to run in any time zone. The variables continue to effect all entries below them until new entries are listed in the file. Entries would run with a HOME directory set to the one listed and at times that are correct according to the TZ value and with a shell specified by SHELL. Setting any other variable results in an error when you try and save the crontab file. Use of this facility is controlled by an entry in the already existing /etc/default/cron [ the project team is aware that ideally this and the existing cron(1M) use of this file should migrate to SMF properties but that is not this case ]. If there is an entry of the form: ALLOW_EXTENSIONS=YES in the file then the entries are allowed otherwise cron and crontab behave as it do now and crontab will not let you add the lines and cron will not process them, instead treating them as errors. The one problem area would be if an Admin removed the entry from /etc/default/cron while there were crontab files that contained those entries. When cron was restarted all the lines would be reported as in error and potentially cron jobs could run at the wrong times with the wrong shell and wrong HOME directory. OpenSolaris distributions would decide whether they wish to allow the extensions or not by default and provide an /etc/default/cron with ALLOW_EXTENSIONS set to YES or NO depending on that decision. This case declares the default for the Solaris distribution to be YES. All the functionality defined in this case is exported as Committed interfaces with a release binding of patch. Updated man pages are in the materials directory. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From dwc@spartan.eng.sun.com Mon Sep 3 11:34:35 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l83IYZCi019959 for ; Mon, 3 Sep 2007 11:34:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l83IVq01008320 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Sep 2007 11:31:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNT004012549300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Sep 2007 11:31:52 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNT00JSD254FBD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Sep 2007 11:31:52 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l83IVqPm003618; Mon, 03 Sep 2007 11:31:52 -0700 (PDT) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l83IVpQI003617; Mon, 03 Sep 2007 11:31:51 -0700 (PDT) Date: Mon, 03 Sep 2007 11:31:51 -0700 (PDT) From: Don Cragun Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] To: PSARC-ext@sun.com, darrenm@sac.sfbay.sun.com Cc: chris@thegerhards.com Message-id: <200709031831.l83IVpQI003617@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 386 >Date: Mon, 03 Sep 2007 06:28:09 -0700 (PDT) >From: Darren J Moffat > >Updated man pages are in the materials directory. > Darren, When is the materials directory going to be created and populated? Given the abnormal effects this can have on third party code, I want to see the rationale and application usage sections of these man pages... Cheers, Don From jek3@sun.com Tue Sep 4 14:36:51 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l84LapaR025738 for ; Tue, 4 Sep 2007 14:36:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l84LY41n021984 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 Sep 2007 14:34:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNV00M0X58SU200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Sep 2007 15:34:04 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNV00HUA58RXH50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Sep 2007 15:34:03 -0600 (MDT) Received: from [129.150.12.124] (vpn-129-150-12-124.SFBay.Sun.COM [129.150.12.124]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l84LY1LU451614; Tue, 04 Sep 2007 14:34:01 -0700 (PDT) Date: Tue, 04 Sep 2007 11:30:25 -1000 From: Joseph Kowalski Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] In-reply-to: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com, chris@thegerhards.com Message-id: <46DDCE71.8040806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 433 Darren J Moffat wrote: > I'm sponsoring this OpenSolaris case for Chris Gerhard. Nit/Opinion... > ALLOW_EXTENSIONS=YES > How about a definition that is a little more explicit? Maybe something like: ALLOW_ENV=YES I can't say I love this, but "EXTENSIONS" seems rather broad. I could envision there being several classes of extensions, and it might be desirable to control them (as small classes) individually. - jek3 From Darren.Moffat@Sun.COM Wed Sep 5 03:19:28 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l85AJSLn011848 for ; Wed, 5 Sep 2007 03:19:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l85AGWLV018092; Wed, 5 Sep 2007 11:16:40 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNW00M0J4JQZK00@brm-avmta-1.central.sun.com>; Wed, 05 Sep 2007 04:16:38 -0600 (MDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNW00CKF4JOP390@brm-avmta-1.central.sun.com>; Wed, 05 Sep 2007 04:16:37 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l85AGakR005356; Wed, 05 Sep 2007 10:16:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JNW0020145VAM00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 05 Sep 2007 11:16:36 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JNW00H7U4JMM510@fe-emea-10.sun.com>; Wed, 05 Sep 2007 11:16:35 +0100 (BST) Date: Wed, 05 Sep 2007 11:16:34 +0100 From: Darren J Moffat Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] In-reply-to: <200709031831.l83IVpQI003617@spartan.SFBay.Sun.COM> Sender: Darren.Moffat@Sun.COM To: Don Cragun Cc: PSARC-ext@Sun.COM, chris@thegerhards.com Message-id: <46DE8202.9030703@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709031831.l83IVpQI003617@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 296 Don Cragun wrote: >> Date: Mon, 03 Sep 2007 06:28:09 -0700 (PDT) >> From: Darren J Moffat >> >> Updated man pages are in the materials directory. >> > Darren, > When is the materials directory going to be created and > populated? Available now. -- Darren J Moffat From Darren.Moffat@sun.com Wed Sep 5 03:20:05 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l85AK5hF011862 for ; Wed, 5 Sep 2007 03:20:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l85AH429017127; Wed, 5 Sep 2007 03:17:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNW00B574KONM00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Sep 2007 03:17:12 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNW009824GI3X00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Sep 2007 03:14:43 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l85ADrOB018343; Wed, 05 Sep 2007 10:13:53 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JNW0020145VAM00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 05 Sep 2007 11:13:53 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JNW00H7B4F1M510@fe-emea-10.sun.com>; Wed, 05 Sep 2007 11:13:50 +0100 (BST) Date: Wed, 05 Sep 2007 11:13:49 +0100 From: Darren J Moffat Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] In-reply-to: <200709031831.l83IVpQI003617@spartan.SFBay.Sun.COM> Sender: Darren.Moffat@sun.com To: Don Cragun Cc: PSARC-ext@sun.com, darrenm@sac.sfbay.sun.com, chris@thegerhards.com Message-id: <46DE815D.50706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709031831.l83IVpQI003617@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 862 Don Cragun wrote: >> Date: Mon, 03 Sep 2007 06:28:09 -0700 (PDT) >> From: Darren J Moffat >> >> Updated man pages are in the materials directory. >> > Darren, > When is the materials directory going to be created and > populated? Given the abnormal effects this can have on third party > code, I want to see the rationale and application usage sections of > these man pages... Can you explain exactly how you think that third party code could be impacted by this. These variables are NOT set by default unless a user explicitly chooses to set them. Even third party code that adds entries to end user crontab's isn't likely to be impacted by this as I see it unless the user has explicitly added these new variables before the third party code updates the users crontab file or they do so afterwards. -- Darren J Moffat From cjg@thegerhards.com Wed Sep 5 14:45:27 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l85LjQC8004316 for ; Wed, 5 Sep 2007 14:45:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l85LgZ7t001045; Thu, 6 Sep 2007 05:42:38 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNX0010Z0AYFI00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Sep 2007 14:42:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNX00L2H0AWJX30@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Sep 2007 14:42:32 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l85LXHm6018182; Wed, 05 Sep 2007 21:42:32 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay14i.sun.com with ESMTP id BT-MMP-194969; Wed, 05 Sep 2007 21:42:32 +0000 (Z) Received: from relay17i.sun.com (relay17i.sun.com [129.179.4.127]) by mmp11es.sun.com with ESMTP id BT-MMP-525040; Wed, 05 Sep 2007 21:42:31 +0000 (Z) Received: from cdmnet.org ([62.24.230.83] [62.24.230.83]) by relay1ib.sun.com with ESMTP id BT-MMP-812146; Wed, 05 Sep 2007 21:42:31 +0000 (Z) Received: from host86-136-111-85.range86-136.btcentralplus.com ([86.136.111.85]:62579 helo=thegerhards.com) by cdmnet.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IT2do-0002uH-Ut; Wed, 05 Sep 2007 22:42:29 +0100 Received: from gmp-ea-fw-1.sun.com ([192.18.1.36] helo=[129.156.173.21]) by thegerhards.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1IT2dg-0003L7-95; Wed, 05 Sep 2007 21:42:20 +0000 Date: Wed, 05 Sep 2007 22:42:05 +0100 From: Chris Gerhard Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] In-reply-to: <46DDCE71.8040806@sun.com> Sender: cjg@thegerhards.com To: Joseph Kowalski Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <46DF22AD.3080909@thegerhards.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Spam_score: -101.0 X-Spam_score_int: -1009 X-Spam_bar: --------------------------------------------------- X-Spam_report: Spam detection software, running on the system "pearson.thegerhards.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see Postmaster for details. Content preview: Joseph Kowalski wrote: > Darren J Moffat wrote: >> I'm sponsoring this OpenSolaris case for Chris Gerhard. > Nit/Opinion... >> ALLOW_EXTENSIONS=YES >> > How about a definition that is a little more explicit? Maybe something > like: > > ALLOW_ENV=YES > > I can't say I love this, but "EXTENSIONS" seems rather broad. I could > envision there being several classes of extensions, and it might be > desirable to > control them (as small classes) individually. > [...] Content analysis details: (-101.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.5 AWL AWL: From: address is in the auto white-list References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> <46DDCE71.8040806@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 915 Joseph Kowalski wrote: > Darren J Moffat wrote: >> I'm sponsoring this OpenSolaris case for Chris Gerhard. > Nit/Opinion... >> ALLOW_EXTENSIONS=YES >> > How about a definition that is a little more explicit? Maybe something > like: > > ALLOW_ENV=YES > > I can't say I love this, but "EXTENSIONS" seems rather broad. I could > envision there being several classes of extensions, and it might be > desirable to > control them (as small classes) individually. > My thinking was that this option allows cron to be extended beyond the standard as it is currently written. If further extensions were proposed then at that time it would be possible to have ALLOW_EXTENSIONS=YES be a big switch with individual variables as smaller switches if at the time that was considered important. So if ALLOW_EXTENSIONS is not YES you get a standard conforming cron no matter what other settings are. --chris From sommerfeld@sun.com Wed Sep 5 15:38:02 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l85Mc1Lb005614 for ; Wed, 5 Sep 2007 15:38:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l85MYfNw018179; Wed, 5 Sep 2007 16:34:43 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNX003072QRWM00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Sep 2007 15:35:15 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNX00LZD2QQJV60@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Sep 2007 15:35:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l85MZ86b019742; Wed, 05 Sep 2007 18:35:08 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l85MZ7QI014498; Wed, 05 Sep 2007 18:35:07 -0400 (EDT) Date: Wed, 05 Sep 2007 18:35:06 -0400 From: Bill Sommerfeld Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] In-reply-to: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com, chris@thegerhards.com Message-id: <1189031706.12483.29.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> Status: RO Content-Length: 1743 On Mon, 2007-09-03 at 06:28 -0700, Darren J Moffat wrote: > I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible > standards impact but I believe based on previous discussions this should > be acceptable, if it wasn't for the standards impact this would likely have > been self-review. Might I suggest a minor extension? From a quick glance at a *BSD (Vixie) crontab(5) manpage, I see one piece I could really use: MAILTO. In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it has any reason to send mail as a result of running commands in ``this'' crontab. If MAILTO is defined (and non-empty), mail is sent to the user so named. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Secondly: I think ALLOW_EXTENSIONS is not necessary. This is another case where an extension gives meaning to what was formerly a syntax error. There appears to be extensive implementation experience with this sort of extension on other platforms. In the absence of evidence that there is real crontab-manipulating code out there which will be broken by this extension, I don't think we need the ALLOW_EXTENSIONS knob (except *possibly* as a hedge to enable backport to an older release, and even then I'm skeptical). Rationale: If an application is in complete control of the entire crontab file contents and is unaware of the extension, it won't use it and no problem can result. If an application is not in complete control of the crontab file, then administrators need to take responsibility for the contents and thus need to avoid introducing environment variables which will disrupt application-added crontab entries. - Bill From Darren.Moffat@sun.com Thu Sep 6 02:31:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l869VkRV016398 for ; Thu, 6 Sep 2007 02:31:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l869Sm5d009660; Thu, 6 Sep 2007 10:29:01 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JNX00F13X0A6F00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 02:28:58 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNX00EWEX08OG10@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 Sep 2007 02:28:57 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l869Stla025909; Thu, 06 Sep 2007 09:28:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JNX00D01W92Z800@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 06 Sep 2007 10:28:55 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JNX00LYUX00LS00@fe-emea-10.sun.com>; Thu, 06 Sep 2007 10:28:49 +0100 (BST) Date: Thu, 06 Sep 2007 10:28:48 +0100 From: Darren J Moffat Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] In-reply-to: <1189031706.12483.29.camel@thunk> Sender: Darren.Moffat@sun.com To: Bill Sommerfeld Cc: Darren J Moffat , PSARC-ext@sun.com, chris@thegerhards.com Message-id: <46DFC850.20405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> <1189031706.12483.29.camel@thunk> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 1044 Bill Sommerfeld wrote: > Secondly: I think ALLOW_EXTENSIONS is not necessary. This is another > case where an extension gives meaning to what was formerly a syntax > error. > > There appears to be extensive implementation experience with this sort > of extension on other platforms. In the absence of evidence that there > is real crontab-manipulating code out there which will be broken by this > extension, I don't think we need the ALLOW_EXTENSIONS knob (except > *possibly* as a hedge to enable backport to an older release, and even > then I'm skeptical). I agree with this and I particularly like how your rationale makes the distinction between full crontab file vs single entry. The only reason that I encouraged Chris to put in the knob was "standards fear fud". I think we need Don (or someone else intimate with the standards that cover cron/crontab) to comment on this. In particular do the standards tests actually put "garbage" in the crontab files and check that it fails ? knobless is best. -- Darren J Moffat From dwc@spartan.eng.sun.com Fri Sep 7 16:49:24 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l87NnNfu006536 for ; Fri, 7 Sep 2007 16:49:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l87NjvDT017743; Fri, 7 Sep 2007 17:46:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO000GMUVDMVE00@nwk-avmta-2.sfbay.sun.com>; Fri, 07 Sep 2007 16:46:34 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO000M5MV5IPU70@nwk-avmta-2.sfbay.sun.com>; Fri, 07 Sep 2007 16:41:42 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l87NfgqM008742; Fri, 07 Sep 2007 16:41:42 -0700 (PDT) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l87NfgVa008741; Fri, 07 Sep 2007 16:41:42 -0700 (PDT) Date: Fri, 07 Sep 2007 16:41:42 -0700 (PDT) From: Don Cragun Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo To: Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, chris@thegerhards.com Message-id: <200709072341.l87NfgVa008741@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1855 ut 09/10/2007] >From Darren.Moffat@sun.com Wed Sep 5 03:17:21 2007 > >Don Cragun wrote: >>> Date: Mon, 03 Sep 2007 06:28:09 -0700 (PDT) >>> From: Darren J Moffat >>> >>> Updated man pages are in the materials directory. >>> >> Darren, >> When is the materials directory going to be created and >> populated? Given the abnormal effects this can have on third party >> code, I want to see the rationale and application usage sections of >> these man pages... > >Can you explain exactly how you think that third party code could be >impacted by this. These variables are NOT set by default unless a user >explicitly chooses to set them. Even third party code that adds >entries to end user crontab's isn't likely to be impacted by this as I >see it unless the user has explicitly added these new variables before >the third party code updates the users crontab file or they do so >afterwards. 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. Cheers, Don PS Sorry for the delay in resonding. The available networks both in the hotel I was in and the conference room in which I was meeting were configured in ways that did not allow me to punch into my mail server. From dwc@spartan.eng.sun.com Sun Sep 9 15:43:28 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l89MhSEj006525 for ; Sun, 9 Sep 2007 15:43:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l89MdxtV050207; Sun, 9 Sep 2007 16:39:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO400701HNNZD00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 09 Sep 2007 15:40:35 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO4006KHHNNJ2A0@nwk-avmta-1.sfbay.Sun.COM>; Sun, 09 Sep 2007 15:40:35 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l89MeZsu010381; Sun, 09 Sep 2007 15:40:35 -0700 (PDT) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l89MeYvs010380; Sun, 09 Sep 2007 15:40:34 -0700 (PDT) Date: Sun, 09 Sep 2007 15:40:34 -0700 (PDT) From: Don Cragun Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout 09/10/2007] To: Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, chris@thegerhards.com Message-id: <200709092240.l89MeYvs010380@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1258 >Date: Thu, 06 Sep 2007 10:28:48 +0100 >From: Darren J Moffat > >Bill Sommerfeld wrote: >> Secondly: I think ALLOW_EXTENSIONS is not necessary. This is another >> case where an extension gives meaning to what was formerly a syntax >> error. >> >> There appears to be extensive implementation experience with this sort >> of extension on other platforms. In the absence of evidence that there >> is real crontab-manipulating code out there which will be broken by this >> extension, I don't think we need the ALLOW_EXTENSIONS knob (except >> *possibly* as a hedge to enable backport to an older release, and even >> then I'm skeptical). > >I agree with this and I particularly like how your rationale makes the >distinction between full crontab file vs single entry. > >The only reason that I encouraged Chris to put in the knob was >"standards fear fud". I think we need Don (or someone else intimate >with the standards that cover cron/crontab) to comment on this. In >particular do the standards tests actually put "garbage" in the crontab >files and check that it fails ? No, they don't. My concern is how non-standard extensions in a shared crontab file will affect applications installing crontab entries. - Don From Darren.Moffat@sun.com Mon Sep 10 02:26:56 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8A9Qum8020866 for ; Mon, 10 Sep 2007 02:26:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8A9O2dY022509; Mon, 10 Sep 2007 02:24:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO500G0PBG41800@brm-avmta-1.central.sun.com>; Mon, 10 Sep 2007 03:24:05 -0600 (MDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO500ETBBG28P10@brm-avmta-1.central.sun.com>; Mon, 10 Sep 2007 03:24:03 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l8A9O2xJ019892; Mon, 10 Sep 2007 09:24:02 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JO500N01A7D4G00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 10 Sep 2007 10:24:02 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JO5009UTBFSVO00@fe-emea-09.sun.com>; Mon, 10 Sep 2007 10:23:52 +0100 (BST) Date: Mon, 10 Sep 2007 10:23:52 +0100 From: Darren J Moffat Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo In-reply-to: <200709072341.l87NfgVa008741@spartan.SFBay.Sun.COM> Sender: Darren.Moffat@sun.com To: Don Cragun Cc: PSARC-ext@sun.com, chris@thegerhards.com Message-id: <46E50D28.5050808@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709072341.l87NfgVa008741@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 1330 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 ? 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. -- Darren J Moffat From roland.mainz@nrubsig.org Mon Sep 10 09:34:51 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8AGYoFq028884 for ; Mon, 10 Sep 2007 09:34:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8AGVu4n010574 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 10 Sep 2007 17:32:00 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO500H07V9B0B00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Sep 2007 10:31:59 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO500EX6V9731B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Sep 2007 10:31:59 -0600 (MDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8AGR6HD028812 for ; Mon, 10 Sep 2007 16:31:54 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay16i.sun.com with ESMTP id BT-MMP-593344 for PSARC-ext@sun.com; Mon, 10 Sep 2007 16:31:54 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.sun.com with ESMTP id BT-MMP-61738 for PSARC-ext@sun.com; Mon, 10 Sep 2007 16:31:54 +0000 (Z) Received: from mail-in-06.arcor-online.net ([151.189.21.46] [151.189.21.46]) by relay1i.sun.com with ESMTP id BT-MMP-1003047 for PSARC-ext@sun.com; Mon, 10 Sep 2007 16:31:54 +0000 (Z) Received: from mail-in-04-z2.arcor-online.net (mail-in-04-z2.arcor-online.net [151.189.8.16]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id 759D6356562; Mon, 10 Sep 2007 18:31:53 +0200 (CEST) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-04-z2.arcor-online.net (Postfix) with ESMTP id 53F8AABE0E; Mon, 10 Sep 2007 18:31:53 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-247-110.pools.arcor-ip.net [84.58.247.110]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 18A6636E86A; Mon, 10 Sep 2007 18:31:48 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l8AGVipX002181; Mon, 10 Sep 2007 18:31:45 +0200 (CEST) Date: Mon, 10 Sep 2007 18:31:43 +0200 From: Roland Mainz Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout09/10/2007] Sender: gisburn@jupiterb48.nrubsig.org To: Darren J Moffat Cc: PSARC-ext@Sun.COM, chris@thegerhards.com Message-id: <46E5716F.7B994FB2@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> Status: RO Content-Length: 4020 Darren J Moffat wrote: > > I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible > standards impact but I believe based on previous discussions this should > be acceptable, if it wasn't for the standards impact this would likely have > been self-review. > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > crontab entry environment variables > 1.2. Name of Document Author/Supplier: > Author: Chris Gerhard > 1.3 Date of This Document: > 03 September, 2007 > 4. Technical Description > > This project proposes support for and use of TZ, SHELL and HOME > variables as per crontab(4) entry varaiables, these are the only ones > that change the way cron behaves. All others can be achieved via > having the entry set the variable (SHELL is the weakest of the three to > change as it only saves on exec). > > HOME solves the problems associated with NFS and cronjobs where a users > home directory is not available when the entry runs (as in the case with > secure NFS). > > TZ obviously sets the time zone when the entry is valid. Allowing jobs > to run in any time zone. > > The variables continue to effect all entries below them until new > entries are listed in the file. Entries would run with a HOME directory > set to the one listed and at times that are correct according to the TZ > value and with a shell specified by SHELL. > > Setting any other variable results in an error when you try and save > the crontab file. > > Use of this facility is controlled by an entry in the already existing > /etc/default/cron [ the project team is aware that ideally this and the > existing cron(1M) use of this file should migrate to SMF properties but > that is not this case ]. If there is an entry of the form: > > ALLOW_EXTENSIONS=YES 1. What will happen if new extensions are added ? IMO this should include a version number or something similar to make sure syntax extensions can be added later... 2. I have great concerns about the abuse of the global environment variable namespace - sooner or later this will backfire _badly_ if cron and other applications have slightly different ways to interpret the values. What about the following solution: -- snip -- The following variables are supported ("cron"-specific variable live in a seperate variable "namespace" starting with ".cron." followed by the variable name): ".cron.home": This allows the user to choose and alternative direc- tory for cron to change directory to prior to running the command. For example .cron.home=/var/tmp ".cron.shell": The name of the shell to use to run the commands. Eg: .cron.shell=/usr/bin/ksh ".cron.tz": This allows the user to choose the timezone in which the cron entries are run. This effects both the environment of the command that is run and the timing of the entry. For example to have your entries run using the timezone for Ice- land: .cron.tz=Iceland Variables starting with any other valid variable charatcers than "." are exported to the launched cron session, e.g. TODAYS_MEAL=giraffe will set the variable "TODAYS_MEAL" to the value "giraffe" in the process environment when the cron job is lanuched. The rest of the lines are the same as crontab entries that conform to the UNIX standard. -- snip -- As a side-effect we could define any extra variable name within ".cron." without running into problems with variable name collisions, e.g. the system is extensible (for example ".cron.mailto" could be added later). A precedent for this can be found in ksh93 which uses the ".sh."-namespace to store shell-specific implementation details (like ".sh.version" etc.) outside the normal variables. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From dwc@spartan.eng.sun.com Mon Sep 10 17:58:01 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8B0w0tF011028 for ; Mon, 10 Sep 2007 17:58:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8B0t8p3009195; Tue, 11 Sep 2007 01:55:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO600A05IJW6R00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 10 Sep 2007 17:55:08 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO600KXKIJRYZ90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 10 Sep 2007 17:55:03 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l8B0t3ts012056; Mon, 10 Sep 2007 17:55:03 -0700 (PDT) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l8B0t3j2012055; Mon, 10 Sep 2007 17:55:03 -0700 (PDT) Date: Mon, 10 Sep 2007 17:55:03 -0700 (PDT) From: Don Cragun Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo To: Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, chris@thegerhards.com Message-id: <200709110055.l8B0t3j2012055@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5551 >Date: Mon, 10 Sep 2007 10:23:52 +0100 >From: Darren J Moffat > >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. 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.'' 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. 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 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? 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). > >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. - Don > >-- >Darren J Moffat From cjg@thegerhards.com Tue Sep 11 04:21:32 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BBLVKT020453 for ; Tue, 11 Sep 2007 04:21:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l8BBId5h016356 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Sep 2007 19:18:39 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO700G03BF0PQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Sep 2007 05:18:36 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO700GFGBEYBX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Sep 2007 05:18:35 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8BBF9km015194 for ; Tue, 11 Sep 2007 11:18:34 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-1067594 for PSARC-ext@sun.com; Tue, 11 Sep 2007 11:18:34 +0000 (Z) Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-1787891 for PSARC-ext@sun.com; Tue, 11 Sep 2007 11:18:33 +0000 (Z) Received: from cdmnet.org ([62.24.230.83] [62.24.230.83]) by relay4i.sun.com with ESMTP id BT-MMP-11240492 for PSARC-ext@sun.com; Tue, 11 Sep 2007 11:18:32 +0000 (Z) Received: from host217-42-34-163.range217-42.btcentralplus.com ([217.42.34.163]:53860 helo=thegerhards.com) by cdmnet.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IV3lF-0002f2-6D for PSARC-ext@sun.com; Tue, 11 Sep 2007 12:18:29 +0100 Received: from gmp-ea-fw-1.sun.com ([192.18.1.36] helo=[129.156.173.21]) by thegerhards.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IV3l3-0006Ud-Gw; Tue, 11 Sep 2007 11:18:18 +0000 Date: Tue, 11 Sep 2007 12:18:11 +0100 From: Chris Gerhard Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout09/10/2007] In-reply-to: <46E5716F.7B994FB2@nrubsig.org> Sender: cjg@thegerhards.com To: Roland Mainz Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <46E67973.8030208@thegerhards.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Spam_score: -101.4 X-Spam_score_int: -1013 X-Spam_bar: --------------------------------------------------- X-Spam_report: Spam detection software, running on the system "pearson.thegerhards.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see Postmaster for details. Content preview: Roland Mainz wrote: > Darren J Moffat wrote: >> I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible >> standards impact but I believe based on previous discussions this should >> be acceptable, if it wasn't for the standards impact this would likely have >> been self-review. >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> crontab entry environment variables >> 1.2. Name of Document Author/Supplier: >> Author: Chris Gerhard >> 1.3 Date of This Document: >> 03 September, 2007 >> 4. Technical Description >> >> This project proposes support for and use of TZ, SHELL and HOME >> variables as per crontab(4) entry varaiables, these are the only ones >> that change the way cron behaves. All others can be achieved via >> having the entry set the variable (SHELL is the weakest of the three to >> change as it only saves on exec). >> >> HOME solves the problems associated with NFS and cronjobs where a users >> home directory is not available when the entry runs (as in the case with >> secure NFS). >> >> TZ obviously sets the time zone when the entry is valid. Allowing jobs >> to run in any time zone. >> >> The variables continue to effect all entries below them until new >> entries are listed in the file. Entries would run with a HOME directory >> set to the one listed and at times that are correct according to the TZ >> value and with a shell specified by SHELL. >> >> Setting any other variable results in an error when you try and save >> the crontab file. >> >> Use of this facility is controolled by an entry in the already existing >> /etc/default/cron [ the project team is aware that ideally this and the >> existing cron(1M) use of this file should migrate to SMF properties but >> that is not this case ]. If there is an entry of the form: >> >> ALLOW_EXTENSIONS=YES > > 1. What will happen if new extensions are added ? IMO this should > include a version number or something [...] Content analysis details: (-101.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> <46E5716F.7B994FB2@nrubsig.org> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 3131 Roland Mainz wrote: > Darren J Moffat wrote: >> I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible >> standards impact but I believe based on previous discussions this should >> be acceptable, if it wasn't for the standards impact this would likely have >> been self-review. >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> crontab entry environment variables >> 1.2. Name of Document Author/Supplier: >> Author: Chris Gerhard >> 1.3 Date of This Document: >> 03 September, 2007 >> 4. Technical Description >> >> This project proposes support for and use of TZ, SHELL and HOME >> variables as per crontab(4) entry varaiables, these are the only ones >> that change the way cron behaves. All others can be achieved via >> having the entry set the variable (SHELL is the weakest of the three to >> change as it only saves on exec). >> >> HOME solves the problems associated with NFS and cronjobs where a users >> home directory is not available when the entry runs (as in the case with >> secure NFS). >> >> TZ obviously sets the time zone when the entry is valid. Allowing jobs >> to run in any time zone. >> >> The variables continue to effect all entries below them until new >> entries are listed in the file. Entries would run with a HOME directory >> set to the one listed and at times that are correct according to the TZ >> value and with a shell specified by SHELL. >> >> Setting any other variable results in an error when you try and save >> the crontab file. >> >> Use of this facility is controlled by an entry in the already existing >> /etc/default/cron [ the project team is aware that ideally this and the >> existing cron(1M) use of this file should migrate to SMF properties but >> that is not this case ]. If there is an entry of the form: >> >> ALLOW_EXTENSIONS=YES > > 1. What will happen if new extensions are added ? IMO this should > include a version number or something similar to make sure syntax > extensions can be added later... If the knob stays, which the consensus seems to be that it is not required but if it did then versioning could happen when you have the second set of extensions. > > 2. I have great concerns about the abuse of the global environment > variable namespace - sooner or later this will backfire _badly_ if cron > and other applications have slightly different ways to interpret the > values. It would if they did. However since cron is interpreting all the variables in the way you expect I fail to see how this is an issue. TZ is treated as the timezone. If we went with .cron.tz cron would still have to set TZ to match this otherwise you would have a cron job wiht .cron.tz set to PST but running on a system in UTC would have the job seeing time as UTC while scheduled in PST. HOME and SHELL are also being used in their expected ways and again it would be strange to not propagate those in the environment of the cron job having acted on them. --chris From Darren.Moffat@sun.com Tue Sep 11 04:24:06 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8BBO67C020492 for ; Tue, 11 Sep 2007 04:24:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8BBLFJG013377 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Sep 2007 04:21:15 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO700607BJFFE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Sep 2007 04:21:15 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO700I6EBJEPYA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Sep 2007 04:21:15 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l8BBLDAL011770 for ; Tue, 11 Sep 2007 11:21:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JO700C01BDWU100@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Sep 2007 12:21:13 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JO7008AGBJ99R10@fe-emea-10.sun.com>; Tue, 11 Sep 2007 12:21:10 +0100 (BST) Date: Tue, 11 Sep 2007 12:21:09 +0100 From: Darren J Moffat Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeout09/10/2007] In-reply-to: <46E67973.8030208@thegerhards.com> Sender: Darren.Moffat@sun.com To: Chris Gerhard Cc: Roland Mainz , Darren J Moffat , PSARC-ext@sun.com Message-id: <46E67A25.6040703@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> <46E5716F.7B994FB2@nrubsig.org> <46E67973.8030208@thegerhards.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 404 Chris Gerhard wrote: > HOME and SHELL are also being used in their expected ways and again it > would be strange to not propagate those in the environment of the cron > job having acted on them. Plus I thought the whole point of this case was to ensure that they did get used both for cron AND got propagated into the running job. Otherwise I don't see the point of this case. -- Darren J Moffat From roland.mainz@nrubsig.org Wed Sep 12 09:30:54 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CGUsw5025801 for ; Wed, 12 Sep 2007 09:30:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CGS1qP022383 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Sep 2007 09:28:03 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900K0FKEQ5J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 09:28:02 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO900FHZKEPG980@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 09:28:01 -0700 (PDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8CFhU1o010268 for ; Wed, 12 Sep 2007 16:28:01 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay25i.sun.com with ESMTP id BT-MMP-1326199 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:28:01 +0000 (Z) Received: from relay21.ob.sun.com (relay21.ob.sun.com [192.12.251.24]) by mms24es.sun.com with ESMTP id BT-MMP-281000 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:28:01 +0000 (Z) Received: from mail-in-08.arcor-online.net ([151.189.21.48] [151.189.21.48]) by relay21i.sun.com with ESMTP id BT-MMP-6066784 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:28:00 +0000 (Z) Received: from mail-in-11-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id AFB692F2AAA; Wed, 12 Sep 2007 18:27:59 +0200 (CEST) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-11-z2.arcor-online.net (Postfix) with ESMTP id 9C190345BF1; Wed, 12 Sep 2007 18:27:59 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-245-049.pools.arcor-ip.net [84.58.245.49]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id 6BC882BB4E3; Wed, 12 Sep 2007 18:27:55 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l8CGRoxj002897; Wed, 12 Sep 2007 18:27:51 +0200 (CEST) Date: Wed, 12 Sep 2007 18:27:50 +0200 From: Roland Mainz Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTracktimeout09/10/2007] Sender: gisburn@jupiterb48.nrubsig.org To: Chris Gerhard Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <46E81386.35DBB658@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Virus-Scanned: ClamAV 0.91.2/4255/Wed Sep 12 09:18:47 2007 on mail-in-08.arcor-online.net X-Virus-Status: Clean References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> <46E5716F.7B994FB2@nrubsig.org> <46E67973.8030208@thegerhards.com> Status: RO Content-Length: 2088 Chris Gerhard wrote: > Roland Mainz wrote: > > Darren J Moffat wrote: [snip] > > 2. I have great concerns about the abuse of the global environment > > variable namespace - sooner or later this will backfire _badly_ if cron > > and other applications have slightly different ways to interpret the > > values. > > It would if they did. However since cron is interpreting all the > variables in the way you expect I fail to see how this is an issue. TZ > is treated as the timezone. If we went with .cron.tz cron would still > have to set TZ to match this otherwise you would have a cron job wiht > .cron.tz set to PST but running on a system in UTC would have the job > seeing time as UTC while scheduled in PST. Two issues: 1. You basically assign a double-functionality to the variables - they affect both cron internal behaviour and they are exported into the environment of the launched cron job. For example: What do you want to do if you use the timezone "a" for the cron entries but run the cron job with the default system timezone ? 2. The scheme as described in the current ARC materials is not extensible since you can't gurantee that you won't create namespace clashes between variables which set/define cron-internal behaviour and stuff which is exported into the environment (imagine you add a variable called "VERSION" to define which version of the cron spec should be used to interpret the cron entries - this would render the OS/Net build defunct since environment variables override Makefile variables and usr/src/Makefile.master contains a variable "VERSION" ... or short: *BOOOOOM* ...). Maybe you could say you only export a defined subset of these variables (e.g. "SHELL", "HOME", "TZ") but that would make these other variables more or less "local variables" and by the usual Unix shell conventions such variable names should be at least spelled using lowercase characters... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From cjg@thegerhards.com Wed Sep 12 09:39:15 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CGdEJl026245 for ; Wed, 12 Sep 2007 09:39:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CGaNjd025612 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Sep 2007 09:36:24 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900909KSNFL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 09:36:23 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO900JHLKSLJQD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 09:36:21 -0700 (PDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8CGKmt7008170 for ; Wed, 12 Sep 2007 16:36:21 +0000 (GMT) Received: from mms23es.sun.com ([150.143.232.54] [150.143.232.54]) by relay22i.sun.com with ESMTP id BT-MMP-533185 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:36:20 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms23es.sun.com with ESMTP id BT-MMP-86898 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:36:20 +0000 (Z) Received: from cdmnet.org ([62.24.230.83] [62.24.230.83]) by relay22i.sun.com with ESMTP id BT-MMP-8664567 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:36:19 +0000 (Z) Received: from host217-42-34-163.range217-42.btcentralplus.com ([217.42.34.163]:41290 helo=thegerhards.com) by cdmnet.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IVVCH-0004f9-Sa for PSARC-ext@sun.com; Wed, 12 Sep 2007 17:36:14 +0100 Received: from gmp-ea-fw-1.sun.com ([192.18.1.36] helo=[129.156.173.21]) by thegerhards.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IVVC1-0000Rg-BS; Wed, 12 Sep 2007 16:36:00 +0000 Date: Wed, 12 Sep 2007 17:35:34 +0100 From: Chris Gerhard Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTracktimeout09/10/2007] In-reply-to: <46E81386.35DBB658@nrubsig.org> Sender: cjg@thegerhards.com To: Roland Mainz Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <46E81556.20703@thegerhards.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Spam_score: -101.4 X-Spam_score_int: -1013 X-Spam_bar: --------------------------------------------------- X-Spam_report: Spam detection software, running on the system "pearson.thegerhards.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see Postmaster for details. Content preview: Roland Mainz wrote: > Chris Gerhard wrote: >> Roland Mainz wrote: >>> Darren J Moffat wrote: > [snip] >>> 2. I have great concerns about the abuse of the global environment >>> variable namespace - sooner or later this will backfire _badly_ if cron >>> and other applications have slightly different ways to interpret the >>> values. >> It would if they did. However since cron is interpreting all the >> variables in the way you expect I fail to see how this is an issue. TZ >> is treated as the timezone. If we went with .cron.tz cron would still >> have to set TZ to match this otherwise you would have a cron job wiht >> .cron.tz set to PST but running on a ssystem in UTC would have the job >> seeing time as UTC while scheduled in PST. > > Two issues: > 1. You basically assign a double-functionality to the variables - they > affect both cron internal behaviour and they are exported into the > environment of the launched cron job. > For example: What do you want to do if you use the timezone "a" for the > cron entries but run the cron job with the default system timezone ? [...] Content analysis details: (-101.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> <46E5716F.7B994FB2@nrubsig.org> <46E67973.8030208@thegerhards.com> <46E81386.35DBB658@nrubsig.org> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 2214 Roland Mainz wrote: > Chris Gerhard wrote: >> Roland Mainz wrote: >>> Darren J Moffat wrote: > [snip] >>> 2. I have great concerns about the abuse of the global environment >>> variable namespace - sooner or later this will backfire _badly_ if cron >>> and other applications have slightly different ways to interpret the >>> values. >> It would if they did. However since cron is interpreting all the >> variables in the way you expect I fail to see how this is an issue. TZ >> is treated as the timezone. If we went with .cron.tz cron would still >> have to set TZ to match this otherwise you would have a cron job wiht >> .cron.tz set to PST but running on a system in UTC would have the job >> seeing time as UTC while scheduled in PST. > > Two issues: > 1. You basically assign a double-functionality to the variables - they > affect both cron internal behaviour and they are exported into the > environment of the launched cron job. > For example: What do you want to do if you use the timezone "a" for the > cron entries but run the cron job with the default system timezone ? With a crontab entry like this: TZ=UTC * * * 7 * env TZ=PST ..... > > 2. The scheme as described in the current ARC materials is not > extensible since you can't gurantee that you won't create namespace > clashes between variables which set/define cron-internal behaviour and > stuff which is exported into the environment (imagine you add a variable > called "VERSION" to define which version of the cron spec should be used > to interpret the cron entries - this would render the OS/Net build > defunct since environment variables override Makefile variables and > usr/src/Makefile.master contains a variable "VERSION" ... or short: > *BOOOOOM* ...). > Maybe you could say you only export a defined subset of these variables > (e.g. "SHELL", "HOME", "TZ") but that would make these other variables > more or less "local variables" and by the usual Unix shell conventions > such variable names should be at least spelled using lowercase > characters... I do. The only variables I export are SHELL, HOME and TZ since they are the only ones that effect cron. It does not allow the setting of any other variables. --chirs From roland.mainz@nrubsig.org Wed Sep 12 09:49:52 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CGnpox026289 for ; Wed, 12 Sep 2007 09:49:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l8CGkwYA007441 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Sep 2007 00:47:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900K2NLA9WR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 09:46:57 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO900FEJLA9G190@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 09:46:57 -0700 (PDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8CFxl60028112 for ; Wed, 12 Sep 2007 16:46:57 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay25i.sun.com with ESMTP id BT-MMP-1327995 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:46:57 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.sun.com with ESMTP id BT-MMP-303811 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:46:56 +0000 (Z) Received: from mail-in-07.arcor-online.net ([151.189.21.47] [151.189.21.47]) by relay22i.sun.com with ESMTP id BT-MMP-8675851 for PSARC-ext@sun.com; Wed, 12 Sep 2007 16:46:56 +0000 (Z) Received: from mail-in-12-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id C74CD24B25F; Wed, 12 Sep 2007 18:46:55 +0200 (CEST) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-12-z2.arcor-online.net (Postfix) with ESMTP id 9F26B279401; Wed, 12 Sep 2007 18:46:55 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-245-049.pools.arcor-ip.net [84.58.245.49]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id 620CD2F2C14; Wed, 12 Sep 2007 18:46:51 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l8CGklNs002918; Wed, 12 Sep 2007 18:46:47 +0200 (CEST) Date: Wed, 12 Sep 2007 18:46:47 +0200 From: Roland Mainz Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTracktimeout09/10/2007] Sender: gisburn@jupiterb48.nrubsig.org To: Chris Gerhard Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <46E817F7.4BB941D2@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 X-Virus-Scanned: ClamAV 0.91.2/4255/Wed Sep 12 09:18:47 2007 on mail-in-08.arcor-online.net X-Virus-Status: Clean References: <200709031328.l83DS9oV016496@sac.sfbay.sun.com> <46E5716F.7B994FB2@nrubsig.org> <46E67973.8030208@thegerhards.com> <46E81386.35DBB658@nrubsig.org> <46E81556.20703@thegerhards.com> Status: RO Content-Length: 3059 Chris Gerhard wrote: > Roland Mainz wrote: > > Chris Gerhard wrote: > >> Roland Mainz wrote: > >>> Darren J Moffat wrote: [snip] > > Two issues: > > 1. You basically assign a double-functionality to the variables - they > > affect both cron internal behaviour and they are exported into the > > environment of the launched cron job. > > For example: What do you want to do if you use the timezone "a" for the > > cron entries but run the cron job with the default system timezone ? > > With a crontab entry like this: > > TZ=UTC > * * * 7 * env TZ=PST ..... I really wish the functionality could be cleanly split: One variable (maybe just written lowercase to indicate that it's affecting local behvaiour ("local"=this cron instance)) which affects the timezone selection and a 2nd (written using an uppercase name) which is the variable which is exported to the environment of the launched process. > > 2. The scheme as described in the current ARC materials is not > > extensible since you can't gurantee that you won't create namespace > > clashes between variables which set/define cron-internal behaviour and > > stuff which is exported into the environment (imagine you add a variable > > called "VERSION" to define which version of the cron spec should be used > > to interpret the cron entries - this would render the OS/Net build > > defunct since environment variables override Makefile variables and > > usr/src/Makefile.master contains a variable "VERSION" ... or short: > > *BOOOOOM* ...). > > Maybe you could say you only export a defined subset of these variables > > (e.g. "SHELL", "HOME", "TZ") but that would make these other variables > > more or less "local variables" and by the usual Unix shell conventions > > such variable names should be at least spelled using lowercase > > characters... > > I do. The only variables I export are SHELL, HOME and TZ since they are > the only ones that effect cron. It does not allow the setting of any > other variables. What about future extensions ? IMO it would be nice to have a way to seperate between variables which have only a local meaning and those which are exported. For example what happens if you add a variable to set the "project" (e.g. the project(4) thing) using a "PROJECT" variable (note that the environment variable "PROJECT" is already in use by other software and shouldn't be set in an environment (see my easlier concerns about namespace collisions)) ? What if you want to set a cron-internal variable (in a later ARC case as extension) which should be exported (for example one of the very old proposals was a "CRON_SESSION" environment variable which contains an identifier for the current cron session and the other idea was "MAILTO" (which leads to the question whether MAILTO should be exported to the environment of the launched cron process (which may be usefull) or not)) ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From cjg@thegerhards.com Wed Sep 12 11:19:34 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CIJYIk001045 for ; Wed, 12 Sep 2007 11:19:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CIGfu5029586; Wed, 12 Sep 2007 11:16:42 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900105PFTGU00@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Sep 2007 11:16:41 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO9001ESPFS9400@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Sep 2007 11:16:40 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8CIAs7m012153; Wed, 12 Sep 2007 18:16:40 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay12i.sun.com with ESMTP id BT-MMP-480143; Wed, 12 Sep 2007 18:16:40 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp11es.sun.com with ESMTP id BT-MMP-96384; Wed, 12 Sep 2007 18:16:39 +0000 (Z) Received: from cdmnet.org ([62.24.230.83] [62.24.230.83]) by relay1i.sun.com with ESMTP id BT-MMP-2376622; Wed, 12 Sep 2007 18:16:38 +0000 (Z) Received: from host217-42-34-163.range217-42.btcentralplus.com ([217.42.34.163]:42718 helo=thegerhards.com) by cdmnet.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IVWlQ-0000qZ-Vt; Wed, 12 Sep 2007 19:16:37 +0100 Received: from gmp-ea-fw-1.sun.com ([192.18.1.36] helo=[129.156.173.21]) by thegerhards.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IVWlF-0007ZO-GK; Wed, 12 Sep 2007 18:16:27 +0000 Date: Wed, 12 Sep 2007 19:16:19 +0100 From: Chris Gerhard Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo In-reply-to: <200709110055.l8B0t3j2012055@spartan.SFBay.Sun.COM> Sender: cjg@thegerhards.com To: Don Cragun Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com Message-id: <46E82CF3.7060006@thegerhards.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Spam_score: -101.4 X-Spam_score_int: -1013 X-Spam_bar: --------------------------------------------------- X-Spam_report: Spam detection software, running on the system "pearson.thegerhards.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see Postmaster for details. Content preview: Don Cragun wrote: >> Date: Mon, 10 Sep 2007 10:23:52 +0100 >> From: Darren J Moffat >> >> 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. [...] Content analysis details: (-101.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list References: <200709110055.l8B0t3j2012055@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 6557 Don Cragun wrote: >> Date: Mon, 10 Sep 2007 10:23:52 +0100 >> From: Darren J Moffat >> >> 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 From sommerfeld@sun.com Wed Sep 12 12:21:28 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CJLROS002985 for ; Wed, 12 Sep 2007 12:21:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CJIW2X018548; Wed, 12 Sep 2007 12:18:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900A01SB00700@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 13:18:36 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO9005YRSAZ9D50@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 13:18:35 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l8CJITu8010631; Wed, 12 Sep 2007 15:18:29 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8CJIT1a015046; Wed, 12 Sep 2007 15:18:29 -0400 (EDT) Date: Wed, 12 Sep 2007 15:18:28 -0400 From: Bill Sommerfeld Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo In-reply-to: <200709110055.l8B0t3j2012055@spartan.SFBay.Sun.COM> To: Don Cragun Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, chris@thegerhards.com Message-id: <1189624708.14897.42.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709110055.l8B0t3j2012055@spartan.SFBay.Sun.COM> Status: RO Content-Length: 574 On Mon, 2007-09-10 at 17:55 -0700, Don Cragun wrote: > 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 don't believe it's appropriate to have warnings against perfectly reasonable usage of the feature. What we need is a clear warning that the variable settings affect all successive entries and that administrators need to be on the lookout for unexpected side-effects. - Bill From sommerfeld@sun.com Wed Sep 12 12:27:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CJRpTx003141 for ; Wed, 12 Sep 2007 12:27:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CJOk56026760; Wed, 12 Sep 2007 20:25:00 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900044SLNJ200@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Sep 2007 12:24:59 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO900AAOSLJNYB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 12 Sep 2007 12:24:56 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l8CJOrYp034304; Wed, 12 Sep 2007 15:24:53 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8CJOqUn015063; Wed, 12 Sep 2007 15:24:52 -0400 (EDT) Date: Wed, 12 Sep 2007 15:24:52 -0400 From: Bill Sommerfeld Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo In-reply-to: <200709072341.l87NfgVa008741@spartan.SFBay.Sun.COM> To: Don Cragun Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, chris@thegerhards.com Message-id: <1189625092.14897.49.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709072341.l87NfgVa008741@spartan.SFBay.Sun.COM> Status: RO Content-Length: 739 On Fri, 2007-09-07 at 16:41 -0700, Don Cragun wrote: > 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. Exactly what constitutes off-peak hours for an installation depends not only on $TZ, but also on when peak activity actually occurs. > 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. But that also the case if timezone shifting isn't enabled; a vendor's preconception of likely off-peak hours will be wrong at many sites. - Bill From John.Plocher@Sun.COM Wed Sep 12 13:45:56 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CKjuP2005585 for ; Wed, 12 Sep 2007 13:45:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CKh1ea024414; Wed, 12 Sep 2007 13:43:05 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900E07W7SJ800@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 14:43:04 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO9005HYW7P9FB0@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 14:43:01 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l8CKh1Dk005626; Wed, 12 Sep 2007 13:43:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JO900301VZ88Y00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 12 Sep 2007 13:43:01 -0700 (PDT) Received: from [129.146.58.87] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JO900HF7W7OV1E0@fe-sfbay-09.sun.com>; Wed, 12 Sep 2007 13:43:01 -0700 (PDT) Date: Wed, 12 Sep 2007 13:42:35 -0700 From: John Plocher Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo In-reply-to: <1189624708.14897.42.camel@thunk> Sender: John.Plocher@Sun.COM To: Bill Sommerfeld Cc: Don Cragun , PSARC-ext@Sun.COM, chris@thegerhards.com Message-id: <46E84F3B.6030004@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709110055.l8B0t3j2012055@spartan.SFBay.Sun.COM> <1189624708.14897.42.camel@thunk> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 1758 How about changing the spec to avoid this problem all together: There is a knob that controls this behavior. The knob is a special comment at the beginning of the crontab file itself: #pragma envvariables={disallowed|singleton|shared} With the default setting of "disallowed", it is a syntax error for there to be lines of the form "^name=value$" in the crontab file. The user can place an entry in the crontab of either #pragma envvariables=singleton or #pragma envvariables=shared In either of these cases, ...include current spec... With the "singleton" setting, a cron/env variable setting ONLY effects the cron job entry immediately following the settings; all such settings/values are dropped and not used for cronjob entries that follow it in the file. With the "shared" setting, the cron/env variables and their values are remembered and passed on to all subsequent cronjob invocations found in the file. -John Bill Sommerfeld wrote: > On Mon, 2007-09-10 at 17:55 -0700, Don Cragun wrote: >> 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 don't believe it's appropriate to have warnings against perfectly > reasonable usage of the feature. > > What we need is a clear warning that the variable settings affect all > successive entries and that administrators need to be on the lookout > for unexpected side-effects. > > - Bill > > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From don.cragun@Sun.COM Wed Sep 12 14:20:45 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CLKjGp006826 for ; Wed, 12 Sep 2007 14:20:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CLHrsJ024737 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Sep 2007 14:17:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900G11XTTLS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 15:17:53 -0600 (MDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO90054UXTR9HC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Sep 2007 15:17:52 -0600 (MDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id l8CLHpNf016551; Wed, 12 Sep 2007 14:17:51 -0700 (PDT) Date: Wed, 12 Sep 2007 14:17:51 -0700 (PDT) From: Don Cragun Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo To: chris@thegerhards.com Cc: PSARC-ext@Sun.COM Reply-to: Don Cragun Message-id: <200709122117.l8CLHpNf016551@spartan.SFBay.Sun.COM> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: VqMleyghYKe5tqQI6f1r1A== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 8899 >Date: Wed, 12 Sep 2007 19:16:19 +0100 >From: Chris Gerhard > >Don Cragun wrote: >>> Date: Mon, 10 Sep 2007 10:23:52 +0100 >>> From: Darren J Moffat >>> >>> 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 From sommerfeld@sun.com Wed Sep 12 14:40:48 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l8CLemec007401 for ; Wed, 12 Sep 2007 14:40:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l8CLbouf021108; Wed, 12 Sep 2007 22:37:56 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JO900A03YR6OD00@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Sep 2007 14:37:54 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO9001RJYR68WA0@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Sep 2007 14:37:54 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l8CLbqq2050810; Wed, 12 Sep 2007 17:37:52 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8CLbqRu015977; Wed, 12 Sep 2007 17:37:52 -0400 (EDT) Date: Wed, 12 Sep 2007 17:37:51 -0400 From: Bill Sommerfeld Subject: Re: crontab entry environment variables [PSARC/2007/503 FastTrack timeo In-reply-to: <200709122117.l8CLHpNf016551@spartan.SFBay.Sun.COM> To: Don Cragun Cc: chris@thegerhards.com, PSARC-ext@sun.com Message-id: <1189633071.14897.106.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709122117.l8CLHpNf016551@spartan.SFBay.Sun.COM> Status: RO Content-Length: 545 On Wed, 2007-09-12 at 14:17 -0700, Don Cragun wrote: > 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. Why can't that compliance knob be "don't include lines which are syntax errors under the POSIX spec"? - Bill