Bug 435315 - /etc/rc.d/rc.sysinit can't set the system clock
Summary: /etc/rc.d/rc.sysinit can't set the system clock
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts
Version: 5.1
Hardware: s390x
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On: 435312
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-28 17:32 UTC by Martin Poole
Modified: 2009-03-11 17:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-11 17:51:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Martin Poole 2008-02-28 17:32:50 UTC
+++ This bug was initially created as a clone of Bug #435312 +++

Escalated to Bugzilla from IssueTracker

-- Additional comment from tao on 2008-02-28 12:26 EST --
Our customer is running the 64-bit RHEL4 U5 s390x distribution on an IBM System
z9 BC.

There is no hwclock command in zSeries Linux to allow the System clock to be set
correctly when the Hardware Time-of-Day (TOD) Clock is set to Local time. In
/etc/rc.d/rc.sysinit the Red Hat s390x distribution states that the System date
on S390 is always set correctly, by which it means that the zSeries TOD clock
keeps time in UTC.

For those systems where this is not the case, the Novell s390 distribution
provides the following compensation in their /etc/init.d/boot.clock script:

 # set and adjust the CMOS clock
 if [ "$HOSTTYPE" = "s390" -o "$HOSTTYPE" = "s390x" ] ; then
  echo -n Setting up the system clock
  # On s390 the hwclock is set outside Linux currently.  The kernel
  # always assumes it to be set to UTC.  So if it is set to local
  # time, we have to compensate for that.  We might achieve this
  # using this special settimeofday(2) linux feature:
  #  Under  Linux there is some peculiar `warp clock' semantics
  #  associated to the settimeofday system call if on the  very
  #  first  call  (after  booting) that has a non-NULL tz argu-
  #  ment, the tv argument is NULL and the tz_minuteswest field
  #  is  nonzero.  In  such  a case it is assumed that the CMOS
  #  clock is on local time, and that it has to be  incremented
  #  by  this  amount to get UTC system time.  No doubt it is a
  #  bad idea to use this feature.  (settimeofday(2) man page)
  # But unless someone complains we simply will use date(1) to shift
  # the system time by the difference between UTC and local time, if
  # the system clock is set to local time.  This will introduce a
  # minimal shift due to the delay between gettimeofday and
  # settimeofday, and it only works as long as $0 is executed
  # exactly once, at boot.
  if test "$HWCLOCK" != "-u"; then
      date $(date -u +'%m%d%H%M%Y')
     rc_status
  fi
  rc_status -v -r
 else
  ...

We would like a similar compensation in the Red Hat boot scripts to allow
correct time in the event that the Hardware TOD clock is set to Local time.

Could we get a hotfix for the rhel4 u5 initscripts-7.93.29.EL-1.s390x.rpm
package as well having the fix added to all future releases of RHEL4 and RHEL5.
This event sent from IssueTracker by mpoole  [SEG - Base OS]
 issue 166134

Comment 1 Karel Zak 2008-03-03 08:53:50 UTC
Note, for discussion about this issue see bug #435312.

Comment 2 Bill Nottingham 2009-03-11 17:51:54 UTC
Dependent bug closed, closing this one.


Note You need to log in before you can comment on or make changes to this bug.