Re: Trixie - KDE Plasma startet sehr langsam

Am 30.09.25 um 20:26 schrieb Siegfrid Brandstätter:
> Am 30.09.25 um 18:47 schrieb Rolf Reintjes:
>>
>> Hallo,
>>
>> Am 30.09.2025 um 19:37 schrieb Siegfrid Brandstätter:
>>> # systemd-analyze blame
>>> 36.928s e2scrub_reap.service
>>> 21.673s snapd.seeded.service
>>> 21.385s snapd.service
>>> 16.589s blueman-mechanism.service
>>> 13.089s me.proton.vpn.split_tunneling.service
>>> 10.897s 
>>> systemd-fsck@dev-disk-by\x2duuid-75baaea6\x2d5a54\x2d4ad9\x2da1cc\x2d240df6356f28.service
>>> 9.091s udisks2.service
>>> 7.942s wtmpdb-update-boot.service
>>> 6.788s systemd-journal-flush.service
>>> 6.706s accounts-daemon.service
>>> 6.640s polkit.service
>>> 5.918s avahi-daemon.service
>>> 5.910s dbus.service
>>> 5.843s NetworkManager.service
>>> 5.810s switcheroo-control.service
>>> 4.677s ModemManager.service
>>> 4.133s smartmontools.service
>>> 4.125s snap-snapd-25202.mount
>>> 4.059s NetworkManager-wait-online.service
>>> 3.678s fwupd.service
>>> 3.546s snap-signal\x2ddesktop-827.mount
>>> 3.531s snap-signal\x2ddesktop-829.mount
>>> 3.395s snap-gnome\x2d46\x2d2404-125.mount
>>> 3.395s snap-core22-2133.mount
>>> 3.202s systemd-suspend.service
>>> 3.174s snap-mesa\x2d2404-912.mount
>>> 2.940s dev-sda3.device
>>> 2.905s snap-gnome\x2d42\x2d2204-226.mount
>>> 2.894s snap-gtk\x2dcommon\x2dthemes-1535.mount
>>> 2.874s snap-core24-1151.mount
>>> 2.856s wpa_supplicant.service
>>
>> Ich habe dazu mal ChatGPT gefragt und bekam folgende Antwort:
>>
>> Sehr gute Frage – der |systemd-analyze blame|-Output listet *alle 
>> Units nach ihrer Startdauer*. Aber nicht alles davon wirkt sich 
>> direkt auf das *Starten von KDE Plasma* aus.
>>
>> 👉 Wichtige Punkte:
>>
>>  *
>>
>>     *Nicht Plasma-relevant, aber sehr langsam*:
>>
>>      o
>>
>>         |e2scrub_reap.service| (36s): Das ist ein Hintergrunddienst
>>         für ext4-Dateisystemprüfung (e2scrub), nicht nötig für
>>         Plasma. Kann parallel laufen, verzögert den Desktop aber
>>         nicht direkt.
>>
>>      o
>>
>>         |snapd.service| / |snapd.seeded.service| (21s+21s): Snap
>>         initialisiert sich beim Boot, das frisst Zeit und blockiert
>>         teils IO. Hat nichts mit Plasma selbst zu tun, kann aber die
>>         *Systemreaktionszeit* beim Start belasten.
>>
>>      o
>>
>>         |systemd-fsck@...| (10s): Dateisystemprüfung, kann das Booten
>>         blockieren, bis abgeschlossen.
>>
>>  *
>>
>>     *Kann Plasma indirekt betreffen* (weil sie
>>     D-Bus/Netzwerk/PolicyKit bereitstellen):
>>
>>      o
>>
>>         |dbus.service|, |polkit.service|, |accounts-daemon.service|,
>>         |udisks2.service|, |NetworkManager.service|,
>>         |wpa_supplicant.service|.
>>         → Wenn diese Dienste zu lange brauchen, startet Plasma zwar,
>>         aber viele Komponenten (Netzwerk-Manager-Applet, Mounten von
>>         Laufwerken, VPN, Authentifizierung) hängen fest.
>>
>>      o
>>
>>         |blueman-mechanism.service| (16s): Bluetooth-Daemon, kann den
>>         Session-Start blockieren, wenn Plasma auf Bluetooth-Status
>>         wartet.
>>
>>      o
>>
>>         |me.proton.vpn.split_tunneling.service| (13s): VPN-Hook, kann
>>         Netzwerkinitialisierung verzögern → wirkt auf
>>         Plasma-NetworkManager.
>>
>>      o
>>
>>         |NetworkManager-wait-online.service| (4s): Klassischer
>>         Bremser, sorgt dafür, dass gewartet wird, bis Netzwerk
>>         *wirklich online* ist (oft unnötig).
>>
>>  *
>>
>>     *Reine Plasma-Startzeit* hängt also hauptsächlich von *D-Bus,
>>     Polkit, AccountsDaemon, UDisks, NetworkManager, evtl. Bluetooth* ab.
>>
>> 🔑 *Fazit für dich:*
>> Für den langsamen Plasma-Start sind am ehesten verantwortlich:
>>
>> 1.
>>
>>     |NetworkManager-wait-online.service| (kann man oft deaktivieren)
>>
>> 2.
>>
>>     |blueman-mechanism.service| (16s → verzögert Session)
>>
>> 3.
>>
>>     |me.proton.vpn.split_tunneling.service| (VPN hängt im Startup)
>>
>> 4.
>>
>>     |snapd.service| & Mounts (viel IO, indirekt störend)
>>
>> Der dicke Brocken |e2scrub_reap.service| ist zwar am langsamsten, 
>> läuft aber asynchron – bremst Plasma also *nicht direkt*, sondern nur 
>> den gesamten Bootvorgang.
>>
> Vielen Dank, auch an Jürgen!
>
> Snapd hab ich entfernt weiters
>
> systemctl stop NetworkManager.service
>
> |e2scrub_reap.service würde ich gerne deaktivieren falls das geht wenn 
> es für Ext4 eh nicht notwendig wäre. Aber wie macht man das?|
>
> |Werde jetzt mal einen reboot machen und schauen was passiert.|
>
Na ja, bisher kein Erfolg damit.  Network manager werkelt trotz 
deaktivieren wieder.

# systemd-analyze time
Startup finished in 3.438s (kernel) + 40.927s (userspace) = 44.365s
graphical.target reached after 40.927s in userspace.
root@debian:~# systemd-analyze blame
31.199s e2scrub_reap.service
11.795s blueman-mechanism.service
9.356s me.proton.vpn.split_tunneling.service
8.523s NetworkManager-wait-online.service
8.082s udisks2.service
6.620s accounts-daemon.service
6.491s polkit.service
6.474s wtmpdb-update-boot.service
5.918s avahi-daemon.service
5.911s dbus.service
5.792s switcheroo-control.service
5.318s packagekit.service
3.655s systemd-journal-flush.service
3.183s NetworkManager.service
2.916s Musik.mount
2.865s dev-sdb3.device
2.472s smartmontools.service
2.251s ModemManager.service
1.678s cups.service
1.423s dev-nvme0n1p2.device
1.259s plymouth-start.service
1.162s wpa_supplicant.service
  797ms lm-sensors.service



-- 
Beste Grüße
Sigi