Ubuntu – UTC=no in /etc/default/rcS on a Fresh Install 14.04. Why

14.04dual-bootsystem-installationtime

I recently installed 14.04, and decided to do so as a fresh install.

I wiped the only Ubuntu installation on the system, left a Windows 7 installation on, and installed over mdadm (once with /boot on mdadm and later with it not on mdadm as that saves a few other headaches. I'm pretty sure what I'm describing happened in both cases).

Everything from previous Ubuntu installations were completely wiped by manual formatting of the relevant partitions.

I'm in a time-zone currently on Irish Summer Time (UTC+01:00). Windows started jumping the time an hour ahead.

Now, I might expect a default Windows installation to jump the time an hour back, thinking the UTC bios time was the local time, but this was an hour ahead and I had RealTimeIsUniversal set in the registry to get some saner behaviour out of Windows.

After some puzzling over this, I realised that in /etc/default/rcS there was the line UTC=no to set Ubuntu onto local time rather than the normal UTC=yes.

This is a well-known setting for people who normally only use Windows as the illogical choice of local time (not unambiguous) means less change for them than fixing Windows in a way that MS don't support, but I certainly didn't set it.

This was easily fixed, but as I don't know what broke it, I don't know that it won't be broken again.

Is there anything that sets UTC=no upon use or installation, and if so can that be blocked?

Best Answer

If you install Ubuntu on a clean disk with no other OS, UTC=yes is used as default. In your situation, you have Windows aside Ubuntu. So in the installation Ubuntu detected Windows and set UTC=no. Although your Ubuntu is clean, the disk is not clean.

Related Solutions

Ubuntu – How to use cron to schedule a script that implements daylight saving on a non- DST aware application when the server automatically uses DST

The answer lies in the cron sources (which you can get by apt-get source cron), particularly in the main loop at lines 159--272 of file cron.c.

crond sleeps for a minute, then wakes up and queries the system time, comparing it to its own idea of time (i.e., what time it would be if nothing altered the clock). Based on the difference between the actual and the expected time, crond takes different actions; two of them are relevant in your case:

Time has leaped forward more than 5 minutes but less than 3 hours (DST starts): cron runs wildcard jobs scheduled at the actual time, and any job scheduled at a fixed time between the computed time and the actual time. Relevant source is at lines 221--247:

  /*
   * case 2: timeDiff is a medium-sized positive number,
   * for example because we went to DST run wildcard
   * jobs once, then run any fixed-time jobs that would
   * otherwise be skipped if we use up our minute
   * (possible, if there are a lot of jobs to run) go
   * around the loop again so that wildcard jobs have
   * a chance to run, and we do our housekeeping
   */
  Debug(DSCH, ("[%d], DST begins %d minutes to go\n",
      getpid(), timeRunning - virtualTime))
  /* run wildcard jobs for current minute */
  find_jobs(timeRunning, &database, TRUE, FALSE);


  /* run fixed-time jobs for each minute missed */ 
  do {
     if (job_runqueue())
             sleep(10);
     virtualTime++;
     find_jobs(virtualTime, &database, FALSE, TRUE);
     set_time();
  } while (virtualTime< timeRunning &&
      clockTime == timeRunning);
  break;

Time has gone backwards less than 3 hours (DST ends): just run wildcard jobs, skip fixed-schedule jobs since they have already run. Relevant source is at lines 247--258:

/*
 * case 3: timeDiff is a small or medium-sized
 * negative num, eg. because of DST ending just run
 * the wildcard jobs. The fixed-time jobs probably
 * have already run, and should not be repeated
 * virtual time does not change until we are caught up
 */
Debug(DSCH, ("[%d], DST ends %d minutes to go\n",
    getpid(), virtualTime - timeRunning))
find_jobs(timeRunning, &database, TRUE, FALSE);
break;

So, when entering DST, you should have no problem: your script will be run (either just before, or immediately after the time leap).

When exiting DST, there is a risk that your (fixed-time) job will be skipped, if you schedule it exactly at 1 o'clock. My suggestion would be to schedule the run either 1 minute before 1 o'clock, or at 2 o'clock (or after).

Ubuntu – How to migrate to UTC hardware clock

Edit the file /etc/default/rcS with your favorite text editor, ie:

sudo nano /etc/default/rcS

enter image description here

Look for the UTC=foo (yes/no) line and change it to UTC=yes.

From the rcS(5) man page:

UTC
This is used to govern how the hardware real time clock is interpreted when it is read (e.g., at boot time, for the purpose of setting the system clock) and when it is written (e.g., at shutdown). If this option is set to no then the system clock is assumed to be set to local time. If the option is set to yes then the system clock is assumed to be set to something approximating Coordinated Universal Time (UTC). (POSIX systems keep a variant of UTC, without leap seconds.)

Best Answer

Related Solutions

Ubuntu – How to use cron to schedule a script that implements daylight saving on a non- DST aware application when the server automatically uses DST

Ubuntu – How to migrate to UTC hardware clock

Related Question