Siduction Forum
Siduction Forum => Software - Support => Topic started by: cs on 2017/09/17, 10:22:53
-
Hallo,
seit dem Update auf Plasma / KDE5 habe ich mit Siduction folgendes Problem:
Nach dem Login (egal ob mit SDDM oder LightDM) scheint mein eigentlich schnelles Notebook (Betriebssystem auf SSD) eine Denkpause von ca. 30 Sekunden einzulegen, bevor es weitergeht und der KDE-Desktop erscheint.
Das Phänomen wird laut entsprechender Internet-Threads wohl verschiedentlich mit KDE5 beobachtet: Mal ist plasma-nm schuld (https://bugs.launchpad.net/ubuntu/+source/plasma-nm/+bug/1509334 (https://bugs.launchpad.net/ubuntu/+source/plasma-nm/+bug/1509334)), mal der Boot-Splash (https://bugs.launchpad.net/ubuntu/+source/breeze/+bug/1584604 (https://bugs.launchpad.net/ubuntu/+source/breeze/+bug/1584604)). Für mich hat leider kein Workaround gewirkt, z. B. nicht das Abschalten des Bootsplash.
Hat noch jemand das Problem oder könnte mir Hinweise geben, wie ich an das Problem herankomme?
Hier mein System:
System: Host: cord-x230 Kernel: 4.13.2-towo.1-siduction-amd64 x86_64 bits: 64 gcc: 7.2.0
Desktop: KDE Plasma 5.10.5 (Qt 5.9.1) dm: lightdm
Distro: siduction 16.1.0 Patience - kde - (201612232347)
Machine: Device: laptop System: LENOVO product: 2325CN9 v: ThinkPad X230 serial: N/A
Mobo: LENOVO model: 2325CN9 serial: N/A UEFI [Legacy]: LENOVO v: G2ETA7WW (2.67 ) date: 09/09/2016
Chassis: type: 10 serial: N/A
Battery BAT0: charge: 86.3 Wh 96.8% condition: 89.2/93.2 Wh (96%) volts: 12.7/11.1
model: LGC 45N1029 Li-ion serial: 15147 status: N/A cycles: 0
CPU: Dual core Intel Core i7-3520M (-HT-MCP-) arch: Ivy Bridge rev.9 cache: 4096 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 11574
clock speeds: min/max: 1200/2901 MHz 1: 2893 MHz 2: 2893 MHz 3: 2893 MHz 4: 2893 MHz
Memory: Using dmidecode: root required for dmidecode
Graphics: Card: Intel 3rd Gen Core processor Graphics Controller bus-ID: 00:02.0 chip-ID: 8086:0166
Display Server: x11 (X.Org 1.19.3 ) drivers: modesetting (unloaded: fbdev,vesa)
Resolution: 1366x768@60.02hz
OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile
version: 4.2 Mesa 17.2.0 (compat-v: 3.0) Direct Render: Yes
-
Ich habe das gleiche Problem sowohl auf einem Desktop System als auch einem Laptop.
Habe leider auch keine Lösung.
bevo
-
dito bei mir, auf Desktop.
Das ist erst nach hier https://forum.siduction.org/index.php?topic=6845.0 entstanden.
Bin auch am suchen und weiß noch nicht recht, wo ich anfangen soll :-\
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @28.105s
└─multi-user.target @28.105s
└─hddtemp.service @27.508s +596ms
└─network-online.target @27.506s
└─NetworkManager-wait-online.service @22.505s +4.999s
└─NetworkManager.service @17.272s +5.224s
└─dbus.service @16.458s
└─basic.target @16.453s
└─sockets.target @16.453s
└─cups.socket @16.453s
└─sysinit.target @16.441s
└─systemd-timesyncd.service @14.307s +2.133s
└─systemd-tmpfiles-setup.service @14.146s +142ms
└─local-fs.target @14.063s
└─tmp.mount @14.059s +3ms
└─swap.target @13.979s
└─dev-disk-by\x2duuid-045398f2\x2ddfbc\x2d4cc5\x2d99c5\x2ddca098051969.swap @13.890s +88ms
└─dev-disk-by\x2duuid-045398f2\x2ddfbc\x2d4cc5\x2d99c5\x2ddca098051969.device @13.889s$ systemd-analyze blame | head
11.396s dev-sda11.device
8.391s systemd-journal-flush.service
8.027s ModemManager.service
7.910s apt-daily-upgrade.service
7.212s udisks2.service
5.224s NetworkManager.service
5.020s systemd-udevd.service
4.999s NetworkManager-wait-online.service
3.433s accounts-daemon.service
2.133s systemd-timesyncd.service$ systemd-analyze
Startup finished in 18.933s (kernel) + 28.112s (userspace) = 47.046s
-
Ne mögliche Lösung wäre wahrscheinlich:
systemctl mask network-manager.wait-online.serviceeinfach mal probieren und bitte Rückmeldung
-
Danke für den Tip. Leider keine Veränderung. :(
systemctl mask NetworkManager-wait-online.service
Created symlink /etc/systemd/system/NetworkManager-wait-online.service → /dev/null.
nach rebootsystemctl status NetworkManager-wait-online.service
● NetworkManager-wait-online.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
Heute Mittag hatte ich schon den ModemManager.service disabeld. Ebenso :-\
-
Hier gleiches Ergebnis wie bei @unklarer.
-
Schade eigentlich - ok, ich weigere mich jetzt einfach mal, launchpad bugs, die von tiefster Sachkenntnis geprägt sind, irgendeine Releavanz beizumessen. können wir noch mal nen blame und nen critical path zu sda11 haben?
Disclaimer - es gab da einige "kleinere" Veränderungen im Bereich udisks
-
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @20.693s
└─udisks2.service @16.275s +4.417s
└─basic.target @15.239s
└─sockets.target @15.239s
└─avahi-daemon.socket @15.238s
└─sysinit.target @15.217s
└─systemd-timesyncd.service @13.624s +1.592s
└─systemd-tmpfiles-setup.service @13.362s +244ms
└─systemd-journal-flush.service @2.581s +10.779s
└─systemd-remount-fs.service @2.116s +463ms
└─system.slice @2.034s
└─-.slice @2.006s$ systemd-analyze blame
10.779s systemd-journal-flush.service
8.515s dev-sda11.device
4.417s udisks2.service
3.698s NetworkManager.service
3.656s accounts-daemon.service
2.027s networking.service
1.956s colord.service
1.891s preload.service
1.891s dns-clean.service
1.592s systemd-timesyncd.service
1.321s lm-sensors.service
1.188s systemd-tmpfiles-setup-dev.service
1.155s systemd-udevd.service
1.155s qemu-guest-agent.service
1.062s console-kit-log-system-start.service
1.038s keyboard-setup.service
930ms rpcbind.service
905ms polkit.service
887ms virtualbox-guest-utils.service
886ms systemd-logind.service
854ms pppd-dns.service
816ms rtkit-daemon.service
815ms avahi-daemon.service
644ms run-rpc_pipefs.mount
600ms gpm.service
549ms systemd-modules-load.service
469ms dev-mqueue.mount
463ms systemd-remount-fs.service
447ms sys-kernel-debug.mount
444ms dev-hugepages.mount
416ms loadcpufreq.service
387ms systemd-sysctl.service
344ms speech-dispatcher.service
333ms upower.service
322ms systemd-udev-trigger.service
297ms console-setup.service
284ms systemd-random-seed.service
249ms lightdm.service
249ms openvpn.service
248ms systemd-update-utmp.service
244ms media-Distris.mount
244ms systemd-tmpfiles-setup.service
243ms systemd-user-sessions.service
240ms kmod-static-nodes.service
233ms systemd-journald.service
223ms hddtemp.service
183ms cpufrequtils.service
163ms dev-disk-by\x2duuid-045398f2\x2ddfbc\x2d4cc5\x2d99c5\x2ddca098051969.swap
153ms console-kit-daemon.service
151ms systemd-tmpfiles-clean.service
84ms nfs-config.service
71ms user@1000.service
62ms ssh.service
60ms media-DATEN.mount
12ms alsa-restore.service
6ms systemd-update-utmp-runlevel.service
3ms tmp.mount
2ms sys-fs-fuse-connections.mount
lines 23-58/58 (END)
-
Leider auch kein Beitrag zur Lösung, lediglich eine Bestätigung des unangenehmen Phänomens auf den Maschinen von @piper und @samoht:
https://forum.siduction.org/index.php?topic=6826.msg55632#msg55632 (https://forum.siduction.org/index.php?topic=6826.msg55632#msg55632)
-
@unklarer evtl. ein möglicher Workaround für dich:
Wenn du den Networkmanager nicht brauchst (zB. an einem PC der nur per Kabel am LAN hängt) dann ersetze den NM durch systemd-networkd. Ich hatte hier schon mal im Forum einen Post eingestellt. Der läuft bei mir seit jahren völlig stressfrei.
In meinem Wiki habe dazu auche einen Artikel erstellt:
https://mywiki.bluelupo.net/wiki/Umstellung_des_kabelgebundenen_Netzwerkes_auf_systemd-networkd
-
Hallo bluelupo, :)
danke für deinen Hinweis und deine Arbeit.
Hier in der patience mit plasma5 war ich bisher zu faul das auch anzuwenden.
In der älteren Paint_it_Black mit LXDE, auch auf diesen Rechner, ist es Standard. ;) ... und, dein Wiki hat ein Lesezeichen, weil ich da sehr oft stöbere.
-
Und bevor das hier in freundliches hijacking ;) ausartet (die Tipps und Lösungsversuche helfen ja vielleicht auch dem Thread-Eröffner), können wir bitte von cs mal ein 'systemd-analyze blame' und 'systemd-analyze critical-chain' bekommen? Dazu vielleicht noch ein 'systemctl status sddm.service' und 'journalct -b -p err' ...
-
@der_Bud: Sehr gern, siehe weiter unten!
Vom Login unter SDDM oder LightDM bis zum Erscheinen des Desktop vergehen bei mir de facto ganze 50 Sekunden, ohne dass sich das Notebook zu rühren scheint.
systemd-analyze blame:
.397s NetworkManager-wait-online.service
777ms apt-daily.service
726ms dev-sdb1.device
625ms systemd-journal-flush.service
600ms tpdaemon.service
551ms tvheadend.service
539ms apt-daily-upgrade.service
508ms udisks2.service
448ms snapd.service
350ms wpa_supplicant.service
300ms dev-loop1.device
300ms dev-loop0.device
292ms networking.service
287ms dev-loop2.device
265ms inputlirc.service
265ms lircd-setup.service
260ms ModemManager.service
197ms loadcpufreq.service
173ms lvm2-monitor.service
168ms preload.service
166ms NetworkManager.service
165ms disks-disk1part1.mount
162ms systemd-tmpfiles-setup-dev.service
161ms gpm.service
160ms systemd-logind.service
159ms accounts-daemon.service
144ms keyboard-setup.service
142ms systemd-backlight@backlight:intel_backlight.service
128ms systemd-udevd.service
123ms snapd.autoimport.service
119ms ssh.service
113ms lightdm.service
108ms dev-disk-by\x2duuid-828dbf80\x2dd1e7\x2d468b\x2dace2\x2ddbb4b20d3b0f.swap
104ms systemd-modules-load.service
102ms virtualbox-guest-utils.service
98ms smbd.service
92ms upower.service
90ms qemu-guest-agent.service
87ms colord.service
81ms disks-disk1part2.mount
78ms speech-dispatcher.service
systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @7.225s
└─multi-user.target @7.224s
└─smbd.service @7.126s +98ms
└─nmbd.service @7.077s +48ms
└─network-online.target @7.073s
└─NetworkManager-wait-online.service @2.675s +4.397s
└─NetworkManager.service @2.491s +166ms
└─dbus.service @2.423s
└─basic.target @2.409s
└─sockets.target @2.408s
└─snapd.socket @2.395s +10ms
└─sysinit.target @2.388s
└─systemd-timesyncd.service @2.339s +48ms
└─systemd-tmpfiles-setup.service @2.326s +11ms
└─local-fs.target @2.323s
└─disks-disk1part1.mount @2.156s +165ms
└─dev-disk-by\x2duuid-53d1cd6b\x2dfe31\x2d469c\x2d9bfd\x2d20ef0bfc8e34.device @1.341s
systemctl status sddm.service
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/lib/systemd/system/sddm.service; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:sddm(1)
man:sddm.conf(5)
journalctl -b -p err
-- Logs begin at Thu 2017-08-24 11:21:04 CEST, end at Mon 2017-09-18 12:00:45 CEST. --
Sep 18 07:53:28 cord-x230 kernel: tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
Sep 18 07:53:29 cord-x230 systemd[1]: Swap dev-disk-by\x2dlabel-swap.swap appeared twice with different device paths /dev/sdb2 and /dev/sda3
Sep 18 07:53:29 cord-x230 avahi-daemon[568]: chroot.c: open() failed: No such file or directory
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event10 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event11 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event12 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event13 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event14 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event15 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event2 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event6 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 inputlircd[633]: /dev/input/event9 does not support EV_KEY events
Sep 18 07:53:30 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:30 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:30 cord-x230 tvheadend[805]: access: No access entries loaded
Sep 18 07:53:31 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:32 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:33 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:34 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:34 cord-x230 systemd[1]: Failed to start Automatically refresh installed snaps.
Sep 18 07:53:35 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:36 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:37 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:38 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:39 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:40 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:24 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:25 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:26 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:11 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:12 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:13 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:14 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:15 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:16 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:17 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:18 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:19 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:20 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:21 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
Sep 18 07:53:22 cord-x230 lircd-0.10.0[746]: Error: Cannot glob /sys/class/rc/rc0/input[0-9]*/event[0-9]*
-
Hi,
soeben hat's ein Update für udisk2 gegeben, vielleicht hilft das ja.
Gruß dsat
-
cs, bei Deinem systemd-analyze fällt mir zumindest auf Anhieb erstmal nichts kritisches ins Auge, außer das lightdm.service gestartet wird und daher ein 'systemctl status lightdm.service' statt sddm sinnvoll wäre (hab aus Deinem Startpost nicht herausgelassen bei welchem Du aktuell gelandet bist).
Im journalctl fällt auf, dass für sdb2 und sda3 gleiche Label angemeckert werden kann das sein? Das würde zumindest zu Irritationen führen. Dann hagelt es Meldungen zu lirc, hat das nicht was mit IR-Devices zu tun? Vielleicht mal dahingehend forschen, ob alles richtig installiert ist was Du brauchst (mit solchen Geräten kenn ich mich nicht aus).
-
@dsat: Das Update von gerade eben hat die Verzögerung leider nicht vermindert.
@der_Bud: LIRC (d.h. Infrarotfernbedienungen) nutze ich gar nicht. Kann man das irgendwie abschalten?
Die Partitionen habe ich ja seit dem Update auf KDE5 nicht verändert und vorher gab's diese Verzögerungen nicht. Dann wär's seltsam, wenn es an den Labels liegen würde, oder?
Hier die Ausgabe von systemctl status lightdm.service
● lightdm.service - Light Display Manager
Loaded: loaded (/lib/systemd/system/lightdm.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-09-18 14:43:35 CEST; 3min 32s ago
Docs: man:lightdm(1)
Process: 768 ExecStartPre=/bin/sh -c [ "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/lightdm" ] (code=exited, status=0/SUCCESS)
Main PID: 771 (lightdm)
CGroup: /system.slice/lightdm.service
├─771 /usr/sbin/lightdm
└─786 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
Sep 18 14:43:35 cord-x230 systemd[1]: Starting Light Display Manager...
Sep 18 14:43:35 cord-x230 systemd[1]: Started Light Display Manager.
Sep 18 14:43:37 cord-x230 lightdm[771]: user_get_uid: assertion 'user != NULL' failed
Sep 18 14:43:37 cord-x230 lightdm[2216]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
Sep 18 14:45:00 cord-x230 lightdm[7726]: pam_unix(lightdm:session): session opened for user cord by (uid=0)
-
I have this problem also,(which was also posted here https://forum.siduction.org/index.php?topic=6826.msg55567#msg55567) this is experimental, I have a regular debian install (experimental also) with the same exact packages installed, but, no lag/wait time to login.
I have purged mythtv, mariadb, masked network-manager.wait-online.service, etc, to no avail.
I am going to make a new build and start from scratch, not today, I had a long day at work and I am cranky and tired ;)
systemctl status sddm.service
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/lib/systemd/system/sddm.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-09-18 09:32:15 EDT; 30min ago
Docs: man:sddm(1)
man:sddm.conf(5)
Main PID: 800 (sddm)
CGroup: /system.slice/sddm.service
├─800 /usr/bin/sddm
└─969 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{051198af-358a-4fe6-88f5-716f1dd1863f} -background none -noreset -displa
Sep 18 09:32:15 x1 systemd[1]: Starting Simple Desktop Display Manager...
Sep 18 09:32:15 x1 systemd[1]: Started Simple Desktop Display Manager.
Sep 18 09:32:28 x1 sddm-helper[1181]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Sep 18 09:33:00 x1 sddm-helper[2714]: pam_unix(sddm:session): session opened for user piper by (uid=0)
systemd-analyze critical-chain
graphical.target @49.974s
└─multi-user.target @49.974s
└─mythtv-backend.service @33.992s +5.105s
└─mariadb.service @23.901s +10.089s
└─network.target @23.893s
└─NetworkManager.service @18.244s +5.646s
└─dbus.service @16.962s
└─basic.target @16.953s
└─sockets.target @16.952s
└─cups.socket @16.951s
└─sysinit.target @16.798s
└─systemd-timesyncd.service @15.494s +1.303s
└─systemd-tmpfiles-setup.service @15.372s +93ms
└─systemd-journal-flush.service @1.746s +13.622s
└─systemd-remount-fs.service @1.457s +242ms
└─systemd-journald.socket @1.425s
└─-.mount @1.414s
└─system.slice @1.423s
└─-.slice @1.413s
systemd-analyze blame | head
13.622s systemd-journal-flush.service
10.874s mythtv-status.service
10.089s mariadb.service
8.418s udisks2.service
6.124s dev-sda10.device
5.646s NetworkManager.service
5.105s mythtv-backend.service
5.056s loadcpufreq.service
5.010s apache2.service
4.531s disks-disk1part5.mount
-
@Cord - komm mal in den IRC, wir sollten ein wenig aufräumen :D
-
Hier an meinem Laptop keine Probleme nach aktuell heute ausgeführten d-u.
# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @7.194s
└─multi-user.target @7.194s
└─postfix.service @7.191s +2ms
└─postfix@-.service @6.802s +387ms
└─network-online.target @6.801s
└─NetworkManager-wait-online.service @2.163s +4.637s
└─NetworkManager.service @2.025s +135ms
└─dbus.service @1.969s
└─basic.target @1.947s
└─sockets.target @1.946s
└─pywwetha.socket @1.945s
└─sysinit.target @1.935s
└─systemd-timesyncd.service @1.873s +61ms
└─systemd-tmpfiles-setup.service @1.858s +7ms
└─systemd-journal-flush.service @1.738s +119ms
└─var.mount @1.717s +15ms
└─systemd-fsck@dev-disk-by\x2dlabel-VAR.service @1.671s +45ms
└─local-fs-pre.target @1.670s
└─keyboard-setup.service @137ms +1.533s
└─systemd-journald.socket @129ms
└─-.slice @121ms
# systemd-analyze blame
4.637s NetworkManager-wait-online.service
1.533s keyboard-setup.service
576ms console-setup.service
387ms postfix@-.service
354ms dev-mapper-VGsys\x2dLVroot.device
255ms udisks2.service
231ms loadcpufreq.service
192ms accounts-daemon.service
180ms ModemManager.service
135ms NetworkManager.service
134ms colord.service
127ms systemd-logind.service
119ms systemd-journal-flush.service
104ms ssh.service
103ms lm-sensors.service
103ms gpm.service
97ms alsa-restore.service
86ms pppd-dns.service
81ms cpufrequtils.service
80ms preload.service
80ms upower.service
77ms systemd-journald.service
67ms systemd-udev-trigger.service
64ms bluetooth.service
61ms systemd-timesyncd.service
60ms lvm2-monitor.service
60ms systemd-fsck@dev-disk-by\x2dlabel-HOME.service
55ms systemd-udevd.service
50ms avahi-daemon.service
49ms systemd-fsck@dev-disk-by\x2dlabel-MISC.service
47ms polkit.service
45ms systemd-fsck@dev-disk-by\x2dlabel-VAR.service
38ms user@1000.service
33ms systemd-fsck@dev-disk-by\x2dlabel-BOOT.service
32ms systemd-tmpfiles-clean.service
32ms systemd-tmpfiles-setup-dev.service
31ms dns-clean.service
28ms systemd-modules-load.service
26ms systemd-cryptsetup@cryptsda2.service
25ms systemd-user-sessions.service
24ms openvpn.service
22ms dev-mapper-VGsys\x2dLVswap.swap
22ms mnt-share-misc.mount
18ms boot.mount
16ms wpa_supplicant.service
16ms run-rpc_pipefs.mount
15ms systemd-rfkill.service
15ms var.mount
15ms systemd-backlight@backlight:intel_backlight.service
14ms sddm.service
14ms rpcbind.service
13ms sys-kernel-debug.mount
13ms dev-hugepages.mount
12ms dev-mqueue.mount
11ms systemd-random-seed.service
10ms hddtemp.service
10ms systemd-remount-fs.service
10ms systemd-sysctl.service
8ms kmod-static-nodes.service
8ms systemd-update-utmp.service
8ms nfs-config.service
8ms home.mount
7ms systemd-tmpfiles-setup.service
6ms systemd-update-utmp-runlevel.service
2ms postfix.service
-
Im englischsprachigen Teil ist das jetzt auch einmal geposted (finotti) (https://forum.siduction.org/index.php?topic=6856.msg55711#msg55711), da scheint also was im Busche zu sein...
-
Handaufleg: Ich hab das auf meinem kleinen Lappi installiert und alles ist fein - die einzigen Unterschiede, die ich bis jetzt sehe sind die verwendeten Grafik-Treiber.
-
@melmarker: Ich hab integrierte Intel-Grafik: Kann ich da einen anderen Grafik-Treiber verwenden bzw. testen? Wenn mir jemand einen Tipp gibt, probier' ich's gern aus.
Hier nochmal meine Grafik-Hardware:
Graphics: Card: Intel 3rd Gen Core processor Graphics Controller
Display Server: x11 (X.Org 1.19.3 ) drivers: modesetting (unloaded: fbdev,vesa)
Resolution: 1366x768@60.02hz
OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile version: 4.2 Mesa 17.2.1
Übrigens: Hab mal spaßeshalber Gnome mit Wayland installiert: Startet alles ohne Verzögerung. Schade, bin eigentlich kein Gnome-Fan ...
-
Hi,
hier habe ich das Problem auch, allerdings nicht auf allen Rechnern. Alle Rechner wurden regelmäßig aktualisiert:
- T530: neue Installation Anfang August, intel-GraKa --> keine Probleme
- T500: alte Installation, vor 2017, intel-GraKa --> Verzögerung beim Login
- T61: alte Installation, vor 2017, nvidia-Graka --> Verzögerung beim Login
Meine Beobachtung:
- Die Verzögerung tritt auch bei wiederholtem Login auf.
- Die Verzögerung tritt/trat auf T500 bei allen Kombinationen von KDE, LXDE, intel und nvidia auf.
- Nach einer Neuinstallation von T500 war das Problem behoben.
Eine Neuinstallation von T61 will ich mir vorerst sparen. Ich möchte gerne wissen, woran das liegt ;-)
Gruß
Thomas
-
Hmm,
wenn es dem Esel zuu wohl wird geht er aufs Eis oder installert sich zusätzlich zu XfCE zum Test auch noch KDE. ;)
Habe ich letzte Nacht gemacht und habe jetzt dasselbe Problem, allerdings ohne KDE zu starten.
Nach dem Login per sddm kommt gefühlte Ewigkeit nur ein schwarzer Schirm mit dem Mauscursor bevor sich dann der XFCE-Desktop aufbaut. Ansonsten alles normal bis jetzt.
Bin mir daher auch nicht sicher ob das wirklich KDE-Related ist.
Als einziges KDE-Programm scheint okular im Hintergrund zu laufen, sonst sehe ich da aktuell nix von KDE.
Werde mal versuchen das rauszuschmeissen um zu sehen ob das was bringt.
Grüße
Reiner
-
Soderle,
da hatte sich auch noch kaccessibelapp rumgetrieben, aber jetzt nach dem Abmelden und Neustart von sddm sind das und auch Okular weg. Leider hat sich an der "Kaffeepause" nichts geändert. :(
Grüße
Reiner
-
Hatte jetzt sddm in Verdacht da da anscheinend was mitkam und mal gdm3 und lighdm probiert.
Mit gdm 3 falle ich direkt wieder auf die Anmeldung zurück, mit lightdm gibts auch die "Kaffeepause" nur bleibt das Hintergrundbild bis zur XFCE-Session da und der Schirm wird nicht schwarz.
Grüße
Reiner
-
Hmm, noch was Selsames (seit heute).
Anscheinend werde ich jetzt nach einiger Zeit automatisch "abgeneldet".
Ist mir 2 mal aufgefallen, 1 mal mitten im "Betrieb" und einmal als ich kurz weg war.
Jedesmal kam der Anmeldescreen, ich meldete mich an und nach der "Kaffeepause" gings dann weiter.
Grüße
Reiner
-
Du hattest doch lightdm nachinstalliert, da wird es dir auch light-locker mit installiert haben. Der sperrt den Bildschirm und, anders als xscreensaver, verwendet zur Eingabe der Logindaten den Anmeldebildschirm.
-
Nein, den hatte ich schon drauf aber nicht aktiv. Den light-locker hatte ich aus anderen Gründen schon länger deinstalliert.
Ausserdem hatte ich wieder auf sddm gewechselt.
Grüße
Reiner
-
... - T530: neue Installation Anfang August, intel-GraKa --> keine Probleme
- T500: alte Installation, vor 2017, intel-GraKa --> Verzögerung beim Login
- T61: alte Installation, vor 2017, nvidia-Graka --> Verzögerung beim Login
...
Bei mir auf den ersten Blick identische Hardware wie 3. (T61: alte Installation, vor 2017, nvidia-Graka), aber hier keine Verzögerung. Daher wäre vielleicht ein direkter Vergleich der Hardware/Pakete/Autostarteinträge/Dienste/etc zwischen TommiO und mir interessant, kann aber leider frühestens heute abend ran.
Ideen was man noch vergleichen sollte? Und wie kann man sowas weiter debuggen, aus grub nach init3 starten und dann 'startx' ,während auf anderen VTs journalctl tailt oder dmesg oder top/htop läuft?
-
Mit startx habe ich es gerade auch propiert. Ebenfalls "Kaffeepause".
Was mehr stört ist dass ich immer wieder mitten beim Arbeiten abgemeldet werde.
Habe auch ne relativ "alte" Installation aber noch von Anfang 2017 und Intel Grafikkarte
Grüße
Reiner
-
Hallo Leute,
ich habe das Verzeichnis /etc/X11/Xsession.d von einer funktionierenden, neuen Installation auf meinen Problemrechner (T61) transplantiert --> Login funktioniert wieder ohne Verzögerung
Gruß
Thomas
-
Hmm, werde ich morgen füh auch mal testen.
Grüße
Reiner
-
Hat erstmal anscheinend leider nix gebracht.
Was mir auffällt ist dass das automatische "Abmelden" jetzt schon über 4 Stunden nicht aufgetreten ist seitdem ich X mit startx gestartet habe. Sind vielleicht 2 unabhängige Probleme.
Grüsse
Reiner
-
TommyO,
kannst du denn mal die Dateien in dem Verzeichnis auflisten? So bringt das leider niemandem was.
-
Die Dateien des T61 mit dem Login-Problem:
20x11-common_process-args
30x11-common_xresources
35x11-common_xhost-local
40x11-common_xsessionrc
50x11-common_determine-startup
70systemd
75dbus_dbus-launch
90gpg-agent
90qt5-opengl
90x11-common_ssh-agent
95dbus_update-activation-env
98vboxadd-xclient
99x11-common_start
Gruss
Thomas
-
Die Schlinge zieht sich zu:
98vboxadd-xclient in funktionierende, neue Installation kopiert --> Login langsam
/etc/X11/Xsession.d/98vboxadd-xclient scheint zumindest bei mir der Übeltäter zu sein.
Gruß
Thomas
-
Sieh mal einer an, die 98vboxadd-xclient gibts bei mir nicht
la /etc/X11/Xsession.d
insgesamt 52
-rw-r--r-- 1 root root 2024 Jan 20 2016 20x11-common_process-args
-rw-r--r-- 1 root root 878 Nov 10 2015 30x11-common_xresources
-rw-r--r-- 1 root root 389 Nov 10 2015 35x11-common_xhost-local
-rw-r--r-- 1 root root 187 Nov 10 2015 40x11-common_xsessionrc
-rw-r--r-- 1 root root 1568 Nov 10 2015 50x11-common_determine-startup
-rw-r--r-- 1 root root 96 Dez 3 2016 70systemd
-rw-r--r-- 1 root root 752 Mär 7 2016 75dbus_dbus-launch
-rw-r--r-- 1 root root 880 Feb 9 2017 90gpg-agent
-rw-r--r-- 1 root root 966 Jun 13 2016 90qt5-opengl
-rw-r--r-- 1 root root 143 Apr 8 2012 90tpb
-rw-r--r-- 1 root root 629 Nov 10 2015 90x11-common_ssh-agent
-rw-r--r-- 1 root root 513 Dez 1 2015 95dbus_update-activation-env
-rw-r--r-- 1 root root 166 Nov 10 2015 99x11-common_startIst die nicht ein Überbleibsel aus der live-session falls siduction als Gast in Vbox läuft und sollte bei Installation auf real iron entfernt werden? Hm...
-
@der_Bud: ja, sieht so aus, es gab eine Zeit vor Calamares, wo wir diese Pakete nicht sauber entfernt haben nach der Installation.
apt-file search 98vboxadd-xclient
virtualbox-guest-x11: /etc/X11/Xsession.d/98vboxadd-xclient
-
Ist bei mir damit auch gelöst.
Die Kaffeepause ist weg, mal sehen ob das unverhoffte Abmelden auch weg ist.
Grüße
Reiner
-
TommiO + der_bud
Thank you, this fixed all 4 of my machines
Danke, das hat alle 4 meiner Maschinen repariert.
-
Hallo,
vielen Dank für die erfolgreiche Recherche!
Das Problem ließ sich auf der Konsole als root durch
rm -f /etc/X11/Xsession.d/98vboxadd-xclient
lösen.
Jetzt booten alle meine Installationen ohne 50-sekündige Denkpause.
Klasse!
-
Das "Abmelde" Problemchen ist noch immer, Dazu mache ich aber nen seperaten Thread auf.
Grüße
Reiner
-
Danke @TommiO und @der_bud! :)
-
@TommiO und @der_bud
vielen Dank für die intensive Recherche.
bevo