crond, hwclock, and clockspeed

[Lloyd Zusman]

I've got my linux box running with clockspeed, with "/etc/leapsecs.dat",
and with "/etc/localtime" pointing to a "right" timezone file, namely
"/usr/share/zoneinfo/right/America/New_York".

In most cases, my times are shown correctly.  For example, if I do the
test below, the times in the "Date:" header and in the body of the message
agree:

  (sntpclock 209.51.161.238 | clockview ; date) | mail -s date ljz@...

However, it looks like "crond" is not taking the leapseconds into account.
The following is an excerpt from /var/log/cron:

  Sep 12 07:07:39 home crond[6187]: (ljz) CMD (/opt/bin/eachminute 1>/dev/null 2>&1)
  Sep 12 07:08:39 home crond[6191]: (ljz) CMD (/opt/bin/eachminute 1>/dev/null 2>&1)

I have restarted crond with an explicit "TZ=right/America/New_York" in the
environment, but cron still seems to be ignoring the leapseconds.

Can anyone explain this and suggest a way to get "crond" to realize the
correct time?

Also, I have noticed the following behavior with the "hwclock" program:

  # (export TZ=right/America/New_York; hwclock --set --date="$(date '+%m/%d/%y
%H:%M:%S')"; hwclock --show; date)              
  Mon Sep 12 07:17:50 2005  -0.494631 seconds
  2005-09-12T07:18:11-0400
  # (export TZ=America/New_York; hwclock --set --date="$(date '+%m/%d/%y
%H:%M:%S')"; hwclock --show; date)
  Mon Sep 12 07:19:10 2005  -0.497663 seconds
  2005-09-12T07:19:09-0400

It seems like the "hwclock" program only shows the correct time _without_
a "right" timezone, even though the rest of my system seems to be operating
correctly with "right" and with "/etc/leapsecs.dat".

Can someone help me understand this?

Thanks in advance.

--
 Lloyd Zusman
 ljz@...
 God bless you.

[Thorsten Glaser]

Lloyd Zusman dixit:

>However, it looks like "crond" is not taking the leapseconds into account.
>The following is an excerpt from /var/log/cron:
>
>  Sep 12 07:07:39 home crond[6187]: (ljz) CMD (/opt/bin/eachminute 1>/dev/null 2>&1)
>  Sep 12 07:08:39 home crond[6191]: (ljz) CMD (/opt/bin/eachminute 1>/dev/null 2>&1)

I can reproduce stuff like that:
   Sep 12 12:35:39 odem cron[29918]: (root) CMD (/usr/bin/nice /usr/sbin/sendmail -L sm-msp-queue -Ac -q)

Probably, cron doesn't run at the full minute. From crontab:
   #minute hour    mday    month   wday    command
   #
   # sendmail clientmqueue runner
   35      */3     *       *       *       /usr/bin/nice /usr/sbin/sendmail -L sm-msp-queue -Ac -q

So this is okay.

>Also, I have noticed the following behavior with the "hwclock" program:

No comment about this, since I've not touched GNU/Linux since 2000.
BSD doesn't have a "hwclock" equivalent since we do the right thing
(kernel sets CMOS time).

bye,
//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt

[Lloyd Zusman]

Thorsten Glaser <tg@...> writes:

> Lloyd Zusman dixit:
>
>>However, it looks like "crond" is not taking the leapseconds into account.
>>The following is an excerpt from /var/log/cron:
>>
>>  Sep 12 07:07:39 home crond[6187]: (ljz) CMD (/opt/bin/eachminute 1>/dev/null 2>&1)
>>  Sep 12 07:08:39 home crond[6191]: (ljz) CMD (/opt/bin/eachminute 1>/dev/null 2>&1)
>
> I can reproduce stuff like that:
>    Sep 12 12:35:39 odem cron[29918]: (root) CMD (/usr/bin/nice /usr/sbin/sendmail -L sm-msp-queue -Ac -q)
>
> Probably, cron doesn't run at the full minute. From crontab:
>    #minute hour    mday    month   wday    command
>    #
>    # sendmail clientmqueue runner
>    35      */3     *       *       *       /usr/bin/nice /usr/sbin/sendmail -L sm-msp-queue -Ac -q
>
> So this is okay.

Thank you.

However, it turns out that cron does indeed normally run at the full
minute, which is what occurs when I get rid of /etc/leapsecs.dat and use
a non-"right" timezone.  I can reproduce this exactly-on-the-minute
behavior on every other unix-like system I have tried it on: four Linux
systems (without "right" and without leapsecs.dat), and one FreeBSD
system.

And as soon as I change to right/leapsecs.dat on the Linux systems, I
get the *:*:39 behavior again with crond.  The FreeBSD crond runs on the
minute both with and without right/leapsecs.dat.

I'm guessing that this is just some sort of idiosyncracy of Linux's
crond.  Perhaps it tries to be smart about leap seconds itself, thereby
getting confused by the right/leapsecs.dat stuff ... ???


>>Also, I have noticed the following behavior with the "hwclock" program:
>
> No comment about this, since I've not touched GNU/Linux since 2000.
> BSD doesn't have a "hwclock" equivalent since we do the right thing
> (kernel sets CMOS time).
>
> bye,
> //mirabile

Well, my reporting of the hwclock behavior turned out to be a red
herring.  After I set the hardware clock to the system time, it slowly
corrected itself, and then after a while, it was in sync with the
right/leapsecs.dat based system time.

Thanks again.

--
 Lloyd Zusman
 ljz@...
 God bless you.

[Paul Jarc]

Lloyd Zusman <ljz@...> wrote:
> I'm guessing that this is just some sort of idiosyncracy of Linux's
> crond.  Perhaps it tries to be smart about leap seconds itself, thereby
> getting confused by the right/leapsecs.dat stuff ... ???

I would guess that it does date arithmetic by essentially
reimplementing libc's localtime(), and assuming a POSIX clock.  Other
schedulers may not have the same problem.  At least, mine doesn't. :)


paul

[Thorsten Glaser]

Lloyd Zusman dixit:

>I'm guessing that this is just some sort of idiosyncracy of Linux's

This is MirBSD, not GNU/Linux, here, and our cron also has this behaviour.
(MirBSD only has "right" timezones, no "POSIX" ones.)

>crond.  Perhaps it tries to be smart about leap seconds itself, thereby
>getting confused by the right/leapsecs.dat stuff ... ???

I can't explain the 39 then. If it were 22, I'd agree. If it were -22
(or 38), I'd agree.

//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt

[Lloyd Zusman]

prj@... (Paul Jarc) writes:

> Lloyd Zusman <ljz@...> wrote:
>> I'm guessing that this is just some sort of idiosyncracy of Linux's
>> crond.  Perhaps it tries to be smart about leap seconds itself, thereby
>> getting confused by the right/leapsecs.dat stuff ... ???
>
> I would guess that it does date arithmetic by essentially
> reimplementing libc's localtime(), and assuming a POSIX clock.  Other
> schedulers may not have the same problem.  At least, mine doesn't. :)

Yes, I took a look at "runwhen" just today, actually.  I presume that's
what you're referring to. :)

Do you or anyone else here have a tool that will automatically generate
runwhen scripts based on syntax that's at least vaguely crontab-like?
If I had a utility like that, I'd switch to runwhen in a heartbeat.

I schedule a few once-a-month jobs, and therefore, this desired utility
would also have to generate runwhen scripts that manage programs that
run on more-than-25-day intervals on my 2.6 linux system.

If such a tool doesn't already exist, I guess I'll just have to write it
myself ... which I'll be glad to do.


--
 Lloyd Zusman
 ljz@...
 God bless you.

[Lloyd Zusman]

Thorsten Glaser <tg@...> writes:

> Lloyd Zusman dixit:
>
>>I'm guessing that this is just some sort of idiosyncracy of Linux's
>
> This is MirBSD, not GNU/Linux, here, and our cron also has this behaviour.
> (MirBSD only has "right" timezones, no "POSIX" ones.)
>
>>crond.  Perhaps it tries to be smart about leap seconds itself, thereby
>>getting confused by the right/leapsecs.dat stuff ... ???
>
> I can't explain the 39 then. If it were 22, I'd agree. If it were -22
> (or 38), I'd agree.

Well, sometimes cron jobs start running one second late, depending on
where within the span of a second the daemon wakes up, how long it takes
to fork processes, etc.  Therefore, perhaps *:*:39 is the same as
*:*:01.  I have less than a day of log entries, and so I don't know if
after a while, some of them might end up being *:*:38.  I do see a
number of these *:*:01 entries within cron logs for daemons not running
under right/leapsecs.dat.


> //mirabile

--
 Lloyd Zusman
 ljz@...
 God bless you.

[Paul Jarc]

Lloyd Zusman <ljz@...> wrote:
> Yes, I took a look at "runwhen" just today, actually.  I presume that's
> what you're referring to. :)

Yep.

> Do you or anyone else here have a tool that will automatically generate
> runwhen scripts based on syntax that's at least vaguely crontab-like?

http://code.dogmap.org./runwhen/#related

> I schedule a few once-a-month jobs, and therefore, this desired utility
> would also have to generate runwhen scripts that manage programs that
> run on more-than-25-day intervals on my 2.6 linux system.

One way to handle that would be to have your script sleep for, say, a
constant two weeks ("rw-add n d14d wake rw-sleep \$wake ..."), and
then from there figure out how long it is until the next run time and
sleep again.  Early wakeups with "svc -a" would require some special
handling.


paul

[Lloyd Zusman]

prj@... (Paul Jarc) writes:

> Lloyd Zusman <ljz@...> wrote:
>> Yes, I took a look at "runwhen" just today, actually.  I presume that's
>> what you're referring to. :)
>
> Yep.
>
>> Do you or anyone else here have a tool that will automatically generate
>> runwhen scripts based on syntax that's at least vaguely crontab-like?
>
> http://code.dogmap.org./runwhen/#related
>
>> I schedule a few once-a-month jobs, and therefore, this desired utility
>> would also have to generate runwhen scripts that manage programs that
>> run on more-than-25-day intervals on my 2.6 linux system.
>
> One way to handle that would be to have your script sleep for, say, a
> constant two weeks ("rw-add n d14d wake rw-sleep \$wake ..."), and
> then from there figure out how long it is until the next run time and
> sleep again.  Early wakeups with "svc -a" would require some special
> handling.

Thanks.  I overlooked the "migration tool" link the first time around.

Hmm ... couldn't the >25-day case be handled by rw-sleep, which could
break long intervals into a group of slightly-less-than-25-day
increments?  This could be enabled via conditional compilation for those
of us who have broken^H^H^H^H^H^Hmodern linux setitimer calls, with
the current functionality being the default for everyone else.

Or am I missing something?


--
 Lloyd Zusman
 ljz@...
 God bless you.

[Paul Jarc]

Lloyd Zusman <ljz@...> wrote:
> Hmm ... couldn't the >25-day case be handled by rw-sleep, which could
> break long intervals into a group of slightly-less-than-25-day
> increments?

It could, but that would interfere with an early wakeup from a manual
SIGALRM, since there's no way to tell where the SIGALRM came from.
I'd rather see the kernel fixed.  Until then, a little extra scripting
will get the job done, and will make the user more aware that some
things (early wakeups) won't work quite the same.


paul

[Lloyd Zusman]

prj@... (Paul Jarc) writes:

> Lloyd Zusman <ljz@...> wrote:
>> Hmm ... couldn't the >25-day case be handled by rw-sleep, which could
>> break long intervals into a group of slightly-less-than-25-day
>> increments?
>
> It could, but that would interfere with an early wakeup from a manual
> SIGALRM, since there's no way to tell where the SIGALRM came from.
> I'd rather see the kernel fixed.  Until then, a little extra scripting
> will get the job done, and will make the user more aware that some
> things (early wakeups) won't work quite the same.
>
>
> paul

OK.  I understand about SIGALRM making it complicated.  Well, I'm going
to see if I can put some sort of useful wrapper around rw-sleep which
manages this.  It'll be a nice project for my spare time over the next
few weeks.



--
 Lloyd Zusman
 ljz@...
 God bless you.

[Lloyd Zusman]

prj@... (Paul Jarc) writes:

> Lloyd Zusman <ljz@...> wrote:
>> Hmm ... couldn't the >25-day case be handled by rw-sleep, which could
>> break long intervals into a group of slightly-less-than-25-day
>> increments?
>
> It could, but that would interfere with an early wakeup from a manual
> SIGALRM, since there's no way to tell where the SIGALRM came from.
> I'd rather see the kernel fixed.  Until then, a little extra scripting
> will get the job done, and will make the user more aware that some
> things (early wakeups) won't work quite the same.

A thought: could rw-sleep be patched to do an early wakeup in response
to something in addition to SIGALRM, such as SIGHUP?  If so, then the
hypothetical change I mentioned above would still work, as long as those
of us with broken setitimer calls always use that extra signal for an
early wakeup.


--
 Lloyd Zusman
 ljz@...
 God bless you.