Solus und der schnelle Sperrbildschirm

Es ist wohl ein häufiges Gebrechen von Linux-Desktops, das ich gerade in meinem Budgie-Desktop sehe: Wenn ich den Rechner in den Schlafzustand schicke, soll nach dem Aufwachen ein Sperrbildschirm erscheinen, so dass ich mein Passwort neu eingeben muss. Das funktioniert auch. Allerdings sehe ich nach dem Aufwachen, bevor der Sperrbildschirm erscheint, für ein paar Sekunden den eigentlichen Bildschirminhalt. Das soll nicht sein.

Die Schwierigkeit, dieses Problem zu reparieren, besteht wie fast immer lediglich darin, die Ursache für das problematische Verhalten zu finden. Fehlermeldungen sehe ich auf meinem Rechner nicht. Eine Internet-Recherche ergibt T619 im Solus-Issue-Tracker, der mich schnell auf die richtige Spur und ins ArchWiki bringt: Es gibt da wohl ein Kommunikationsproblem zwischen den verschiedenen beteiligten Software-Komponenten.

Im Detail passieren folgende Dinge:

• Wenn ich den Rechner schlafen lege, wird vor Erreichen des Schlafzustandes der Sperrbildschirm aktiviert. Wo genau das passiert, habe ich nicht herausbekommen.
• Das Programm, das für die Anzeige des Sperrbildschirms verantwortlich ist (gnome-screensaver¹), kehrt nach seiner Ausführung relativ schnell zurück, obwohl der Sperrbildschirm noch gar nicht angezeigt wird².
• Dadurch erreicht der Rechner den Schlafzustand, während im Hintergrund noch daran gearbeitet wird³, den Sperrbildschirm anzuzeigen.
• Nach dem Aufwachen wird weiter daran gearbeitet, den Sperrbildschirm anzuzeigen, das dauert bei mir etwa 2 Sekunden. So lange sehe ich noch den eigentlichen Bildschirminhalt.

Im ArchWiki wird dieses Phänomen beschrieben:

As screen lockers may return before the screen is “locked”, the screen may flash on resuming from suspend.

gnome-screensaver sagt also, dass es fertig sei, und der Rechner geht schlafen, eigentlich ist gnome-screensaver aber noch gar nicht fertig. Glaube ich zunächst. Allerdings zeigt der Quelltext von gnome-screensaver, dass hier eine D-Bus-Kommunikation zwischen Prozessen stattfindet und gnome-screensaver nicht mehr tut, als eine Nachricht zu verschicken⁴. Damit ist es natürlich praktisch sofort fertig und ist es nicht falsch, wenn gnome-screensaver nach dem Versand der Nachricht sofort zurückkehrt.

So einfach reparieren lässt sich das somit eher nicht, aber ein Workaround ist schnell gefunden. Das ArchWiki sagt nämlich:

Adding a small delay via ExecStartPost=/usr/bin/sleep 1 helps prevent this.

Der Schlafzustand muss also etwas hinausgezögert werden, damit der Sperrbildschirm unmittelbar nach dem Aufwachen des Rechners bereits angezeigt wird. sleep 1 hat bei mir nicht gereicht, aber sleep 3 dann schon. Ich lege, wie bei T619 beschrieben, die Datei /etc/systemd/system/suspend@.service mit folgendem Inhalt an:

[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=simple
Environment=DISPLAY=:0
ExecStart=/usr/bin/gnome-screensaver-command -l
ExecStartPost=/bin/sleep 3

[Install]
WantedBy=sleep.target

Anschließend aktiviere ich diesen Dienst mit sudo systemctl enable suspend@MEINBENUTZERNAME. Fertig.