[systemd-devel] [ANNOUNCE] systemd 216

[Lennart Poettering]

On Wed, 20.08.14 06:43, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> 
> В Wed, 20 Aug 2014 02:59:52 +0200
> Lennart Poettering <lennart at poettering.net> пишет:
> 
> > Heya!
> > 
> > This is a major new release. Among many other changes systemd-resolved
> > is now a pretty complete caching DNS and LLMNR stub resolver.
> > 
> > http://www.freedesktop.org/software/systemd/systemd-216.tar.xz
> > 
> > CHANGES WITH 216:
> > 
> >         * timedated no longer reads NTP implementation unit names from
> >           /usr/lib/systemd/ntp-units.d/*.list. Alternative NTP
> >           implementations should add a
> > 
> >             Conflicts=systemd-timesyncd.service
> > 
> >           to their unit files to take over and replace systemd's NTP
> >           default functionality.
> > 
> 
> Does it mean any alternative service should also declare
> Alias=systemd-timesyncd.service? This is what timedated checks to
> answer whether NTP is enabled.

No. The simple fact is timedated cannot be used to turn on/off any other
implementation that timesycnd. 

The idea here is that if people bother to install ntpd or chrony, than
they do that knowingly and actively, and that it should always take
precedence, but is generally an act an admin does, not a normal
user. Hence no need for timedated to cover it, but we still want
timesyncd to be kicked out of the initial transaction in that case.

Alias=s-t.s wouldn't work anyway, since that's part of [Install] and
hence only relevant after a unit got enabled. timedated enabler code
would hence never find it as canidate to enable since it would have to
be enabled to be discoverable, if you follow what I mean...

> > 
> >         * systemd will no longer inform the kernel about the current
> >           timezone, as this is necessarily incorrect and racy as the
> >           kernel has no understanding of DST and similar
> >           concepts. This hence means FAT timestamps will be always
> >           considered UTC, similar to what Android is already
> >           doing. Also, when the RTC is configured to the local time
> >           (rather than UTC) systemd will never synchronize back to it,
> >           as this might confuse Windows at a later boot.
> > 
> 
> I do not know how often Android users need to exchange data with
> Windows via USB stick, but I have to do it pretty often and it sounds
> like now my timestamps will be wrong. Could you please name commit that
> does it? The only one I can find close to it
> (c264aeab4b0e7b69f469e12e78d4a48b3ed7a66e) says actually
> 
> "core: only set the kernel's timezone when the RTC runs in local time"
> 
> which is quite different.

No, that's the one.

Lennart

-- 
Lennart Poettering, Red Hat