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

[Josh Triplett]

On Tue, Feb 17, 2015 at 06:59:15AM +0100, Martin Pitt wrote:
> Josh Triplett [2015-02-16 21:49 -0800]:
> > > It does, it's called "Alias=" (man systemd.unit).
> > 
> > Can Alias work together with Conflicts on that alias, such that each of
> > several services all Alias a given virtual service and Conflicts with
> > other providers of that service?  If so, what about using that for
> > systemd-timesyncd and all of the other time services, at least once they
> > all have native service files?
> 
> That's certainly the idea, yes. The Alias= mechanism works a bit
> differently than Provides: on a packaging level; e. g. it must be
> possible to have several of them installed in parallel. So AFAIK
> packages which use this schema need to either systemctl disable
> <aliasname> first (if they want to set itself as the "selected
> alternative") or not enable itself at all (if they are not the
> "selected alternative").

With a bit of machinery tied into the alternatives mechanism, perhaps
"which of several concurrently installed units are enabled" could be
more easily admin-controllable?

> > > We use it for display-manager already (kind of, as we also have to
> > > support the old /etc/X11/default-display-manager config file).
> > 
> > Also, post-jessie, do you have any plans to do a one-time migration away
> > from that display manager configuration file, similar to the various
> > one-time migrations away from sysvinit-specific config files like
> > /etc/default/rcS?
> 
> I wish we could. But don't forget that we still have to support at
> least SysVinit and perpaps even more (openrc? upstart?). As long as we
> have those, we probably have to keep these uber-complex mechanisms
> like systemd-default-display-manager-generator which sync these
> config files with the systemd unit enablement.

Just because we support other init systems, and migrate user
configuration from those init systems, doesn't necessarily mean the
configuration files have to remain the *same*.  It'd be easy enough to
do a one-time migration of the current value in
/etc/X11/default-display-manager to the set of enabled .service files
for display managers, and let the user know that future changes to that
file will not have any further effect.

Similarly, the current setting in /etc/default/tmpfs for whether to
mount a tmpfs on /tmp gets migrated to
/etc/systemd/system/local-fs.target.wants/tmp.mount , but future changes
to /etc/default/tmpfs have no effect, and that file will one day go away
when systemd no longer depends on initscripts.

(I also have hopes that one day, the sysvinit unit generator can live in
a separate package that systemd just Suggests but does not Depends on.)

- Josh Triplett