Bug#755722: systemd must sync systemclock to RTC on shutdown

[Josh Triplett]

On Tue, Feb 17, 2015 at 12:52:20AM +0100, Michael Biebl wrote:
> Am 17.02.2015 um 00:27 schrieb Josh Triplett:
> > On Mon, 16 Feb 2015 16:41:21 +0100 Martin Pitt <mpitt at debian.org> wrote:
> >> For jessie+1/experimental onward, we'll fix this properly by enabling
> >> timesyncd by default. It won't start if ntp or similar are installed.
> >> This will make sure that the hw clock will be updated often enough,
> >> and we won't poke false data into it:
> >>
> >>   http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=929bece5326
> > 
> > Using ConditionFileIsExecutable on specific NTP daemons seems odd here.
> > Doesn't systemd already have a mechanism for choosing from multiple
> > alternative implementations of a given feature, automatically running
> > only one of them?  If not, perhaps it should; that same mechanism would
> > then work for display managers, web servers, etc.
> 
> Sort of. The plan here is, that the individual ntp implementations ship
> a native systemd unit file, which has
> Conflicts=systemd-timesyncd.service [1]
> 
> This will make sure, that if e.g. ntp is installed and enabled, ntp will
> be used instead of systemd-timesyncd.
> 
> None of the ntp implementations currently ship such a native unit file
> though, that's why we decided to add such a Condition to the
> systemd-timesyncd.service unit file for the time being.
> 
> There were concerns that adding this Conflicts to every time
> synchronization service is a questionable approach [2].

Seems like systemd could take a lesson from Debian packaging metadata
here.  Every mail transport agent, rather than conflicting with every
other, has a "Provides: mail-transport-agent" and "Conflicts:
mail-transport-agent", specifically because they all want to provide
/usr/sbin/sendmail and (usually) listen on port 25.

Unit files could do something similar, if systemd had an appropriate
"virtual service" mechanism.  That would then allow the simultaneous
installation of several services that need a conflicting set of
resources (for instance, several services that all need to listen on the
same port), leaving it to the sysadmin to determine which one to enable,
and automatically disabling all the rest.  Some integration with
Debian's alternative mechanism could ensure that the currently enabled
listener on port 25 always matches the provider of /usr/sbin/sendmail.

Time synchronization services need to conflict as well, not necessarily
because they all listen on the same port, but because they all want to
control the system clock, and only one should do so.  A simple "named
resource" mechanism, and some collaboration to agree on common names for
such resources (similar to names for virtual packages) would solve that.

Likewise, display managers could all coexist and install appropriate
unit files, but provide and conflict with a virtual service representing
their control of the display, forcing at most one to run at once.

Does that sound plausible?

- Josh Triplett