Package: systemd Version: 239-1 Severity: normal Dear Michael, dear Maintainers,
Since using kernel 4.17-rc7 I think (now using self compiled 4.17 vanilla kernel), I see a strange new behavior on this ThinkPad T520. I did not yet test whether it is related to the kernel or something else I upgraded at around the same time. On a fresh boot system sddm login screen does not appear until after more than a minute. There is just tty1 login prompt. Often as I logged in as root to see what is up, sddm comes up. But this might just be a co-incidence. I´d need to test whether it comes up without me doing anything. Or whether logging in as root on tty1 is a necessary pre-condition for sddm to come up (unlikely I think). What I see is this: % systemd-analyze blame | head -20 1min 30.108s chrony.service 4.671s NetworkManager-wait-online.service 1.987s keyboard-setup.service 1.974s dev-mapper-sata\x2ddebian.device 1.061s privoxy.service 909ms udisks2.service 653ms postfix@-.service 614ms networking.service 508ms ModemManager.service 504ms NetworkManager.service 455ms sysfsutils.service 440ms systemd-logind.service 439ms thermald.service 404ms avahi-daemon.service 399ms wpa_supplicant.service 378ms rtkit-daemon.service 260ms tlp.service 252ms libvirtd.service 222ms mnt-home\x2dzeit.mount 212ms home.mount % systemctl --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION ● chrony.service loaded failed failed chrony, an NTP client/server ● upower.service loaded failed failed Daemon for power management […] I think at some time I also saw NetworkManager-wait-online.service not coming up properly. % systemctl status upower ● upower.service - Daemon for power management Loaded: loaded (/lib/systemd/system/upower.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2018-06-25 08:58:19 CEST; 10min ago Docs: man:upowerd(8) Process: 3263 ExecStart=/usr/lib/upower/upowerd (code=exited, status=127) Main PID: 3263 (code=exited, status=127) Jun 25 08:58:19 merkaba systemd[1]: upower.service: Service RestartSec=100ms expired, scheduling restart. Jun 25 08:58:19 merkaba systemd[1]: upower.service: Scheduled restart job, restart counter is at 5. Jun 25 08:58:19 merkaba systemd[1]: Stopped Daemon for power management. Jun 25 08:58:19 merkaba systemd[1]: upower.service: Start request repeated too quickly. Jun 25 08:58:19 merkaba systemd[1]: upower.service: Failed with result 'exit-code'. Jun 25 08:58:19 merkaba systemd[1]: Failed to start Daemon for power management. % systemctl status chrony ● chrony.service - chrony, an NTP client/server Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Mon 2018-06-25 08:49:28 CEST; 19min ago Docs: man:chronyd(8) man:chronyc(1) man:chrony.conf(5) Process: 1574 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=killed, signal=TERM) Jun 25 08:47:59 merkaba systemd[1]: Starting chrony, an NTP client/server... Jun 25 08:47:59 merkaba chronyd[1599]: chronyd version 3.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) Jun 25 08:47:59 merkaba chronyd[1599]: Frequency -3.369 +/- 0.300 ppm read from /var/lib/chrony/chrony.drift Jun 25 08:49:28 merkaba systemd[1]: chrony.service: Start operation timed out. Terminating. Jun 25 08:49:28 merkaba systemd[1]: chrony.service: Failed with result 'timeout'. Jun 25 08:49:28 merkaba systemd[1]: Failed to start chrony, an NTP client/server. Often I start up DSL modem, Omnia Turris router and laptop at the same time. Omnia Turris may take a file to provide a working network. But I do not know whether the issue is network related. I also see this on reboots while Omnia Turris and DSL modem are already up and running. I attach journalctl -xb output from the last boot process with the issue. If you need anything else, please ask. Please allow for some delay in replying, as I have other more important issues for me to handle at the moment. Also my motivation to work on debugging it may be a bit limited as I consider to switch this machine to Devuan with sysvinit or runit like I did with two of my server VMs already. I am willing to invest some effort in order to provide any information you request. How much, I will see. Thanks, Martin -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de (charmap=UTF-8) 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-4 ii libaudit1 1:2.8.3-1 ii libblkid1 2.32-0.1 ii libc6 2.27-3 ii libcap2 1:2.25-1.2 ii libcryptsetup12 2:2.0.3-4 ii libgcrypt20 1.8.3-1 ii libgnutls30 3.5.18-1 ii libgpg-error0 1.31-1 ii libidn11 1.33-2.2 ii libip4tc0 1.6.2-1 ii libkmod2 25-1 ii liblz4-1 1.8.2-1 ii liblzma5 5.2.2-1.3 ii libmount1 2.32-0.1 ii libpam0g 1.1.8-3.7 ii libseccomp2 2.3.3-2 ii libselinux1 2.8-1 ii libsystemd0 239-1 ii mount 2.32-0.1 ii procps 2:3.3.15-2 ii util-linux 2.32-0.1 Versions of packages systemd recommends: ii dbus 1.12.8-3 ii libpam-systemd 239-1 Versions of packages systemd suggests: ii policykit-1 0.105-20 pn systemd-container <none> Versions of packages systemd is related to: pn dracut <none> ii initramfs-tools 0.130 ii udev 239-1 -- Configuration Files: /etc/systemd/resolved.conf changed: [Resolve] FallbackDNS= -- no debconf information _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers