Debian Bug report logs - #755722
systemd must sync systemclock to RTC on shutdown

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ralf Jung <post@ralfj.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: systemd: Warning on each reboot: Superblock last write time is in the future

Date: Tue, 22 Jul 2014 20:27:40 +0200

[Message part 1 (text/plain, inline)]

Package: systemd
Version: 208-6
Severity: normal

Dear Maintainer,

each time I do a (warm) system reboot, I get messages like the following
(copied from journalctl):

  Jul 22 19:46:24 r-schnelltop systemd-fsck[542]: homefs: Superblock last write time is in the future.
  Jul 22 19:46:24 r-schnelltop systemd-fsck[542]: (by less than a day, probably due to the hardware clock being incorrectly set).  FIXED.
  Jul 22 19:46:26 r-schnelltop systemd-fsck[542]: homefs: 362146/4587520 files (0.9% non-contiguous), 9175569/18350080 blocks

As a result of this (or so I think), checking homefs takes ~2s (on a really
fast SSD), which significantly delays the boot process.

When I boot the machine in the morning (after it was turned off over
the night), I do usually not see this error.

This is happening for, I think, around 2 months now. I usually don't reboot,
so I am not entirely sure.

The log mentions the hardware clock, so I checked that and indeed:

  $ sudo hwclock -r ; date                                                                                                                                                                                        
  Tue 22 Jul 2014 20:13:22 CEST  -0.235161 seconds                                                                                                                                                                                             
  Tue 22 Jul 20:14:53 CEST 2014

The hardware clock is off by around 1.5 minutes. (Whatever hwclock
tries to tell me with that time delta, I don't know^^.)

My interpretation of the issue is that the hardware clock is not written
back properly on shutdown anymore. Thus it got out of sync, and thus
fsck is complaining on boot. Based on this guess and the fact that
systemd masks the hwclock init scripts (and thus seemingly takes
responsibility for this task), I conclude that this is probably
a bug in systemd. But that's pure guesswork on my side. I also
wouldn't know which other package to report this against ;-)

Kind regards
Ralf

-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.15.3 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl                  2.2.52-1
ii  adduser              3.113+nmu3
ii  initscripts          2.88dsf-53.2
ii  libacl1              2.2.52-1
ii  libaudit1            1:2.3.7-1
ii  libblkid1            2.20.1-5.8
ii  libc6                2.19-7
ii  libcap2              1:2.22-1.2
ii  libcap2-bin          1:2.22-1.2
ii  libcryptsetup4       2:1.6.4-4
ii  libdbus-1-3          1.8.6-1
ii  libgcrypt11          1.5.3-4
ii  libkmod2             18-1
ii  liblzma5             5.1.1alpha+20120614-2
ii  libpam0g             1.1.8-3
ii  libselinux1          2.3-1
ii  libsystemd-daemon0   208-6
ii  libsystemd-journal0  208-6
ii  libsystemd-login0    208-6
ii  libudev1             208-6
ii  libwrap0             7.6.q-25
ii  sysv-rc              2.88dsf-53.2
ii  udev                 208-6
ii  util-linux           2.20.1-5.8

Versions of packages systemd recommends:
ii  libpam-systemd  208-6

Versions of packages systemd suggests:
ii  systemd-ui  3-2

-- no debconf information

[systemd-delta.txt (text/plain, attachment)]

[systemd-analyze-dump.txt (text/plain, attachment)]

[dsh-enabled.txt (text/plain, attachment)]

[fstab (text/plain, attachment)]

Message #10 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Ralf Jung <post@ralfj.de>, 755722@bugs.debian.org

Subject: Re: Bug#755722: systemd: Warning on each reboot: Superblock last write time is in the future

Date: Tue, 22 Jul 2014 21:25:43 +0200

Hi Ralf,

Ralf Jung <post@ralfj.de> writes:
>   $ sudo hwclock -r ; date                                                                                                                                                                                        
>   Tue 22 Jul 2014 20:13:22 CEST  -0.235161 seconds                                                                                                                                                                                             
>   Tue 22 Jul 20:14:53 CEST 2014
>
> The hardware clock is off by around 1.5 minutes. (Whatever hwclock
> tries to tell me with that time delta, I don't know^^.)
Install “ntp” and the problem will be fixed.

systemd intentionally does not sync the system clock to the hwclock, see
http://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html

-- 
Best regards,
Michael

Message #15 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Ralf Jung <post@ralfj.de>

To: Michael Stapelberg <stapelberg@debian.org>, 755722@bugs.debian.org

Subject: Re: Bug#755722: systemd: Warning on each reboot: Superblock last write time is in the future

Date: Tue, 22 Jul 2014 22:00:54 +0200

Hi,

> Ralf Jung <post@ralfj.de> writes:
>>   $ sudo hwclock -r ; date                                                                                                                                                                                        
>>   Tue 22 Jul 2014 20:13:22 CEST  -0.235161 seconds                                                                                                                                                                                             
>>   Tue 22 Jul 20:14:53 CEST 2014
>>
>> The hardware clock is off by around 1.5 minutes. (Whatever hwclock
>> tries to tell me with that time delta, I don't know^^.)
> Install “ntp” and the problem will be fixed.

I already have "ntpdate" and KDE is set up to sync my clock via NTP.
That's working fine, "date" is accurate (As far as I recall, KDE uses
ntpdate to do this update).
According to the ntpdate description, this is exactly the tool I want
for a machine that doesn't have internet all the time, like my laptop.
It's nicely hooked into the if-up scripts.

> systemd intentionally does not sync the system clock to the hwclock, see
> http://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html

Weird. This is IMHO a regression, and a fairly subtle one as well.
I also don't see any good reasons for this, even after reading the mail
you linked to (quoting below - yes I am aware that it's not you who
wrote that, but I just absolutely cannot follow Lennart's arguments here).

> In general there's not really a
> reason to assume that the system clock was anymore correct than the RTC
> so it's probably a good idea to leave the RTC untouched.

I think that's just wrong. The system clock is the one users see, they
will change it when it's wrong or check whatever is necessary to
auto-update it. You cannot reasonably expect users to even know that any
other clock even exists.

> And if the
> user changes the system clock manually it's his duty to sync that
> through to the RTC, and if he doesn't then he probably has a reason
> to.

I'd argue, if he doesn't he probably doesn't know there's such a thing
as an "RTC".


So it seems ntp does some magic to trigger the writeback. It will also
open a daemon to let others sync with my machine, certainly not
something I want. I will try it, but I don't see how that's a proper fix
for the problem, it's more like a work-around (or systemd should
Recommend ntp).

From all I know, ntp is not in a Debian default installation. Having
around half the Debian systems (those where the RTC is behind the actual
time) with this bug is certainly not an acceptable state (I hope we
agree on this). So how do you think this should be fixed? If you don't
want to deviate from upstream systemd (which I can understand), and
cannot convince Lennart to change his mind (which I'd be surprised to
see happening ;-), I could see ntpdate updating the RTC after fetching
the current time. That will still leave everybody using "date" to fix
his clock affected (or does date already trigger a writeback?).

Kind regards
Ralf

Message #20 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Jon Severinsson <jon@severinsson.net>

To: 755722@bugs.debian.org

Subject: Re: systemd: Warning on each reboot: Superblock last write time is in the future

Date: Wed, 23 Jul 2014 23:46:57 +0200

Control: reassign -1 ntpdate
Control: retitle -1 ntpdate does not set the RTC when syncing the system clock

>> systemd intentionally does not sync the system clock to the hwclock, see
>> http://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html

> Weird. This is IMHO a regression, and a fairly subtle one as well.
> I also don't see any good reasons for this, even after reading the mail
> you linked to (quoting below - yes I am aware that it's not you who
> wrote that, but I just absolutely cannot follow Lennart's arguments here).

>> In general there's not really a
>> reason to assume that the system clock was anymore correct than the RTC
>> so it's probably a good idea to leave the RTC untouched.

> I think that's just wrong. The system clock is the one users see, they
> will change it when it's wrong or check whatever is necessary to
> auto-update it. You cannot reasonably expect users to even know that any
> other clock even exists.

If the user sets or syncs the clock, it is indeed reasonable to expect it to 
persist, but the text you are quoting regards the case of a user *not* 
touching the clock in any way.

In that case the only difference between the system clock and the RTC is that 
they might tick at slightly different paces, and there is nothing to say that 
the (software) system clock had a more accurate pace than the (hardware) RTC, 
which is why systemd does not overwrite the RTC with the system clock at 
shutdown.

That said, anything that changes the system clock based on an authoritative 
source (eg user input or network sync, as opposed to drift calculation or 
other heuristics) should usually set both the system clock and RTC, as I agree 
that users shouldn't be expected to know about the difference.

> [ntp] will also open a daemon to let others sync with my machine, certainly
> not something I want.

By default ntp only listens on 127.0.0.1 (for control commands), and will not 
allow other systems to sync with it, so it is not as bad as you think.

In most cases a system that are connected to the Internet for any length of 
time (even if not constantly) should use a continuously syncing daemon like 
ntp (or the upcoming systemd-timesyncd) rather than a oneshot program like 
ntpdate, in order to *stay* synced while connected.

> Having around half the Debian systems (those where the RTC is behind the
> actual time) with this bug is certainly not an acceptable state.

Agreed.

> So how do you think this should be fixed? [...] I could see ntpdate updating
> the RTC after fetching the current time.

That would indeed be the proper fix, so reassigning this bug to ntpdate.

(The fact that hwclock has historically papered over this bug should not be 
used as an argument for forcing systemd to similarly paper over it, as bugs 
should generally be fixed at their source.)

Best regards
Jon Severinsson

Message #31 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: 755722@bugs.debian.org

Cc: Jon Severinsson <jon@severinsson.net>, pkg-systemd-maintainers@lists.alioth.debian.org, pkg-ntp-maintainers@lists.alioth.debian.org

Subject: Re: [pkg-ntp-maintainers] Processed: Re: systemd: Warning on each reboot: Superblock last write time is in the future

Date: Thu, 24 Jul 2014 00:02:09 +0200

reassign -1 systemd-sysv
thanks

I strongly disagree that ntpdate or ntp should be setting the RTC.
ntp doesn't know anything about the RTC, nor should it know
anything about it.  It's only concerned with the system clock.

So what we have now:
Reading:
- kernel
- init
- user manually

Writing:
- kernel
- user manually

It seems only logical that the writing should also be done by
init, like it always has.


Kurt

Message #38 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Jon Severinsson <jon@severinsson.net>

To: Kurt Roeckx <kurt@roeckx.be>, 755722@bugs.debian.org

Subject: Re: [pkg-ntp-maintainers] Processed: Re: systemd: Warning on each reboot: Superblock last write time is in the future

Date: Thu, 24 Jul 2014 04:30:48 +0200

torsdag 24 juli 2014 00:02:09 skrev du:
> reassign -1 systemd-sysv
> thanks
> 
> I strongly disagree that ntpdate or ntp should be setting the RTC.
> ntp doesn't know anything about the RTC, nor should it know
> anything about it.  It's only concerned with the system clock.

ntp already do set the RTC (or more accurately, tells the kernel to do so), it 
is only ntpdate that doesn't.

> It seems only logical that the writing should also be done by
> init, like it always has.

sysvinit has never read from, nor written to, the RTC, and only recently did 
systemd start reading from the RTC, in order to get a reasonably accurate 
system clock before starting any services that might rely on that.

Under sysvinit  hwclock from util-linux used to read the RTC and overwrite the 
system clock partway through the boot, and then overwrite the RTC with the 
system clock partway through the shutdown.

As a result, hwclock would override the RTC on every clean shutdown, even 
though dedicated HW are often less inaccurate than the software system clock. 
Additionally there was a risk of loosing an accurate time sync in the event of 
an unclean shutdown.

Systemd upstream is generally not satisfied with this sort of half-measures, 
and aims to get rid of them as soon as a better solution is made available.  
As both the main ntp daemon and the new systemd-timesyncd daemon do write to 
the RTC whenever they acquire an accurate time, the traditional band-aid at 
shutdown where deemed unnecessary, and so they naturally removed it.

As suitable alternatives are available I do not find it warranted to override 
upstream on this.  But if you are not interest in working on fixing the issue 
from your side we can simply add a Breaks: on ntpdate in systemd instead.

Please let me know how you would like me to proceed.

Regards
Jon Severinsson

Message #43 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Jon Severinsson <jon@severinsson.net>

Cc: 755722@bugs.debian.org

Subject: Re: [pkg-ntp-maintainers] Processed: Re: systemd: Warning on each reboot: Superblock last write time is in the future

Date: Sun, 27 Jul 2014 19:22:13 +0200

On Thu, Jul 24, 2014 at 04:30:48AM +0200, Jon Severinsson wrote:
> torsdag 24 juli 2014 00:02:09 skrev du:
> > reassign -1 systemd-sysv
> > thanks
> > 
> > I strongly disagree that ntpdate or ntp should be setting the RTC.
> > ntp doesn't know anything about the RTC, nor should it know
> > anything about it.  It's only concerned with the system clock.
> 
> ntp already do set the RTC (or more accurately, tells the kernel to do so), it 
> is only ntpdate that doesn't.

ntp does not tell the kernel to do so.  The kernel does so when 
it the clock is synchronized.  That is when the status !=
STA_UNSYNC.  But it is true that only ntpd sets this and not
ntpdate.  I'm not sure it's a good idea to set this in something
like ntpdate or since it might only runs once.  The current
implementation only seems to be doing this after an adjtimex()
call.

> > It seems only logical that the writing should also be done by
> > init, like it always has.
> 
> sysvinit has never read from, nor written to, the RTC, and only recently did 
> systemd start reading from the RTC, in order to get a reasonably accurate 
> system clock before starting any services that might rely on that.
> 
> Under sysvinit  hwclock from util-linux used to read the RTC and overwrite the 
> system clock partway through the boot, and then overwrite the RTC with the 
> system clock partway through the shutdown.

I don't care that init itself didn't read it.  But as part of the
boot controlled by init it did get read and it got written
during shutdown.  But now by systemd it's only in case op boot.

> As a result, hwclock would override the RTC on every clean shutdown, even 
> though dedicated HW are often less inaccurate than the software system clock. 

[citation needed]

> Additionally there was a risk of loosing an accurate time sync in the event of 
> an unclean shutdown.

I assume that in case of an unclean shutdown it didn't get
written, and so because the old system might in some cases not
write the time we're now never going to write it?

> Systemd upstream is generally not satisfied with this sort of half-measures, 
> and aims to get rid of them as soon as a better solution is made available.  
> As both the main ntp daemon and the new systemd-timesyncd daemon do write to 
> the RTC whenever they acquire an accurate time, the traditional band-aid at 
> shutdown where deemed unnecessary, and so they naturally removed it.

I don't even find timesyncd in Debian?  It seems to be new since
213?

> As suitable alternatives are available I do not find it warranted to override 
> upstream on this.  But if you are not interest in working on fixing the issue 
> from your side we can simply add a Breaks: on ntpdate in systemd instead.

That makes no sense at all.  ntpdate doesn't break anything.  If
you're not willing to fix it you should instead Depend on whatever
is needed not to break things.


Kurt

Message #48 received at 755722@bugs.debian.org (full text, mbox, reply):

From: "Eric L." <ewl+debian+nospam2014@lavar.de>

To: 755722@bugs.debian.org

Subject: Not having a hwclock systohc and back is not only an NTP issue

Date: Sun, 26 Oct 2014 09:27:43 +0100

Hello,

I tried to follow your discussion, and I want to add a new use case to 
having a generic solution, independent of NTP:

My problem is a VDR system where I need to have the HW clock set to 
LOCAL (not UTC).
No continuous network access, hence no NTP.
VDR itself is setting the (system) clock based on the time provided by 
the TV-transponder
Today was summer to winter time switching, so the clock made a big jump 
backwards and the (TV) system doesn't like it and freezes.
No issue, restart the system and start again, right? Actually, no, 
because the system clock isn't saved to the HW clock anymore, you start 
the cycle again and again.

So, summary:
- the world is not perfect
- there are many places where the time can be switched, not only through 
NTP.
- the hwclock mechanism was perhaps a workaround, but it worked for all 
of us for many years
- so make sure that something works for all of us is put in place before 
removing it

Thanks, Eric

Message #53 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Ivan Baldo <ibaldo@adinet.com.uy>

To: 755722@bugs.debian.org

Subject: Re: ntpdate does not set the RTC when syncing the system clock

Date: Sun, 25 Jan 2015 01:52:47 -0200

    Hello.
    Kurt Roeckx wrote:
> ntp does not tell the kernel to do so.  The kernel does so when
> it the clock is synchronized.  That is when the status !=
> STA_UNSYNC.  But it is true that only ntpd sets this and not
> ntpdate.  I'm not sure it's a good idea to set this in something
> like ntpdate or since it might only runs once.  The current
> implementation only seems to be doing this after an adjtimex()
> call.
    I don't understand why it isn't a good idea to do it in ntpdate.
    Doesn't ntpdate get an accurate time at the moment it runs that 
should be more accurate than the RTC?
    Sorry, I am not an expert though I would like to know why that is a 
bad idea.
    Thanks for your info!
    Have a nice day!

-- 
Ivan Baldo - ibaldo@adinet.com.uy - http://ibaldo.codigolibre.net/
From Montevideo, Uruguay, at the south of South America.
Freelance programmer and GNU/Linux system administrator, hire me!
Alternatives: ibaldo@codigolibre.net - http://go.to/ibaldo

Message #58 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: 755722@bugs.debian.org, control@bugs.debian.org

Subject: systemd must sync systemclock to RTC on shutdown

Date: Sat, 31 Jan 2015 10:19:29 +0100

severity 755722 serious
retitle 755722 systemd must sync systemclock to RTC on shutdown
thanks


Systemd must make sure that the system clock does not go backwards, 
which causes all kinds of problems, with file systems and with other 
software. To achieve that, systemd has to sync the system time to RTC 
on shutdown. Upstream's argument that the system time may not be more 
accurate is completely unrelated to this issue.

Message #67 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Stefan Fritsch <sf@sfritsch.de>, 755722@bugs.debian.org

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

Date: Wed, 04 Feb 2015 01:41:14 +0100

[Message part 1 (text/plain, inline)]

Am 31.01.2015 um 10:19 schrieb Stefan Fritsch:
> severity 755722 serious
> retitle 755722 systemd must sync systemclock to RTC on shutdown
> thanks
> 
> 
> Systemd must make sure that the system clock does not go backwards, 
> which causes all kinds of problems, with file systems and with other 
> software. To achieve that, systemd has to sync the system time to RTC 
> on shutdown. Upstream's argument that the system time may not be more 
> accurate is completely unrelated to this issue.

Upstream argues, that whoever changes the clock, should also make sure
to sync that to the RTC if so desired. E.g. if you change the time using
the builtin timedatectl command, it will make sure the RTC is synced.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #72 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: Michael Biebl <biebl@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Wed, 04 Feb 2015 06:00:52 +0100

On Wednesday 04 February 2015 01:41:14, Michael Biebl wrote:
> Am 31.01.2015 um 10:19 schrieb Stefan Fritsch:
> > severity 755722 serious
> > retitle 755722 systemd must sync systemclock to RTC on shutdown
> > thanks
> > 
> > 
> > Systemd must make sure that the system clock does not go
> > backwards,
> > which causes all kinds of problems, with file systems and with
> > other software. To achieve that, systemd has to sync the system
> > time to RTC on shutdown. Upstream's argument that the system time
> > may not be more accurate is completely unrelated to this issue.
> 
> Upstream argues, that whoever changes the clock, should also make
> sure to sync that to the RTC if so desired. E.g. if you change the
> time using the builtin timedatectl command, it will make sure the
> RTC is synced.

There is also natural drift between the system clock and the RTC. Who 
is supposed to account for that? On a system with an uptime of several 
months, the drift may be large enough to cause the time to go 
backwards at a reboot.

NB: Upstream should try not to break existing software. The sysv init 
script compatibility is mostly moot if the init scripts need to be 
adjusted because of semantic changes.

Message #79 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 755722@bugs.debian.org

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

Date: Tue, 10 Feb 2015 09:56:28 +0100

Control: severity -1 normal

Stefan Fritsch [2015-01-31 10:19 +0100]:
> severity 755722 serious
> retitle 755722 systemd must sync systemclock to RTC on shutdown

This is severity inflation according to
https://www.debian.org/Bugs/Developer#severities ; adjusting back to
original severity.

I also disagree with the retitling, FTR.

> Systemd must make sure that the system clock does not go backwards,
> which causes all kinds of problems, with file systems and with other
> software. To achieve that, systemd has to sync the system time to
> RTC on shutdown.

I disagree. As the discussion showed, it is in no way clear why the
system time should be more accurate than the hardware clock; on most
hardware it will be the other way around.

IMHO the only proper time to write the hardware clock is when we know
the system time is correct, i. e. after an NTP sync or when the user
sets it manually.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #86 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Fri, 13 Feb 2015 00:09 +0100

You really should CC the the submitter when responing.

On Tuesday 10 February 2015 09:56:28, Martin Pitt wrote:
> Control: severity -1 normal
> 
> Stefan Fritsch [2015-01-31 10:19 +0100]:
> > severity 755722 serious
> > retitle 755722 systemd must sync systemclock to RTC on shutdown

> This is severity inflation according to
> https://www.debian.org/Bugs/Developer#severities ; adjusting back to
> original severity.

No. It breaks other software, like fsck and make. I would call make an 
unrelated package which would make severity critical appropriate.

> I also disagree with the retitling, FTR.
> 
> > Systemd must make sure that the system clock does not go
> > backwards,
> > which causes all kinds of problems, with file systems and with
> > other software. To achieve that, systemd has to sync the system
> > time to RTC on shutdown.
> 
> I disagree. As the discussion showed, it is in no way clear why the
> system time should be more accurate than the hardware clock; on most
> hardware it will be the other way around.

I don't deny that. But monotonic time is more important than accurate 
time. You have not commented on that in any way.

On long running systems, even if nothing modifies the system clock the 
normal drift between system time and RTC can cause the system time to 
go backwards when the system is rebooted. Therefore the system time 
must be synced to the RTC on shutdown.

> IMHO the only proper time to write the hardware clock is when we
> know the system time is correct, i. e. after an NTP sync or when
> the user sets it manually.

Message #91 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Fri, 13 Feb 2015 06:44:06 +0100

On Friday 13 February 2015 00:09:00, Stefan Fritsch wrote:
> > IMHO the only proper time to write the hardware clock is when we
> > know the system time is correct, i. e. after an NTP sync or when
> > the user sets it manually.

Even if it is decided that this is right, this would require fixing in 
quite a lot of packages. From a quick search, at least these

alevt (alevt-date)
dvb-apps (dvbdate)
netdate
tlsdate
htpdate
ntpdate

seem to be affected. Therefore, changing systemd's behavior at least 
for jessiee makes sense in any case.

Message #96 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: 755722@bugs.debian.org

Cc: control@bugs.debian.org

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

Date: Fri, 13 Feb 2015 07:13:15 +0100

[Message part 1 (text/plain, inline)]

severity 755722 grave
thanks

The attached service file (from [1]) seems to work if put into 
/etc/systemd/system/hwclock.service and enabled with

systemctl enable hwclock

Please include it in the package.

Note that I will escalate this to the TC if you downgrade the severity 
of this bug again without very good reason. And repeating some old 
statement from upstream is NOT a good reason.


[1] https://bugs.archlinux.org/task/31674

[hwclock.service (text/plain, attachment)]

Message #103 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Stefan Fritsch <sf@sfritsch.de>

Cc: 755722@bugs.debian.org

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

Date: Fri, 13 Feb 2015 07:54:11 +0100

[Message part 1 (text/plain, inline)]

Control: reassign -1 util-linux 2.25.2-5
Control: severity -1 normal

I still disagree with critical:

 - If the hardware clock is so broken that at the next boot it has an
   earlier time than on the previous boot/ntpdate, then writing it
   once more at shutdown isn't going to entirely fix this problem, as
   it will again go sufficiently wrong if you don't reboot immediately
   but after some time.

 - Second, this doesn't "break" fsck: fsck already correctly notices
   that the last write time is in the future and handles that
   appropriately; at least that's what the original reporter
   mentioned.

Also, under sysvinit and upstart it is util-linux which does the
hwclock <-> sysclock dance, thus reassigning this. We shouldn't
put this logic into different packages for different init systems.

I also disagree this should be done in the first place. But I don't
want to put myself into eternal wars and "who shouds the loudest
wins", so I'll keep this bug open and won't make any further
Severity: adjustments.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[signature.asc (application/pgp-signature, inline)]

Message #114 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Stefan Fritsch <sf@sfritsch.de>, 755722@bugs.debian.org

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

Date: Fri, 13 Feb 2015 08:06:03 +0100

[Message part 1 (text/plain, inline)]

Control: reassign -1 systemd 215-11

Martin Pitt [2015-02-13  7:54 +0100]:
> Also, under sysvinit and upstart it is util-linux which does the
> hwclock <-> sysclock dance, thus reassigning this. We shouldn't
> put this logic into different packages for different init systems.

Michael just pointed out that systemd masks /etc/init.d/hwclock.sh. We
indeed don't want to run this during startup, but that's why it
doesn't run on shutdown. So reassigning back, sorry for the noise.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[signature.asc (application/pgp-signature, inline)]

Message #125 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Roger Lynn <Roger@rilynn.me.uk>

To: Martin Pitt <mpitt@debian.org>, 755722@bugs.debian.org

Cc: Stefan Fritsch <sf@sfritsch.de>

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

Date: Fri, 13 Feb 2015 09:08:32 +0000

On 13/02/2015 06:54, Martin Pitt wrote:
> Control: severity -1 normal
> 
> I still disagree with critical:
> 
>  - If the hardware clock is so broken that at the next boot it has an
>    earlier time than on the previous boot/ntpdate, then writing it
>    once more at shutdown isn't going to entirely fix this problem, as
>    it will again go sufficiently wrong if you don't reboot immediately
>    but after some time.

A good hardware clock can easily lose many minutes over a year. A not
particularly bad one could lose an hour over a year and several minutes over
a month. That is not at all broken and will cause time to go backwards on
every reboot. Every machine with a hardware clock that does not run fast
will eventually run into this problem every time they reboot if the hardware
clock has not been written since installation, especially if they boot quickly.

The user can not easily monitor the status of the hardware clock and will
see that the time on the computer appears to be accurate. There is no reason
to assume that the hardware clock is more accurate when the user can only
monitor the system clock.

Roger

Message #130 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Fri, 13 Feb 2015 10:32:31 +0100 (CET)

On Fri, 13 Feb 2015, Martin Pitt wrote:
> Control: reassign -1 util-linux 2.25.2-5
> Control: severity -1 normal
> 
> I still disagree with critical:


> I also disagree this should be done in the first place. But I don't
> want to put myself into eternal wars and "who shouds the loudest
> wins", so I'll keep this bug open and won't make any further
> Severity: adjustments.

Can't you agree that the best way forward for jessie is to change this in 
systemd? Because

- Reboots may cause unneccessary fsck of all partitions
- fscks take much longer than necessary (systemd #778283)
- fscks cannot be interrupted (systemd #758902)

This is simply not acceptable for a Debian stable release. And it would 
require at least half a dozen packages to be changed, if not fixed in 
systemd. And even that would not fix all cases.

Once jessie is released, the correct long-term fix can be discussed in a 
more relaxed way.

Message #135 received at 755722@bugs.debian.org (full text, mbox, reply):

From: "Eric L." <ewl+debian+nospam2014@lavar.de>

To: 755722@bugs.debian.org

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

Date: Sun, 15 Feb 2015 10:24:01 +0100

Hi,

On 13/02/15 10:32, Stefan Fritsch wrote:
> Once jessie is released, the correct long-term fix can be discussed in a
> more relaxed way.
As a user impacted by this issue, I would like to second this motion! 
Most important is to have it work for the Debian users.

Thanks, Eric

-- 
I'm subscribed on debian-java, debian-mentors, pkg-java-maintainers and 
pkg-vdr-dvb-devel.
No need to CC me on these lists.

Message #140 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Stefan Fritsch <sf@sfritsch.de>

Cc: 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 07:55:41 +0100

Stefan Fritsch [2015-02-13 10:32 +0100]:
> Can't you agree that the best way forward for jessie is to change this in 
> systemd?

For jessie I'd be okay with this. I'd rather have the actual unit in
util-linux and then unmask it in systemd, but that'd require even more
coordination/uploads.

I'll discuss this with Michael today.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #145 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: Martin Pitt <mpitt@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 09:38:44 +0100 (CET)

On Mon, 16 Feb 2015, Martin Pitt wrote:

> Stefan Fritsch [2015-02-13 10:32 +0100]:
> > Can't you agree that the best way forward for jessie is to change this in 
> > systemd?
> 
> For jessie I'd be okay with this. I'd rather have the actual unit in
> util-linux and then unmask it in systemd, but that'd require even more
> coordination/uploads.
> 
> I'll discuss this with Michael today.

OK, thank you.

Message #150 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Stefan Fritsch <sf@sfritsch.de>, 755722@bugs.debian.org, 755722-submitter@bugs.debian.org

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

Date: Mon, 16 Feb 2015 16:00:36 +0100

[Message part 1 (text/plain, inline)]

Am 04.02.2015 um 06:00 schrieb Stefan Fritsch:
> On Wednesday 04 February 2015 01:41:14, Michael Biebl wrote:
>> Am 31.01.2015 um 10:19 schrieb Stefan Fritsch:
>>> severity 755722 serious
>>> retitle 755722 systemd must sync systemclock to RTC on shutdown
>>> thanks
>>>
>>>
>>> Systemd must make sure that the system clock does not go
>>> backwards,
>>> which causes all kinds of problems, with file systems and with
>>> other software. To achieve that, systemd has to sync the system
>>> time to RTC on shutdown. Upstream's argument that the system time
>>> may not be more accurate is completely unrelated to this issue.
>>
>> Upstream argues, that whoever changes the clock, should also make
>> sure to sync that to the RTC if so desired. E.g. if you change the
>> time using the builtin timedatectl command, it will make sure the
>> RTC is synced.
> 
> There is also natural drift between the system clock and the RTC. Who 
> is supposed to account for that? On a system with an uptime of several 
> months, the drift may be large enough to cause the time to go 
> backwards at a reboot.

Running hwclock --systohc on shutdown does not solve the time skew problem.
You could use hwclocks drift calculation and call hwclock --adjust e.g.
via a cron job. That is ugly though and it get's easily confused in
multi-boot environments.
A better alternative is NTP.
Incidentally, systemd ships systemd-timesyncd, a SNTP client, which can
easily be enabled via "systemctl enable systemd-timesyncd.service" and
we are discussing about shipping it enabled by default.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #158 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Stefan Fritsch <sf@sfritsch.de>, 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 16:41:21 +0100

[Message part 1 (text/plain, inline)]

Hello all,

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

This is a new feature though, and as such most probably not
appropriate for jessie at this point.

For master (i. e. testing/jessie), I prepared and tested the attached
patch. I'm still kind of hesitant to apply it as it's solving the
problem in a rather questionable, insufficient, and conceptually wrong
way. However, with that it would stay "bug compatible" with sysvinit
in jessie.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[0001-Add-hwclock.service-to-sync-the-system-clock-to-the-.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #163 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 755722@bugs.debian.org

Cc: Stefan Fritsch <sf@sfritsch.de>

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

Date: Mon, 16 Feb 2015 18:46:33 +0100

[Message part 1 (text/plain, inline)]

Martin Pitt [2015-02-16 16:41 +0100]:
> For master (i. e. testing/jessie), I prepared and tested the attached
> patch.

Slightly refined version 2 of the patch: renamed to
hwclock-save.service to not get mingled with util-linux'
hwclock.service.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[0001-Add-hwclock-save.service-to-sync-the-system-clock-to.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #168 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Stefan Fritsch <sf@sfritsch.de>

To: Michael Biebl <biebl@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 20:40:52 +0100

On Monday 16 February 2015 16:00:36, Michael Biebl wrote:
> > There is also natural drift between the system clock and the RTC.
> > Who  is supposed to account for that? On a system with an uptime
> > of several months, the drift may be large enough to cause the
> > time to go backwards at a reboot.
> 
> Running hwclock --systohc on shutdown does not solve the time skew
> problem.

It does not magically make the RTC run accurately. But it solves the 
problem of spurious fscks at reboot, doesn't it?

> You could use hwclocks drift calculation and call hwclock
> --adjust e.g. via a cron job. That is ugly though and it get's
> easily confused in multi-boot environments.
> A better alternative is NTP.
> Incidentally, systemd ships systemd-timesyncd, a SNTP client, which
> can easily be enabled via "systemctl enable
> systemd-timesyncd.service" and we are discussing about shipping it
> enabled by default.

I am not opposed to enabling timesyncd by default post-jessie. For 
jessie, I agree with the simpler fix posted by Martin.

I don't know what timesyncd does if no NTP server is reachable. It's 
possible that this case will need to be discussed again, but probably 
that discussion should happen in upstream's bug tracker.

Message #173 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 15:27:31 -0800

On Mon, 16 Feb 2015 16:41:21 +0100 Martin Pitt <mpitt@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.

- Josh Triplett

Message #178 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 755722@bugs.debian.org

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

Date: Tue, 17 Feb 2015 00:52:20 +0100

[Message part 1 (text/plain, inline)]

Am 17.02.2015 um 00:27 schrieb Josh Triplett:
> On Mon, 16 Feb 2015 16:41:21 +0100 Martin Pitt <mpitt@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].

Arguably, for ntp, chrony and openntpd, we can solve this on a packaging
level, by making those packages conflict.

If we want to enable timesyncd by default and keep it as a part of the
systemd package, this approach doesn't work, and we need the Conflicts=
on the systemd unit level.

Michael


[1] http://article.gmane.org/gmane.comp.sysutils.systemd.devel/22172
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1116369

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #183 received at 755722@bugs.debian.org (full text, mbox, reply):

From: "Eric L." <ewl+debian+nospam2014@lavar.de>

To: Michael Biebl <biebl@debian.org>,755722@bugs.debian.org

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

Date: Tue, 17 Feb 2015 01:24:02 +0100

Hi,

On 17 February 2015 00:52:20 CET, Michael Biebl <biebl@debian.org> wrote:
>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].
>
>Arguably, for ntp, chrony and openntpd, we can solve this on a
>packaging
>level, by making those packages conflict.
>
>If we want to enable timesyncd by default and keep it as a part of the
>systemd package, this approach doesn't work, and we need the Conflicts=
>on the systemd unit level.
Perhaps just a bit too late for me, but how would package vdr be handled, which does _optionally_ set the system clock from the TV signal.
Eric

-- 
I'm on debian-java, java maintainers, vdr maintainers and debian-mentors; no need to CC me on these lists. Thanks!

Message #188 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Michael Biebl <biebl@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 17:37:44 -0800

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@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

Message #193 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: "Eric L." <ewl+debian+nospam2014@lavar.de>, 755722@bugs.debian.org

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

Date: Tue, 17 Feb 2015 06:42:38 +0100

Hello Eric,

Eric L. [2015-02-17  1:24 +0100]:
> Perhaps just a bit too late for me, but how would package vdr be
> handled, which does _optionally_ set the system clock from the TV
> signal.

Note that not starting timesyncd if ntp etc. are installed is mostly
an optimization, to avoid multiple unnecessary time syncs and wakeups.
But we don't need to be exact here: timesyncd automatically adjusts
the period after which it wakes up and sets the clock based on the
previous inaccuracy. Thus if the clock keeps being correct because
something else sets it regularly, it will hardly ever wake up.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #198 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 755722@bugs.debian.org

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

Date: Tue, 17 Feb 2015 06:44:28 +0100

Hey Josh,

Josh Triplett [2015-02-16 17:37 -0800]:
> 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.

Note that openntpd and chrony both have a Provides: time-daemon, but
ntp doesn't.

> Unit files could do something similar, if systemd had an appropriate
> "virtual service" mechanism.

It does, it's called "Alias=" (man systemd.unit). We use it for
display-manager already (kind of, as we also have to support the old
/etc/X11/default-display-manager config file).

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #203 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Martin Pitt <mpitt@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 21:49:48 -0800

On Tue, Feb 17, 2015 at 06:44:28AM +0100, Martin Pitt wrote:
> Josh Triplett [2015-02-16 17:37 -0800]:
> > 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.
> 
> Note that openntpd and chrony both have a Provides: time-daemon, but
> ntp doesn't.

Interesting.  Any idea why?

> > Unit files could do something similar, if systemd had an appropriate
> > "virtual service" mechanism.
> 
> 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?

> 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?

- Josh Triplett

Message #208 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: Josh Triplett <josh@joshtriplett.org>

Cc: 755722@bugs.debian.org

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

Date: Tue, 17 Feb 2015 06:59:15 +0100

Josh Triplett [2015-02-16 21:49 -0800]:
> > Note that openntpd and chrony both have a Provides: time-daemon, but
> > ntp doesn't.
> 
> Interesting.  Any idea why?

No, I don't; probably just an omission. openntpd and chrony both have
an explicit Conflicts: ntp, though.

> > 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").

> > 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.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Message #213 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Martin Pitt <mpitt@debian.org>

Cc: 755722@bugs.debian.org

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

Date: Mon, 16 Feb 2015 22:10:12 -0800

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

Message #218 received at 755722-close@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 755722-close@bugs.debian.org

Subject: Bug#755722: fixed in systemd 219-1

Date: Tue, 17 Feb 2015 15:35:53 +0000

Source: systemd
Source-Version: 219-1

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 755722@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin Pitt <mpitt@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 17 Feb 2015 15:51:38 +0100
Source: systemd
Binary: systemd systemd-sysv libpam-systemd libsystemd0 libsystemd-dev libsystemd-login-dev libsystemd-daemon-dev libsystemd-journal-dev libsystemd-id128-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb libgudev-1.0-0 gir1.2-gudev-1.0 libgudev-1.0-dev python3-systemd systemd-dbg
Architecture: source amd64
Version: 219-1
Distribution: experimental
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Martin Pitt <mpitt@debian.org>
Description:
 gir1.2-gudev-1.0 - libgudev-1.0 introspection data
 libgudev-1.0-0 - GObject-based wrapper library for libudev
 libgudev-1.0-dev - libgudev-1.0 development files
 libpam-systemd - system and service manager - PAM module
 libsystemd-daemon-dev - systemd utility library (transitional package)
 libsystemd-dev - systemd utility library - development files
 libsystemd-id128-dev - systemd 128 bit ID utility library (transitional package)
 libsystemd-journal-dev - systemd journal utility library (transitional package)
 libsystemd-login-dev - systemd login utility library (transitional package)
 libsystemd0 - systemd utility library
 libudev-dev - libudev development files
 libudev1   - libudev shared library
 libudev1-udeb - libudev shared library (udeb)
 python3-systemd - Python 3 bindings for systemd
 systemd    - system and service manager
 systemd-dbg - system and service manager (debug symbols)
 systemd-sysv - system and service manager - SysV links
 udev       - /dev/ and hotplug management daemon
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 755722 757367 759489 769186 771980 773302 774012 778499
Changes:
 systemd (219-1) experimental; urgency=medium
 .
   [ Martin Pitt ]
   * New upstream release:
     - Fix spelling mistake in systemd.unit(5). (Closes: #773302)
     - Fix timeouts with D-Bus, leading to SIGFPE. (Closes: #774012)
     - Fix load/save of multiple rfkill states. (Closes: #759489)
     - Non-persistant journal (/run/log/journal) is now readable by group adm.
       (Closes: #771980)
     - Read netdev user mount option to correctly order network mounts after
       network.target. (Closes: #769186)
     - Fix 60-keyboard.hwdb documentation and whitespace handling.
       (Closes: #757367)
     - Fix ThinkPad X1 Carbon 20BT trackpad buttons (LP: #1414930)
     - Drop all backported patches and port the others to new upstream release.
   * Bump libblkid-dev build dependency as per upstream configure.ac.
   * debian/systemd.install: Add new language-fallback-map file.
   * debian/udev.install: Add new systemd-hwdb tool.
   * debian/libsystemd0.symbols: Add new symbols from this release.
   * tmpfiles.d/systemd.conf: Drop "wheel" ACL (that group does not exist in
     Debian) to make the ACL for "adm" actually work.
   * debian/rules: Explicitly disable importd for now; it should still mature a
     bit. Explicitly enable hwdb support.
   * /lib/lsb/init-functions.d/40-systemd: Call systemctl is-system-running
     with --quiet. (LP: #1421058)
   * debian/systemd.postrm: Clean getty@tty1.service and remote-fs.target
     enablement symlinks on purge. (Closes: #778499)
   * Move all Debian specific units in the systemd package into
     debian/extra/units/ and simplify debian/systemd.install.
   * Enable timesyncd by default. Add a config drop-in to not start if ntp,
     openntpd, or chrony is installed. (Closes: #755722)
   * debian/systemd.links: Drop obsolete hwclockfirst.service mask link, this
     was dropped in wheezy's util-linux already.
   * debian/udev.postinst: Call systemd-hwdb instead of udevadm hwdb.
 .
   [ Michael Biebl ]
   * Stop removing firstboot man pages. They are now installed conditionally.
Checksums-Sha1:
 25f5c8c9b99b990df423ad12f54b97785f8f9011 3838 systemd_219-1.dsc
 307d1c3e48b3bca1039cb66df2d7def074efe2ef 3938228 systemd_219.orig.tar.xz
 72195454bb4a2d4bf7b6693b11acb0560ecdd991 133588 systemd_219-1.debian.tar.xz
 77571d28e3e841dda2a1d0993277bd10a615c757 3384862 systemd_219-1_amd64.deb
 b919866cbc9a31df1a46a631fb01b9a48c746fb5 37528 systemd-sysv_219-1_amd64.deb
 81f4ee1f5f42065f7ea08ec2f99d7a3e1924fd47 137080 libpam-systemd_219-1_amd64.deb
 d43f100e95c9fcbf594a5bbba578489d18a943ab 97730 libsystemd0_219-1_amd64.deb
 92fcd2ed1f7c43f5ed4e707873a0134350b9d65f 99338 libsystemd-dev_219-1_amd64.deb
 2f57c66e4a4d9bc5c16c2994c91f846f6f60ed61 33152 libsystemd-login-dev_219-1_amd64.deb
 a978f2ff6ffebe777f9c3130156e45e6bce08144 33176 libsystemd-daemon-dev_219-1_amd64.deb
 2820e615521d2bcaa05437fbfa8e5e170bfa0fd6 33148 libsystemd-journal-dev_219-1_amd64.deb
 cd900960bd02b4ab1e3084ac2bfcb8709b4d9278 33142 libsystemd-id128-dev_219-1_amd64.deb
 b2a499fdc86037798d328830195522a6f2506596 947914 udev_219-1_amd64.deb
 08e0a237752e73559f207ee350893221fd85dfd5 65822 libudev1_219-1_amd64.deb
 31387341b5b7d3837528d59f020951c22e3a57c6 23004 libudev-dev_219-1_amd64.deb
 c7cdb2e8e7a8c923dea15702d156c7e47c71f0a8 230142 udev-udeb_219-1_amd64.udeb
 03f23b89ae278f30bd93e340ab565f46dec70ad8 32146 libudev1-udeb_219-1_amd64.udeb
 e48457d1d3848683a84f96b608906d825b38e95c 43474 libgudev-1.0-0_219-1_amd64.deb
 aa496572e19b5387fe16c9ed24e5247880d974fc 2828 gir1.2-gudev-1.0_219-1_amd64.deb
 b715896182aef8e93a927b62ab9f6aa66e3f3252 24432 libgudev-1.0-dev_219-1_amd64.deb
 99a97e009baf30e9bf2db69bb941683897e40d9f 63398 python3-systemd_219-1_amd64.deb
 02d8717b6a5581e889e494f15036c42309b84092 21961652 systemd-dbg_219-1_amd64.deb
Checksums-Sha256:
 5d0df12645985e33225681e24c61229131d997070d4b221d188831a2d5f3c60a 3838 systemd_219-1.dsc
 5c57113454e37c040d0cb481bd960ae7cf3a3fe0a231ff4945259bc74503f2d9 3938228 systemd_219.orig.tar.xz
 c8df82064332d8903f43369e5ff88c3a34416a135eaecc57a107e6eb126dbeac 133588 systemd_219-1.debian.tar.xz
 15bc3745d51fae36e439afd504f784cb81822e296b7f664eaef94164787b3b06 3384862 systemd_219-1_amd64.deb
 dc7229b0215613ab3967cf490d633e54b5a81b7a4e0a0de245636350e7d4c59b 37528 systemd-sysv_219-1_amd64.deb
 f2e1575573bbac2a9f527572bd8c2fa4ed1e0b2d107c844c08bcd6ff0fd0f357 137080 libpam-systemd_219-1_amd64.deb
 5231f2160f0f7cc5729714f5e0d077f1dab4775664a6c346fd0123015e43bbef 97730 libsystemd0_219-1_amd64.deb
 09759c410c561e93829ad841ce2b0c7a461be491feacacabcc2957504f5e1933 99338 libsystemd-dev_219-1_amd64.deb
 cd357e201a240bcdf26a768bd46c727f102ba5083dc9ba5a5c75b732bb70069b 33152 libsystemd-login-dev_219-1_amd64.deb
 949afe14b1a73a54edc8ad5ec53a7df2a74e03a08a2521ce8165f56465f32cdb 33176 libsystemd-daemon-dev_219-1_amd64.deb
 9f2b3e18e381a0e66184cdbe22e9c73f89132e02e4def58c6dfc8a2c22ca83fa 33148 libsystemd-journal-dev_219-1_amd64.deb
 c8af9f0247dcc0baacc9758900989170b4bfbfe58c968c9e0963274337e7bc60 33142 libsystemd-id128-dev_219-1_amd64.deb
 538b503a4e922edeb0227d4c98ea4eb4c519c9be7eca5dae4bf5ec2dc1836e56 947914 udev_219-1_amd64.deb
 a0dcead71835cdedb4b17eef9e38de41f99433d3d9f312c39e7e5444cf797dde 65822 libudev1_219-1_amd64.deb
 2e405eca6ddd7c39afc9192aef02710601fc18604f5f02d1626397657118933a 23004 libudev-dev_219-1_amd64.deb
 2bc48892cb86e5cc93090f233c9d3bbe9f654ce2c01fe6ad6126422ac56de292 230142 udev-udeb_219-1_amd64.udeb
 d1243afbddb455259f40d6360d9732501a8e942039a1befae599a45ca9075c9e 32146 libudev1-udeb_219-1_amd64.udeb
 c5e266875b1ce539b852905145c848ab49b70606bbeb695cd72251535e743b9a 43474 libgudev-1.0-0_219-1_amd64.deb
 0a5414e04650ba836592aabaf6b520e2c31f4d467c17201a259df28910aefab2 2828 gir1.2-gudev-1.0_219-1_amd64.deb
 629c5d45e761f496c731333fcefca6cf72fff41b144a8db5d26e6def828d4b66 24432 libgudev-1.0-dev_219-1_amd64.deb
 42f2fee0ee2994330b366d02ed65c5094b8663c190e46335431549940293b879 63398 python3-systemd_219-1_amd64.deb
 1ad367765d1aefa26d532897888c4c72157af45594f1b1abaad37598d5be034e 21961652 systemd-dbg_219-1_amd64.deb
Files:
 d71207a754f1548c4687373194938e44 3838 admin optional systemd_219-1.dsc
 e0d6c9a4b4f69f66932d2230298c9a34 3938228 admin optional systemd_219.orig.tar.xz
 3b7c51662ffa03c1bbce7158d9e61d5f 133588 admin optional systemd_219-1.debian.tar.xz
 c42842dd221355ef85cb1f25d6df9948 3384862 admin optional systemd_219-1_amd64.deb
 d0f9729356fe831131d18f14fc2bf8a8 37528 admin extra systemd-sysv_219-1_amd64.deb
 5d7ecbaa9003a523ad7225cde6257524 137080 admin optional libpam-systemd_219-1_amd64.deb
 cabdafa28ba890f58048519328a8f14d 97730 libs optional libsystemd0_219-1_amd64.deb
 39752c3687ac43554a16aa58e2f8ae48 99338 libdevel optional libsystemd-dev_219-1_amd64.deb
 253a396da4fd9d5bef7ba88c0c0ce42e 33152 oldlibs extra libsystemd-login-dev_219-1_amd64.deb
 c66db7f5094ed38ae593cc64dc064434 33176 oldlibs extra libsystemd-daemon-dev_219-1_amd64.deb
 a537e6008cd60f4b70ff863cee836544 33148 oldlibs extra libsystemd-journal-dev_219-1_amd64.deb
 1dc8703023373eebde17c4e65082cd78 33142 oldlibs extra libsystemd-id128-dev_219-1_amd64.deb
 0fd7c94ffb55cdcc569f833b6e2929ef 947914 admin important udev_219-1_amd64.deb
 0bc9af2e64ea3896da1e21c0802ad2e7 65822 libs important libudev1_219-1_amd64.deb
 db3d22d5152ba95919e730a216ee971b 23004 libdevel optional libudev-dev_219-1_amd64.deb
 ed3a62e17a27a6dad5ccb13e18b6cd78 230142 debian-installer optional udev-udeb_219-1_amd64.udeb
 99b6c089337722b3799d95d80ed9f95f 32146 debian-installer optional libudev1-udeb_219-1_amd64.udeb
 9ce2e55a6f4a397ee76de44071dc7227 43474 libs optional libgudev-1.0-0_219-1_amd64.deb
 82dec671e100b9a5fcb6caa61f0b687c 2828 introspection optional gir1.2-gudev-1.0_219-1_amd64.deb
 a2d9376b09e83a8ebc1c1bbdd360490f 24432 libdevel optional libgudev-1.0-dev_219-1_amd64.deb
 d84b591a3cbe7f9e129b30e7fca457c0 63398 python optional python3-systemd_219-1_amd64.deb
 681a223d3a2bdf13916d6602c3a69597 21961652 debug extra systemd-dbg_219-1_amd64.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJU41vgAAoJENFO8V2v4RNHhyYP/1nB8u3V9jowU3gHSojcLWlE
esFawFHixPb2HfKj+7hkuYkmoKTy4blZLf71YHTqTVCZ6sMNbrrM8FfR7r1beU39
8XE5m7UwtKbaqixmkrFv1uw+a7f6Y3lqtnbR8OiZW7jV4nUZW+/p9O7odDMXmeTE
7flLKbzCpHRaxwPTuLIN1v3pmEC2Vndw0LOFCPciTqWkkErhGUF6+5Nxsj4zZb5/
kCQF22X5wr0c9v5sO0mBPEVtZZ0k7RRP8pO++DuZ6xQYmWiW8R5C3OJONP0DSu9L
LBL7uGdvzycq/iMTh6rMFKcCoa/VIINK6uSqHAoXDbbxC4zBxOtyYX90qHbsvf1a
4yVacl5l65S3/7gGYHc8texi1aoKEgGBfltMJ6x3V7lD0KIQ4czs20jKNFD4U0ua
q3f6ujX5Wcrzf2suHxWCXFWIaKy1X9I9LX7SQSF4ci6hT1Noi178OaG8GaOPfAb8
9jRmPHN1P1kODAMlqAlRbmioRGm+66BE3mXFQXZcBmmt5u0rCBZ4lM4W3wf+MpZY
aSGWkXQwLzlIpVkaathtpqNbYAOXlpaBd8rA8dZ+KacnMzqdoZ+/gSOYH281yk16
MUP/jZrM1C8hByfDO4wpSZjHK+rLNBPnbgy3l1Vwuepvm1DHQZQcx1T0FwGvCCos
R2w/NNc1Qxa8DawoDy79
=3/Uf
-----END PGP SIGNATURE-----

Message #223 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Willi Mann <willi@debian.org>

To: 755722@bugs.debian.org

Subject: should be fixed in jessie

Date: Thu, 19 Feb 2015 09:02:21 +0100

Hi,

I think this bug should get fixed for jessie. I don't want to raise the
severity of this bug myself as it was already lowered once, but please
fix this bug before the release.

thanks
Willi

Message #228 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 755722@bugs.debian.org

Cc: Stefan Fritsch <sf@sfritsch.de>

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

Date: Tue, 24 Feb 2015 07:00:01 +0100

[Message part 1 (text/plain, inline)]

Control: tag -1 pending

Hello all,

The release team agreed to adding hwclock-save.service to jessie now,
and also unblocked 215-12 (d-i ack still pending), so that we can go
ahead with that.  Committed to git (for master only).

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[signature.asc (application/pgp-signature, inline)]

Message #235 received at 755722@bugs.debian.org (full text, mbox, reply):

From: pav ka <vorobjevpavel@gmail.com>

To: 755722@bugs.debian.org

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

Date: Thu, 19 Mar 2015 11:03:50 +0300

[Message part 1 (text/plain, inline)]

root@pa:/var/log# cat /etc/debian_version
8.0


root@pa:/var/log# cat daemon.log | grep fsck
Mar 17 06:15:15 pa systemd-fsck[170]: root: Superblock last write time is
in the future.
Mar 17 06:15:15 pa systemd-fsck[170]: (by less than a day, probably due to
the hardware clock being incorrectly set).  FIXED.
Mar 17 06:15:15 pa systemd-fsck[170]: root: 119976/6111232 files (0.2%
non-contiguous), 1467523/24413952 blocks
Mar 17 06:15:15 pa systemd-fsck[386]: srv: clean, 85348/953984 files,
221143708/244190208 blocks
Mar 17 06:15:15 pa systemd-fsck[387]: home: clean, 40337/24305664 files,
42675932/97194240 blocks
Mar 18 06:17:10 pa systemd-fsck[171]: root: Superblock last write time is
in the future.
Mar 18 06:17:10 pa systemd-fsck[171]: (by less than a day, probably due to
the hardware clock being incorrectly set).  FIXED.
Mar 18 06:17:10 pa systemd-fsck[171]: root: 120036/6111232 files (0.2%
non-contiguous), 1467869/24413952 blocks
Mar 18 06:17:10 pa systemd-fsck[385]: srv: clean, 85348/953984 files,
221143708/244190208 blocks
Mar 18 06:17:10 pa systemd-fsck[386]: home: clean, 40337/24305664 files,
42678676/97194240 blocks
Mar 19 06:42:49 pa systemd-fsck[171]: root: Superblock last write time is
in the future.
Mar 19 06:42:49 pa systemd-fsck[171]: (by less than a day, probably due to
the hardware clock being incorrectly set).  FIXED.
Mar 19 06:42:49 pa systemd-fsck[171]: root: 120032/6111232 files (0.2%
non-contiguous), 1468002/24413952 blocks
Mar 19 06:42:49 pa systemd-fsck[388]: srv: clean, 85348/953984 files,
221144092/244190208 blocks
Mar 19 06:42:49 pa systemd-fsck[389]: home: clean, 40353/24305664 files,
42678750/97194240 blocks

[Message part 2 (text/html, inline)]

Message #240 received at 755722@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: pav ka <vorobjevpavel@gmail.com>, 755722@bugs.debian.org

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

Date: Thu, 19 Mar 2015 15:56:43 +0100

[Message part 1 (text/plain, inline)]

Am 19.03.2015 um 09:03 schrieb pav ka:
> root@pa:/var/log# cat /etc/debian_version
> 8.0
> 
> 
> root@pa:/var/log# cat daemon.log | grep fsck
> Mar 17 06:15:15 pa systemd-fsck[170]: root: Superblock last write time is
> in the future.
> Mar 17 06:15:15 pa systemd-fsck[170]: (by less than a day, probably due to
> the hardware clock being incorrectly set).  FIXED.
> Mar 17 06:15:15 pa systemd-fsck[170]: root: 119976/6111232 files (0.2%
> non-contiguous), 1467523/24413952 blocks

What is that supposed to show?
That you are affected by [1] maybe?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #245 received at 755722-close@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 755722-close@bugs.debian.org

Subject: Bug#755722: fixed in systemd 215-13

Date: Thu, 26 Mar 2015 13:49:07 +0000

Source: systemd
Source-Version: 215-13

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 755722@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin Pitt <mpitt@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 26 Mar 2015 14:23:35 +0100
Source: systemd
Binary: systemd systemd-sysv libpam-systemd libsystemd0 libsystemd-dev libsystemd-login0 libsystemd-login-dev libsystemd-daemon0 libsystemd-daemon-dev libsystemd-journal0 libsystemd-journal-dev libsystemd-id128-0 libsystemd-id128-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb libgudev-1.0-0 gir1.2-gudev-1.0 libgudev-1.0-dev python3-systemd systemd-dbg
Architecture: source amd64
Version: 215-13
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Martin Pitt <mpitt@debian.org>
Description:
 gir1.2-gudev-1.0 - libgudev-1.0 introspection data
 libgudev-1.0-0 - GObject-based wrapper library for libudev
 libgudev-1.0-dev - libgudev-1.0 development files
 libpam-systemd - system and service manager - PAM module
 libsystemd-daemon-dev - systemd utility library (transitional package)
 libsystemd-daemon0 - systemd utility library (deprecated)
 libsystemd-dev - systemd utility library - development files
 libsystemd-id128-0 - systemd 128 bit ID utility library (deprecated)
 libsystemd-id128-dev - systemd 128 bit ID utility library (transitional package)
 libsystemd-journal-dev - systemd journal utility library (transitional package)
 libsystemd-journal0 - systemd journal utility library (deprecated)
 libsystemd-login-dev - systemd login utility library (transitional package)
 libsystemd-login0 - systemd login utility library (deprecated)
 libsystemd0 - systemd utility library
 libudev-dev - libudev development files
 libudev1   - libudev shared library
 libudev1-udeb - libudev shared library (udeb)
 python3-systemd - Python 3 bindings for systemd
 systemd    - system and service manager
 systemd-dbg - system and service manager (debug symbols)
 systemd-sysv - system and service manager - SysV links
 udev       - /dev/ and hotplug management daemon
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 755722 759001 777164 779571 779710 779902 780263 780675
Changes:
 systemd (215-13) unstable; urgency=medium
 .
   [ Martin Pitt ]
   * Add hwclock-save.service to sync the system clock to the hardware clock on
     shutdown, to provide monotonic time for reboots. (Note: this is a hack for
     jessie; the next Debian release will enable timesyncd by default).
     (Closes: #755722)
   * Check for correct architecture identifiers for SuperH. (Closes: #779710)
   * networkd: Fix stopping v4 dhcpclient when the carrier is lost. Thanks
     Christos Trochalakis! (Closes: #779571)
   * Fix segfault with units that depend on themselves. (Closes: #780675)
   * tmpfiles-setup-dev: Call tmpfiles with --boot to allow unsafe device
     creation. Fixes creation of static device nodes with kmod 20.
     (Closes: #780263)
 .
   [ Christian Seiler ]
   * core: Don't migrate PIDs for units that may contain subcgroups.
     This stops messing up lxc/libvirt/other custom cgroup layouts after
     daemon-reload. (Closes: #777164)
   * sysv-generator: add support for /etc/insserv/overrides. (Closes: #759001)
 .
   [ Michael Biebl ]
   * debian/udev.init: Recognize '!' flag with static device lists, to work
     with kmod 20. (Closes: #780263)
 .
   [ Didier Roche ]
   * Ensure PrivateTmp doesn't require tmpfs through tmp.mount, but rather adds
     an After relationship. (Closes: #779902)
Checksums-Sha1:
 fd4f4b6ef0c36f54d3955141d69f33bfc71da106 4107 systemd_215-13.dsc
 fd4df3c4eaf2427b18f548491b4c1b83319130cc 198712 systemd_215-13.debian.tar.xz
 a9cc79f663869cd61b0600eb895d081c1ba66a54 2537600 systemd_215-13_amd64.deb
 e5f51f48138b1de9e220351ab1ae426f65d08c12 33116 systemd-sysv_215-13_amd64.deb
 bd122f10a34fae001fb9126559bd20e01a40cf9c 122434 libpam-systemd_215-13_amd64.deb
 be1462cc7b6baf1730ada10a39696ea358cf92bc 85920 libsystemd0_215-13_amd64.deb
 7ac032916d4b84877e19ae6fd4bac2594fb2ee06 92054 libsystemd-dev_215-13_amd64.deb
 3a4849dbe2a97875615b0bc302e98eb2331cdd01 46214 libsystemd-login0_215-13_amd64.deb
 84eb95fd378d47b7ef925bffe2d7b3947ce4e582 28714 libsystemd-login-dev_215-13_amd64.deb
 d2a9b69a02d99e64ad63e4215290caf04c5cb357 35326 libsystemd-daemon0_215-13_amd64.deb
 7a3df31260d17beeaa4850e160c84416926a5947 28726 libsystemd-daemon-dev_215-13_amd64.deb
 c85af667f52601fa5bda45ab0341b848d6dfb51d 71510 libsystemd-journal0_215-13_amd64.deb
 cfd4ab5f0b857a9bdac6595f3dce6419c089d4dc 28716 libsystemd-journal-dev_215-13_amd64.deb
 da96d4dfccf7ad81672e3a966e5c68adfe3a40e3 34294 libsystemd-id128-0_215-13_amd64.deb
 87011b49f6c27b3c68f94023128c3ee52a93904b 28702 libsystemd-id128-dev_215-13_amd64.deb
 81483cfc43175be74b988b9c67720e94f5ce2da5 872942 udev_215-13_amd64.deb
 6bc8410ebbfa74c32a235d6ef68787fe3fda4c9c 54196 libudev1_215-13_amd64.deb
 ade33bf582d31189a16ecb3e14ea384e41161067 23078 libudev-dev_215-13_amd64.deb
 27fe2b05a28dc25e2df0dc43a810bd212a9625bf 195296 udev-udeb_215-13_amd64.udeb
 77645609d4b8484df2dc1f1ca765d9ed3d903a42 24732 libudev1-udeb_215-13_amd64.udeb
 01050f59c54297ae1ccaff107b1ee7a942e23b53 39032 libgudev-1.0-0_215-13_amd64.deb
 1d9ada797cd8502c5abceb17c57fbf6e0d6a8926 2816 gir1.2-gudev-1.0_215-13_amd64.deb
 121a4e01cb3f8c740390b12cfeddef8846f6ec16 24514 libgudev-1.0-dev_215-13_amd64.deb
 e0986e7ce368634fea1cd519dc6d413b4dec14e1 58434 python3-systemd_215-13_amd64.deb
 12ac6c451d646ab4336ad307bbaf876bee9eea78 15925862 systemd-dbg_215-13_amd64.deb
Checksums-Sha256:
 4211596924683dcfad859ac71382f1bd864314ae6bfa14c5c2c7d6d32d8d3a78 4107 systemd_215-13.dsc
 aa1b1027cac4e174f41c9d3d4a46e3d0e3354360355cc1a5882cdeb2714d0d21 198712 systemd_215-13.debian.tar.xz
 4de8f935f596db0031f35bfab2313a386c8ba1f51c9056bbe688da48edf872a7 2537600 systemd_215-13_amd64.deb
 5d9461c882121077ac0851ce63af8700ba41eef18d94f7a020bc6a5015f1d490 33116 systemd-sysv_215-13_amd64.deb
 6fd56689f73256bbc3b0866fa1f60c1f4a0a86dab3419b44c1817e9b9854f18d 122434 libpam-systemd_215-13_amd64.deb
 03f09f59e6bd7a09b92558948bff07d82a9adf9ccb5ef90feb02447899c8d9b4 85920 libsystemd0_215-13_amd64.deb
 c8cf285939a7250fab6aac389b3edcffeec5067544da8c67dedf45942c595e84 92054 libsystemd-dev_215-13_amd64.deb
 83f68f8c1cc93ffccd30923cff694f94d4e6f629818eeb493113016fca89f803 46214 libsystemd-login0_215-13_amd64.deb
 83063298ff1ddd2db6f61ab97c2d34194ca7234737d0a341aa5fb18bdf2bc1c1 28714 libsystemd-login-dev_215-13_amd64.deb
 f68bb5394e4876226b02e7ac4693b2a4275d5ce25c4dd9ee9a7b6b21db620963 35326 libsystemd-daemon0_215-13_amd64.deb
 f3e534b48ecdeb01ee42bb73106a44d3a4eb67f1f59526762aaa0bab53950e03 28726 libsystemd-daemon-dev_215-13_amd64.deb
 bce5b643724e780eea2394493759953f957c7faf1a5d2241c0a1ecabb711fe33 71510 libsystemd-journal0_215-13_amd64.deb
 da35383c9d206a38246bb61f3ccedfe384b4def5bb63a9ede2b7d1e1f397f9b7 28716 libsystemd-journal-dev_215-13_amd64.deb
 188e71b2ce60ac760ccde8fe1533a0f8e2a537568eaef3fd13998c6594ebd6d0 34294 libsystemd-id128-0_215-13_amd64.deb
 9085a93e9ba8fa7ac6ef89061b5e47602df05113ed2b8a70622e23dfae41c095 28702 libsystemd-id128-dev_215-13_amd64.deb
 41c3ad964116b8714d0ab3a7290d333ac0afa649dee447777650a979c73c9c8c 872942 udev_215-13_amd64.deb
 64b1f104aefd4e9fa56f492887feffc53f90c73eee8fdff9fdb66047f05b0097 54196 libudev1_215-13_amd64.deb
 485c184bc29972923b42fbaf4618aeb2d1e2169ca95c06b6cdc2844f263fbcad 23078 libudev-dev_215-13_amd64.deb
 b7b049d1f795af66801d183b7e76365ea59ca5312a83b4aa0ae68f69f20785ed 195296 udev-udeb_215-13_amd64.udeb
 ee85ef5dce1442421b7c76049a1358bbc02441fa6477a14075a77f4cab70bf74 24732 libudev1-udeb_215-13_amd64.udeb
 248ed847005db9c3a024b16caf288d19c611c2b142b4895fa591fedf2680937f 39032 libgudev-1.0-0_215-13_amd64.deb
 53c4b029ef235cd6cdd67f210369a91f247438b7b56435255642ccef50876005 2816 gir1.2-gudev-1.0_215-13_amd64.deb
 e8c74d75c29b95e824891471dfb038c18e0218eba7cde8091ce45537284fc6cb 24514 libgudev-1.0-dev_215-13_amd64.deb
 ea035dc08469937c2bdad81eef71abb92718eebe174aaddf5402964daa162e14 58434 python3-systemd_215-13_amd64.deb
 da73dedc18f3d7bc94728692681f0f7938d69ebc326d32684655c5613e27adaf 15925862 systemd-dbg_215-13_amd64.deb
Files:
 29d542615583ebe63a8b584c9a957a41 4107 admin optional systemd_215-13.dsc
 3a8d7206498991dfd296b40ef657142e 198712 admin optional systemd_215-13.debian.tar.xz
 f3234f633a70d410194633459903b312 2537600 admin optional systemd_215-13_amd64.deb
 82d8a11c304e5f3faf3b97b29c9b46d3 33116 admin extra systemd-sysv_215-13_amd64.deb
 b6531877b25c23b22bbd43c8b6017187 122434 admin optional libpam-systemd_215-13_amd64.deb
 c454fe69027649d816e2b188227c003c 85920 libs optional libsystemd0_215-13_amd64.deb
 16883d3e36c447ffee9bb471d80d196d 92054 libdevel optional libsystemd-dev_215-13_amd64.deb
 85faabb3165d462a999b966158c3e800 46214 oldlibs extra libsystemd-login0_215-13_amd64.deb
 ac8875198ebbc0dbe71a4b2d058cc5e5 28714 oldlibs extra libsystemd-login-dev_215-13_amd64.deb
 06b3addfef5af830795804b1b237c453 35326 oldlibs extra libsystemd-daemon0_215-13_amd64.deb
 111998f4578ebc0ef102135e7083ee0b 28726 oldlibs extra libsystemd-daemon-dev_215-13_amd64.deb
 49482fe8aed4ce332cf6ea618812da18 71510 oldlibs extra libsystemd-journal0_215-13_amd64.deb
 c56943b71d312ec34a9813e7e000370b 28716 oldlibs extra libsystemd-journal-dev_215-13_amd64.deb
 c4c511b023474387b8a33b8641ceaf17 34294 oldlibs extra libsystemd-id128-0_215-13_amd64.deb
 3a93ee6237dfc3104dbf9a984f8acef7 28702 oldlibs extra libsystemd-id128-dev_215-13_amd64.deb
 20ef09df83ad8696d51c115beb76a710 872942 admin important udev_215-13_amd64.deb
 5e30efe2707df7b06f2b2a41edfb09cf 54196 libs important libudev1_215-13_amd64.deb
 a6b4b1225711856a5786c0544c718426 23078 libdevel optional libudev-dev_215-13_amd64.deb
 4ab1c41c4d6e63a7a857f29b3f716cf5 195296 debian-installer optional udev-udeb_215-13_amd64.udeb
 ea03b82073be69bf97364b1056b524ae 24732 debian-installer optional libudev1-udeb_215-13_amd64.udeb
 139a367192244d15e1ff47120ad45897 39032 libs optional libgudev-1.0-0_215-13_amd64.deb
 e53e7365ac529a9c4ddb5701b112e983 2816 introspection optional gir1.2-gudev-1.0_215-13_amd64.deb
 b46e95a8406a4b96783fc69e5b7aafd8 24514 libdevel optional libgudev-1.0-dev_215-13_amd64.deb
 b6444c508283108c5de22f981f5bf6cc 58434 python optional python3-systemd_215-13_amd64.deb
 090f9a06e5d9867242d4410333e0eb71 15925862 debug extra systemd-dbg_215-13_amd64.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVFAtcAAoJENFO8V2v4RNHEgIQAINOwtHv3tPe097uTg75s3bm
gpv8qxnGKrp7VUVul9cLhZrIEnt5h9iP3As6Wm/2MrAqc/F99+nRm4XVLAiC5SNt
lxmIQw4YwFxBHy/doWz2fUcd1LnhhpQ/csNgca9IiVkowRMkfGmbtPexRiTvuhmq
vwvycU/55A/5xi3FbEb7KHoLbKbZcxBjsiYmx5Sf7BbrQS4clTGlJxfevk0h5RzN
caSP1bDcKdykKStYJ8eqjcbZJOs2KpN/tm2cpNr73kkmmpEiwkjqbpRDH5/9NSuv
/nRYmIdBTalUaTBkLoYUsZ5R58DeGkzr/Xw7dHLptxxT+oxO/X0qYe57/hsVp71N
aUrVDzKbStsTJSh8a7yi0LcwmAB2uln0la1AYtnAprbaQViLWlt8kNIfAWCD5Obj
WxVsJgj7sy6GbqLiJLkNc50ci3wn4HIRR4I6WW9FjihGUjv5+MiLQwxbcGaGz5Lz
G1g5/KaMDDiWWw+r5dN5pcjZu23hbd+IW7HGwMnOM/y1uCNKlrFNLrl6Jb+Xoe+Z
NFFuS7U3T4VwCyIKVpnNK4x4tD6Tcw0+Ds/Ewd3+QC4JODDsjh8KA9eGSyXVnGI3
HVfLFofziwKBfrI0+uTKGF1MEJoRUx1mzzgI6YKwHbJln7jV7FQdjJRB35FiMonv
O36E2+yKEfkG9919ox5F
=rqb/
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.