[systemd-devel] /etc/systemd/system/darkice.service

[Lennart Poettering]

On Thu, 18.07.13 14:34, Tom Gundersen (teg at jklm.no) wrote:

> 
> On Thu, Jul 18, 2013 at 2:27 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Thu, 18.07.13 18:01, Kai Hendry (hendry at iki.fi) wrote:
> >> [root at pihsg ~]# systemctl status darkice.service
> >> darkice.service - DarkIce audio forwarder
> >>    Loaded: loaded (/etc/systemd/system/darkice.service; enabled)
> >>    Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08
> >> SGT; 43 years 6 months ago
> >
> > The timestamp looks weird. Does the device have no RTC or so?
> 
> Yeah, the RPi does not have an RTC.

Which reminds me that people suggested we should maybe add a simple
logic to systemd that during shutdown we should invoke
utimensat(clock_gettime(CLOCK_REALTIME)) on some file in /var/, and
during boot-up we should set the realtime clock from that if it is set
to a date earlier than that or so... That way time will monotonically
increase even across reboots, and even without network around, which is
useful in particular during boot up, and not constantly restart from
1970 again on each boot. For machines that are more often on than off
the accuracy might be good enough so that NTP never has to resort to
making the time jump abruptly.

If somebody wants to work on this: this should probably take inspiration
from the random seed service which is started after /var is up and
stopped before /var goes down. I figure embedded devices are the most
likely to use a split off /var (because of read-only /), so this
ordering is a must to ensure that we check for the file at the right
time.

In the cases where /var is not split off it might be a good idea to
apply the jump even earlier, from PID1 before the first unit is forked
off, so that userspace outside of PID 1 *never* has to see weird 1970
dates. Hence it would be a good choice to do the threshold-based RTC
jump logic twice: once in PID 1 in some code like
src/core/{hostname,loopback,machine-id,mount}-setup.c and once in that
random-seed-like unit that runs after /var is found. The threshold logic
should make sure we do not make the time jump twice. And of course if
the file is not found then this should not cause an error but should be
silently ignored.

A nice side effect of this is that even on systems which have an RTC
we'd always correct them at least to the date the OS image you run was
created at.

The stuff of course should be compile-time optional.

If somebody wants to work on this, I'd be happy to take the patch. If
figure this should be < 50 lines or so.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.