Bug 17750

Comment 1 Brian Somers 2000-04-02 23:49:18 UTC

Responsible Changed
From-To: freebsd-bugs->brian

I've already got a bunch of similar PRs. 

In article <200004021318.PAA72810@internal> you wrote:
> 
>>Number:         17750
>>Category:       conf
>>Synopsis:       periodic/daily problem one day after changing to summer time
>>Confidential:   no
>>Severity:       non-critical
>>Priority:       medium
>>Responsible:    freebsd-bugs
>>State:          open
>>Quarter:        
>>Keywords:       
>>Date-Required:
>>Class:          sw-bug
>>Submitter-Id:   current-users
>>Arrival-Date:   Sun Apr  2 06:20:00 PDT 2000
>>Closed-Date:
>>Last-Modified:
>>Originator:     Andre Albsmeier
>>Release:        FreeBSD 3.4-STABLE i386
>>Organization:
>>Environment:
> 
> 3.4-STABLE, but I assume all versions
> 
>>Description:
> 
> Each morning at 1:59 the /etc/periodic/daily/* scripts are run. Among
> them is 460.status-mail-rejects which executes a "date -v-1d '+%b %d'"
> command. Depending on how many time is needed to run the previous daily
> scripts, it is possible that 460.status-mail-rejects is run shortly after
> 2:00. In this case, and if the system has changed to daylight saving time
> one day before, the "date -v-1d '+%b %d'" fails since the calculated
> time does not exist:
> 
> Checking for rejected mail hosts: 
> -1d: Cannot apply date adjustment 
> usage: date [-nu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
>             [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]
> 
> 
>>How-To-Repeat:
> 
> Can be repeated easily if you have a system that has lots of 
> things to do when running the /etc/periodic/daily/*. For example,
> this might happen when you have big local disks that make 
> 450.status-security run quite a while.
> 
> I assume, you can trigger the problem by temporarely creating
> a file /etc/periodic/daily/459.sleep that only contains a "sleep 61"
> command. Than wait until one day after swithing to summer time
> has occured and check your mail :-)
> 
>>Fix:
> 	
> Let the scripts run at 3:01 :-).
> 
> Seriously, we could move 460.status-mail-rejects to the beginning of
> /etc/periodic/daily but I would not call this a clean solution.

This is not a misconfiguration of the scripts. This is the concequence
of a broken date(1) command. date(1) should not fail,

  % date; date -v-1d
  Mon Apr  3 02:01:00 EDT 2000
  Sun Apr  2 01:01:00 EST 2000

But should return the time from 24 hours ago, regardless of any
daylight-time changes. It behaves correctly for me now,

  % date; date -v-2d
  Mon Apr  3 10:49:15 EDT 2000
  Sat Apr  1 09:49:15 EST 2000

I don't have the time to dig into the date source at the moment, but
it looks like something in there is not right.
-- 
Crist J. Clark                           cjclark@home.com

On Mon, 03-Apr-2000 at 10:51:24 -0400, Crist J. Clark wrote:
> In article <200004021318.PAA72810@internal> you wrote:
> > 
> > Each morning at 1:59 the /etc/periodic/daily/* scripts are run. Among
> > them is 460.status-mail-rejects which executes a "date -v-1d '+%b %d'"
> > command. Depending on how many time is needed to run the previous daily
> > scripts, it is possible that 460.status-mail-rejects is run shortly after
> > 2:00. In this case, and if the system has changed to daylight saving time
> > one day before, the "date -v-1d '+%b %d'" fails since the calculated
> > time does not exist:
> > 
> > Checking for rejected mail hosts: 
> > -1d: Cannot apply date adjustment 
> > usage: date [-nu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
> >             [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]
> > 
> > 
> >>How-To-Repeat:
> > 
> > Can be repeated easily if you have a system that has lots of 
> > things to do when running the /etc/periodic/daily/*. For example,
> > this might happen when you have big local disks that make 
> > 450.status-security run quite a while.
> > 
> > I assume, you can trigger the problem by temporarely creating
> > a file /etc/periodic/daily/459.sleep that only contains a "sleep 61"
> > command. Than wait until one day after swithing to summer time
> > has occured and check your mail :-)
> > 
> >>Fix:
> > 	
> > Let the scripts run at 3:01 :-).
> > 
> > Seriously, we could move 460.status-mail-rejects to the beginning of
> > /etc/periodic/daily but I would not call this a clean solution.
> 
> This is not a misconfiguration of the scripts. This is the concequence
> of a broken date(1) command. date(1) should not fail,
> 
>   % date; date -v-1d
>   Mon Apr  3 02:01:00 EDT 2000
>   Sun Apr  2 01:01:00 EST 2000
> 
> But should return the time from 24 hours ago, regardless of any
> daylight-time changes. It behaves correctly for me now,
> 
>   % date; date -v-2d
>   Mon Apr  3 10:49:15 EDT 2000
>   Sat Apr  1 09:49:15 EST 2000

Well, here it does not:

andre@bali:~>date; date -v-8d -v-16H
Mon Apr  3 18:25:45 CEST 2000
-16H: Cannot apply date adjustment
usage: date [-nu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]

whereas these work:

andre@bali:~>date; date -v-8d -v-15H
Mon Apr  3 18:26:50 CEST 2000
Sun Mar 26 03:26:50 CEST 2000

andre@bali:~>date; date -v-8d -v-17H
Mon Apr  3 18:26:54 CEST 2000
Sun Mar 26 00:26:54 CET 2000

Comment 4 Brian Somers 2000-04-05 03:01:08 UTC

State Changed
From-To: open->closed

Fixed with vary.c v1.9