Carlos E. R. writes:
I think it is intentional to wait.
When eventually ntp service syncs, the clock can jump ahead or backwards, hopefully by less than a second if the cmos clock is not off by much, but eventually by minutes or hours.
That is already done by ntpdate so the ntpd should only slew.
Some of the Linux services that are started after ntp can react badly to clock changes. I know of at least one (dovecot) that bails out if the clock goes back. It simply crashes nicely, with a message as to the reason.
Of course, if you have no network you should disable or remove ntp.
I have.
Or find out why it starts slowly.
I found out why it does that and surprisingly it looks like systemd actually starts it too late. The standard config is to chroot ntpd and that produces a lot of disk activity that takes a long time, especially during boot when there are other processes competing for disk I/O. I think that with the old init system where it was started realtively early, there simply wasn't as much competition for disk and perhaps there also weren't as many things to copy over into the chroot. I've switched chrooting off as an experiment, lets see if the boot times go back to something halfway sane (it's an old machine, so that'll still be some time). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org