Am 21.09.19 um 08:53 schrieb Marc Haber: > On Sat, Sep 21, 2019 at 12:06:51AM +0200, Michael Biebl wrote: >> Ok, thanks. I have a feeling we are getting closer. >> If you (temporarily) disable ippl (via update-rc.d ippl disable), what >> do you get on next reboot for >> systemctl status >> systemctl list-jobs > > [4/4986]mh@banana:~ $ sudo systemctl status > [sudo] password for mh on banana: > ● banana > State: starting > Jobs: 16 queued > Failed: 0 units > Since: Sat 2019-09-21 08:32:11 CEST; 17min ago > CGroup: / > ├─user.slice > │ └─user-1001.slice > │ ├─session-7.scope > │ │ ├─2477 sshd: mh [priv] > │ │ ├─2542 sshd: mh@pts/0,pts/1 > │ │ ├─2543 -bash > │ │ ├─3202 sudo dpkg --configure -a > │ │ ├─3203 dpkg --configure -a > │ │ ├─3204 sh -c (test -x /usr/lib/needrestart/dpkg-status && > /usr/lib/needrestart/dpkg-status || cat > > │ │ ├─3205 sh -c (test -x /usr/lib/needrestart/dpkg-status && > /usr/lib/needrestart/dpkg-status || cat > > │ │ ├─3206 /bin/sh /usr/lib/needrestart/dpkg-status > │ │ ├─3347 /usr/bin/perl -w /usr/share/debconf/frontend > /var/lib/dpkg/info/man-db.postinst configure 2> > │ │ ├─3353 /bin/sh /var/lib/dpkg/info/man-db.postinst configure > 2.8.7-1 > │ │ ├─5270 /bin/systemctl start man-db.timer > │ │ ├─5282 -bash > │ │ ├─5409 sudo systemctl status > │ │ ├─5410 systemctl status > │ │ └─5411 pager > │ └─user@1001.service > │ └─init.scope > │ ├─2480 /lib/systemd/systemd --user > │ └─2481 (sd-pam) > ├─init.scope > │ └─1 /sbin/init > └─system.slice > ├─irqbalance.service > │ └─277 /usr/sbin/irqbalance --foreground > ├─systemd-time-wait-sync.service > │ └─190 /lib/systemd/systemd-time-wait-sync > ├─dbus.service > │ └─292 /usr/bin/dbus-daemon --system --address=systemd: > --nofork --nopidfile --systemd-activation --s> > ├─avahi-daemon.service > │ ├─279 avahi-daemon: running [banana.local] > │ └─288 avahi-daemon: chroot helper > ├─system-serial\x2dgetty.slice > │ └─serial-getty@ttyS0.service > │ └─355 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 > ttyS0 vt220 > ├─ntp.service > │ └─340 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:113 > ├─system-getty.slice > │ └─getty@tty1.service > │ └─350 /sbin/agetty -o -p -- \u --noclear tty1 linux > ├─smartd.service > │ └─282 /usr/sbin/smartd -n > ├─systemd-logind.service > │ └─287 /lib/systemd/systemd-logind > ├─systemd-resolved.service > │ └─265 /lib/systemd/systemd-resolved > ├─mini-buildd.service > │ ├─285 /usr/bin/python2 /usr/sbin/mini-buildd --verbose -W > :::8066 > │ ├─529 gpg-agent --homedir /var/lib/mini-buildd/.gnupg > --use-standard-socket --daemon > │ └─538 gpg-agent --homedir > /var/lib/mini-buildd/var/tmp/tmp4tlVYb --use-standard-socket --daemon > ├─cron.service > │ └─3338 /usr/sbin/cron -f > ├─systemd-udevd.service > │ └─202 /lib/systemd/systemd-udevd > ├─rsyslog.service > │ └─298 /usr/sbin/rsyslogd -n -iNONE > ├─atop.service > │ └─315 /usr/bin/atop -R -w /var/log/atop/atop_20190921 600 > ├─atd.service > │ └─299 /usr/sbin/atd -f > ├─systemd-journald.service > │ └─193 /lib/systemd/systemd-journald > ├─atopacct.service > │ └─291 /usr/sbin/atopacctd > ├─haveged.service > │ └─266 /usr/sbin/haveged --Foreground --verbose=1 -w 1024 > └─systemd-networkd.service > └─208 /lib/systemd/systemd-networkd > [5/4987]mh@banana:~ $ sudo systemctl list-jobs > JOB UNIT TYPE STATE > 74 logrotate.timer start waiting > 96 anacron.service start waiting > 69 fstrim.timer start waiting > 66 anacron.timer start waiting > 72 man-db.timer start waiting > 24 time-sync.target start waiting > 2 multi-user.target start waiting > 67 apt-daily.timer start waiting > 73 e2scrub_all.timer start waiting > 65 timers.target start waiting > 86 systemd-update-utmp-runlevel.service start waiting > 70 apt-daily-upgrade.timer start waiting > 128 exim4.service start waiting > 71 exim4-base.timer start waiting > 58 systemd-time-wait-sync.service start running
Hm, this service is not enabled by default and I'm guessing it prevents time-sync.target to be reached, blocking all subsequent services. Have you enabled this service manually? What happens if you disable this service? I see that you use ntp, so systemd-timesyncd will/should not be active for you. If you read man 8 systemd-time-wait-sync.service > systemd-time-wait-sync is a system service that delays the start of > units that depend on time-sync.target > until the system time has been synchronized with an accurate time > source by systemd-timesyncd.service. > > systemd-timesyncd.service notifies on successful synchronization. > systemd-time-wait-sync also tries to > detect when the kernel marks the time as synchronized, but this > detection is not reliable and is intended > only as a fallback for other servies that can be used to synchronize > time (e.g., ntpd, chronyd). > Maybe you should only use systemd-time-wait-sync.service in combination with systemd-timesyncd. The man page explicitly warns that using it combination with other NTP clients can be unreliable. > Now, speaking with my ippl maintainer hat on, what was the information > that made you take a closer look at ippl? It was in the list of queued jobs and a quick apt-file search ippl.service did not reveal anything, so I was wondering if this was maybe a 3rd party service file. -- 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
