StefanP schrieb:
Verständnisfrage:
1)"/lib/systemd/system-sleep/"example-SteOnWakeup.sh" steht im Systemd-Bereich ist aber ein Script (*.sh) - spricht man da auch von einer "Unit" - bzw. wenn du von "UserUnit" schreibst meinst du dann die "*.service"-Struktur?
2) in Unit steht unter "systemweite Units": dass nur die System-Units unter a)"/lib/systemd/system" stehen sollten, die vom Nutzer angelegten sollen unter b)"/etc/systemd/system" abgelegt werden. NUR: das Verzeichnis "system-sleep" gibt es nur unter a) nicht aber unter b). Soll/kann ich dort ein Verzeichnis "system-sleep" anlegen und hat es die selbe Bedeutung wie unter a)?
In /lib liegen die mitgelieferten Units, die im Paket systemd enthalten sind. Diese werden auch bei Updates/Upgrades überschrieben und gegen neuere Versionen ausgetauscht. Wenn man nun systemweite Änderungen vornehmen möchte/muss, so legt man diese nach /etc (DAS Konfigurationsverzeichnis). systemd prüft nach einer Reihenfolge das Vorhandensein von Units. Wenn in /etc keine ist, wird automatisch die /lib-Version genommen.
Du kannst Verzeichnisse manuell anlegen, ich bevorzuge aber den Weg neue Units mit systemctl edit --force UNIT anzulegen, da sich dann systemd um die richtige Platzierung kümmert. Ich habe das nicht ausprobiert, aber ich meine es ist egal, ob du ein Unterverzeichnis nutzt oder nicht. Wichtig sind die symbolischen Links auf die Ordner wie xx.target.wants, etc, denn so weiß systemd, welche Unit aktiv ist.
OK - SO hatte ich das mit dem "display.target" auch gemeint ... und deine Antwort verstehe ich so, dass es kein "*.target" gibt, mit dem ich das Vorhandensein der graphischen Oberfläche prüfen/abwarten kann.
Geben vielleicht schon, aber es ist nicht gewährleistet. Das "drüberbügeln" mittels export VARIABLE funktioniert auch nicht unbedingt. Wenn es kein DISPLAY :0 im richtigen Moment gibt, scheitert das Script.
- Grundfrage: ist die TastaurCodeZuordnung vom Vorhandensein der graphischen Oberfläche abhängig?
Ja. Und nein. Es gibt eine "Basiskonfiguration" UND eine oprionale für die grafische Oberfläche. Im Falle von X11 kannst du diese bspw. mit setxkbmap en auf englisch standard setzen. Das liegt daran, dass du für die Verwendung des Systems keine GUI brauchst. Die wird wie ein normales Programm gestartet und übernimmt dann gewisse Teile des Systems. Das ganze Code-Gedöns ist aber auch recht umfangreich und betrifft dich in dem Fall nicht. Bei dir geht es ja eher darum, dass die grafische Oberfläche diese "KeyCodeUmleitung" haben muss.
Vereinfacht gesagt: Eine Tastatur sendet nur Signale (dargestellt als Zahlen). Diese werden empfangen und über eine Zuordnungskarte den entsprechenden Befehlen zugeordnet. Also wenn du "w" drückst, interpretiert der Kernel das Signal und führt die hinterlegte Aktion aus (was in den meisten Fällen die Anzeige als Buchstabe ist). Der Ansatz über die "evdev"-Datei überschreibt die Events grundlegend (aber auch nur für den grafischen Teil über X11). Der hat nichts mit aufwachen, einschlafen oder dergleichen zu tun, sondern ändert grundlegend die Verarbeitung der Signale. Da mir gerade entfallen ist, was nach dem Aufwachen nicht mehr funktionierte, kann ich es leider nicht auf dein Beispiel beziehen. Aber hier findest du eine Anwendungsmöglichkeit: xev
Falls es für alle Nutzer gültig oder aktivierbar sein soll, wird es ein wenig mehr Arbeit und du müsstest dir einen "@.service" einrichten, der den Nutzernamen als Argument erhält.
SO - HIER verstehe ich nur Bahnhof ... also auch SUCHEN ☺
Mal als ganz plumpes Beispiel. Du legst eine Unit an, die Hallo sagen soll. die würde dann auf Basis von user@.service etwa so aussehen:
#speichern als hallo@.service
[Unit]
Description=Benutzerspezifischer Gruß
After=systemd-user-sessions.service user-runtime-dir@%i.service dbus.service
Requires=user-runtime-dir@%i.service
[Service]
ExecStart=/usr/bin/logger Hallo %i
(Keine Ahnung ob das funktioniert, geht nur um die Idee)
Aktivieren kannst du die nun für jeden Nutzer einzeln. systemctl enable --now hallo@stefan.service würde dann bei jedem Ausführen ein "Hallo Stefan" ins Log schreiben. Es gäbe noch die [Install]-Sektion, da könntest du die Automatik an etwas binden, wie bspw. Alias=multi-user.target.wants/hallo@%i.service. Das macht WLAN/wpa supplicant so.
Ist aber für den Moment wirklich uninteressant für dich.
