Your message dated Tue, 17 Jul 2018 01:30:17 +0200
with message-id <[email protected]>
and subject line Re: Bug#890891: systemd: PID1 getting stuck printing
"systemd[1]: Time has been changed" continuously
has caused the Debian Bug report #890891,
regarding systemd: PID1 getting stuck printing "systemd[1]: Time has been
changed" continuously
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
890891: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890891
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 236-3
Severity: normal
Tags: upstream
Dear Maintainer,
on an 32 bit arm system when the RTC is set to a wrong time booting the system
might
fail because systemd gets stuck in a loop printing "systemd[1]: Time has been
changed".
The problem is known upstream and claimed to be a problem of the kernel:
https://github.com/systemd/systemd/issues/1143
However, while upstream is certainly correct that a kernel bug is the trigger
of
the lockup, systemd should not hang on this, because if sending messages to
systemd
can lock up the system then this is actually an attack vector for a DoS attack.
A approach to work around this problem is posted in above bug report by user
wtarreau and
repeated here (comment included):
Basically manager_clock_watch() could start with something more or less like
this
(assuming it's the one responsible for this endless loop) :
gettimeofday(&now, NULL);
if (m->last_change == now.tv_sec) {
m->change_count++;
}
else {
if (m->change_count > 1)
log("Time changed %d times in the last second\n", m->change_count);
if (m->change_count >= 100) {
log("Timerfd is broken on this system, disabling time change
detection\n");
manager_listen_stop(m);
return 0;
}
m->change_count = 0;
m->last_change = now.tv_sec;
}
Best,
Gert
-- Package-specific info:
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armhf (armv7l)
Kernel: Linux 4.15.1-cm-fx6-my (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.117
ii libacl1 2.2.52-3+b1
ii libapparmor1 2.12-2
ii libaudit1 1:2.8.2-1
ii libblkid1 2.30.2-0.3
ii libc6 2.26-6
ii libcap2 1:2.25-1.2
ii libcryptsetup4 2:1.7.5-1
ii libgcrypt20 1.8.1-4
ii libgpg-error0 1.27-6
ii libidn11 1.33-2.1
ii libip4tc0 1.6.2-1
ii libkmod2 25-1
ii liblz4-1 0.0~r131-2+b1
ii liblzma5 5.2.2-1.3
ii libmount1 2.30.2-0.3
ii libpam0g 1.1.8-3.7
ii libseccomp2 2.3.1-2.1
ii libselinux1 2.7-2+b1
ii libsystemd0 236-3
ii mount 2.30.2-0.3
ii procps 2:3.3.12-3
ii util-linux 2.30.2-0.3
Versions of packages systemd recommends:
ii dbus 1.12.4-1
ii libpam-systemd 236-3
Versions of packages systemd suggests:
ii policykit-1 0.105-18
pn systemd-container <none>
Versions of packages systemd is related to:
pn dracut <none>
pn initramfs-tools <none>
ii udev 236-3
-- no debconf information
--- End Message ---
--- Begin Message ---
On Sun, 25 Feb 2018 18:46:34 +0100 Michael Biebl <[email protected]> wrote:
> On Tue, 20 Feb 2018 19:38:08 +0100 Gert Wollny <[email protected]> wrote:
> > Am Dienstag, den 20.02.2018, 15:31 +0100 schrieb Michael Biebl:
> > >
> > > > Kernel: Linux 4.15.1-cm-fx6-my (SMP w/4 CPU cores; PREEMPT)
> > >
> > >
> > > Does this also happen with a Debian provided kernel? If so, which
> > > kernel version is that?
> > I haven't tried this so far, for that reason I was initially also a bit
> > reluctant to report the bug here and I didn't report anything against
> > the kernel package. There is another problem: reproducing the bug is
> > not straightforward: in theory I should be able to trigger it by
> > setting the clock to a time past the year 2038, but hwclock doesn't let
> > me, and unplugging the device also doesn't switchset the RTC to a bogus
> > value right away.
>
> I was under the impression, that this issue was fixed in the kernel. So,
> are you still running into this with your self-compiled 4.15.1-cm-fx6-my?
Closing, due to lack of further feedback.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
