http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c2 --- Comment #2 from Ginko Bonsai ---

chrony-wait.service is disabled by default and should only be used on machines running services that strictly require synchronized time and have a permanent network connection. I wonder what caused it to be enabled on your laptop.

Me too. I changed the ntp server from the default to a pool for my country via YaST, iirc. Maybe that's when it happened?

For further analysis please post the output of "systemctl status chrony-wait.service".

Sure: ● chrony-wait.service - Wait for chrony to synchronize system clock Loaded: loaded (/usr/lib/systemd/system/chrony-wait.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2019-08-14 13:03:58 CEST; 6h ago Docs: man:chronyc(1) Main PID: 2691 (code=exited, status=1/FAILURE) Aug 14 13:03:49 suse-laptop systemd[1]: Starting Wait for chrony to synchronize system clock... Aug 14 13:03:58 suse-laptop systemd[1]: chrony-wait.service: Main process exited, code=exited, status=1/FAILURE Aug 14 13:03:58 suse-laptop systemd[1]: chrony-wait.service: Failed with result 'exit-code'. Aug 14 13:03:58 suse-laptop systemd[1]: Failed to start Wait for chrony to synchronize system clock. Since I'm currently using Wifi which only connects after I log in with my user, I'm not surprised by the failure.

BTW, the timeout you are criticising is not until the NTP server starts responding, but until chrony has synchronized the local clock to the server, which can take some time even if the server responds immediately, depending on how far off the local clock is.

Ah OK, that explains it, thanks :-) I guess the real issue is that it got activated for a laptop, then. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c4 --- Comment #4 from Ginko Bonsai --- @Yunhe Guo: Personally, I don't use KDE (but XFCE), so I can't confirm that this is related to this issue. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c6 Sam G changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |samueldgv@pm.me --- Comment #6 from Sam G --- I have just installed Tumbleweed (with the 22nd of August snapshot) on a new laptop and found chrony-wait.service activated by default. It was activated from the first boot, nothing installed, nothing modified. The only way to avoid waiting 10 minutes is to have it plugged to ethernet prior or during the wait time as otherwise it won't reach anything. I think this is may be rather urgent as new Tumbleweed users installing it for the first time on their laptops will have a bad impression! Below is the status of the service prior to me having to disable it manually: sam@localhost:~> sudo systemctl status chrony-wait.service [sudo] password for root: ● chrony-wait.service - Wait for chrony to synchronize system clock Loaded: loaded (/usr/lib/systemd/system/chrony-wait.service; enabled; vendor preset: disabled) Active: active (exited) since Sun 2019-08-25 16:47:11 CEST; 4min 57s ago Docs: man:chronyc(1) Main PID: 1446 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CGroup: /system.slice/chrony-wait.service Aug 25 16:40:07 localhost systemd[1]: Starting Wait for chrony to synchronize system clock... Aug 25 16:47:11 localhost.localdomain systemd[1]: Started Wait for chrony to synchronize system clock. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c8 --- Comment #8 from Sam G --- (In reply to Sam G from comment #7)

(In reply to Sam G from comment #6)

...

I have just installed Tumbleweed (with the 22nd of August snapshot) on a new laptop and found chrony-wait.service activated by default. It was activated from the first boot, nothing installed, nothing modified.

The only way to avoid waiting 10 minutes is to have it plugged to ethernet prior or during the wait time as otherwise it won't reach anything. I think this is may be rather urgent as new Tumbleweed users installing it for the first time on their laptops will have a bad impression!

Below is the status of the service prior to me having to disable it manually:

sam@localhost:~> sudo systemctl status chrony-wait.service [sudo] password for root: ● chrony-wait.service - Wait for chrony to synchronize system clock Loaded: loaded (/usr/lib/systemd/system/chrony-wait.service; enabled; vendor preset: disabled) Active: active (exited) since Sun 2019-08-25 16:47:11 CEST; 4min 57s ago Docs: man:chronyc(1) Main PID: 1446 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CGroup: /system.slice/chrony-wait.service

Aug 25 16:40:07 localhost systemd[1]: Starting Wait for chrony to synchronize system clock... Aug 25 16:47:11 localhost.localdomain systemd[1]: Started Wait for chrony to synchronize system clock.

Sorry, had a brain fart! This was not truly a first boot as after finishing the installation and booting directly I logged into Plasma and then rebooted. I cannot really confirm the above as I was on ethernet but judging by the fact that the vendor preset is disabled there may be a desktop component triggering it on that first login. I will install TW again and confirm.

Well...now I reinstalled TW with the same media and checked it on the first boot without ethernet at any moment nor logging to Plasma (just a tty)...and to my surprise the chrony-wait service is deactivated and inactive. I also tried: 1) A reboot, without logging into Plasma and without ethernet 2) A reboot, logging into Plasma and without ethernet 3) A reboot, logging into Plasma and with ethernet Whatever activated it in the first place may not even be doing it in all cases...if any further info is needed I will be happy to help, though maybe I have created an even bigger confusion -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c11 --- Comment #11 from ls gz --- Same issue here on fresh tumbleweed gnome install: Chrony (enabled by default) causes 10 min delay at boot time. I modified the time by doing sudo systemctl edit --full chrony-wait.service and also set NTP to manual in Yast. Now the system boots ok -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c13 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yast2-maintainers@suse.de Flags| |needinfo?(yast2-maintainers | |@suse.de) Severity|Normal |Major --- Comment #13 from Fabian Vogt --- It looks like this isn't even tracked on the YaST board yet. As this affects more and more systems the longer this is in YaST code, please revert the change until a proper approach has been figured out. Does that sound ok? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c15 --- Comment #15 from ravas mi --- Forget about NTP settings. The "solution" is

systemctl disable chrony-wait.service

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c32 Hagen Buliwyf changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hagen.buliwyf@t-online.de --- Comment #32 from Hagen Buliwyf --- Today i was hit by this problem on a fresh Tumbleweed installation: When i set up time synchronisation (now and on system start) on the next reboot the system got stuck and told me there was a start job running with NO TIME LIMIT. I killed the boot process with STRG+ALT+DEL, started the dvd-rescue-system and disabled chrony-wait now everything works fine.

The problem is: today many services communicates via certificates, even on local systems, and we are getting more and more bug reports because this fails, as this services are started before the time is set. The other problem is, that even booting creates meanwhile a lot of trouble because of this [bsc#1129730], that's why we enable it in our images.

As long as services communicate via certificates on a local system don't they they use the same time source - the system clock and therefore do have identical time? If services want to communicate via certificates across a network with a remote machine they do need network access. So does chrony. Only THOSE services should wait until chrony has finished time synchronisation. but no others. "Killing" the whole boot process seems not a good idea to me. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c34 Felix Niederwanger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felix@feldspaten.org --- Comment #34 from Felix Niederwanger --- I can also confirm the bug on a fresh install of Tumbleweed (Lenovo T440p). Had to wait for 10 minutes until the process times out while being in the train on battery power. It's also non-intuitive, as there is a time limit of 10 minutes, but the boot screen does not display it (8 min 15 s / no limit). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c35 --- Comment #35 from Alberto Planas Dominguez --- Maybe the bug is in chronyd.service, that is missing something like After=network-online.target -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 Hans de Raad changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hcderaad@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c41 --- Comment #41 from Reinhard Max --- (In reply to Fabian Vogt from comment #37)

I see there has not been any progress on this. I'm still very much in favor of reverting the change in YaST ASAP. The stream of incoming complaints about TW being unusuable is constant and we're losing users because of this.

Fixing this in a way that everyone can agree on can be done afterwards.

Yes, please! I agree with Thorsten that there is much stuff to be fixed in this area, but just enabling chrony-wait.service through YaST and ignoring the other problems this brings up was throwing out the baby with the bath water. Maybe for the time being the default-enablement of chrony-wait.service can be done in a way so that it only happens on openSUSE Kubic, but not on normal Tumbleweed? If not, let's disable it by default until the followup-problems have been sorted out. (In reply to Josef Reidinger from comment #40)

what change in YaST you have mean? Switch from ntpd to chrony? Or something else?

The fact that YaST enables chrony-wait.service as a result of bug #1137196. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c44 Reinhard Max changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(kukuk@suse.com) --- Comment #44 from Reinhard Max --- Thorsten, could you please provide a list of services that use certs and might get into trouble when chrony-wait.service is not enabled, so that we can investigate if they really need the sub-second clock precision of time-sync.target or if time-set.target would be good enough for them? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c49 --- Comment #49 from Ginko Bonsai ---

YaST can't be responsible for decision taking here. We just implement what others want in a way they need it. I'd like to hear your wishes/opinions till Monday, 23rd September, 12:00 CEST. Then we need to plan for the next sprint.

I can't speak for the "always online and we absolutely need super-exact time" usecase, just for the "laptop, may be used offline" use case, so here goes the user story: As a travelling laptop user I want to be able to boot my laptop to graphical user interface and use it even if I have no network so that I can work on the train. Being offline must not block booting to GUI. A timeout of 10 minutes with no indication that the timeout *is* 10 minutes signals to me "this machine won't ever boot". Side note: since deactivating the chrony-wait service, I've had zero problems with services due to inexact time. But then I'm not using the laptop as a host for webserver, timeserver, fileserver, crypto stuff, etc. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c53 --- Comment #53 from Marcus Hallett --- I'm also seeing this problem. Whenever I boot without a network connection into TW I'll see the same wait time. I agree that disabling chrony-wait.service is not a real solution. Like Ginko Bonsai, I changed the wait time from 600 seconds (to 60), so that if there were a connection the sync would occur at that time. I'd need to assess my use cases, but I think that Thorsten Kukuk is on the right track what he said (In reply to Thorsten Kukuk from comment #17) about executing the synchronization upon network connection. Anyhow, is there any action on this? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 Philip Leupold changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philip.leupold@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1145193 http://bugzilla.opensuse.org/show_bug.cgi?id=1145193#c58 --- Comment #58 from ravas mi --- The "chrony.conf" file documentation for "makestep" mentions "initstepslew" https://chrony.tuxfamily.org/doc/3.5/chrony.conf.html#initstepslew “The purpose of the initstepslew directive is to allow chronyd to make a rapid measurement of the system clock error at boot time, and to correct the system clock by stepping before normal operation begins. Since this would normally be performed only at an appropriate point in the system boot sequence, no other software should be adversely affected by the step. If the correction required is less than a specified threshold, a slew is used instead. This makes it safer to restart chronyd whilst the system is in normal operation. The initstepslew directive takes a threshold and a list of NTP servers as arguments. Each of the servers is rapidly polled several times, and a majority voting mechanism used to find the most likely range of system clock error that is present. A step or slew is applied to the system clock to correct this error. chronyd then enters its normal operating mode.” -- You are receiving this mail because: You are on the CC list for the bug.