Re: Trixie - KDE Plasma startet sehr langsam

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.