(LINUX) systemctl

Allgemeines

Eigentlich koennte ich diese Seite in eine neue Kategorie 'weird things' packen.

Um systemctl und damit systemd besser einordnen zu koennen, dient vielleicht folgender Artikel.

Motivation

Ich habe 08/2021 meinen Server auf eine neue alte Hardware umgezogen. Da die Server-Hardware (XW8400 auf XW8600; ja ich geb es zu, alt ist gar kein Ausdruck, aber 8 Kerne und 16 GB RAM sind fuer meinen Server ausreichend; vorerst;-)) sich unwesentlich geaendert hat, war es fast damit getan die Festplatten umzustecken. Die wesentlichen Anpassungen bezogen sich auf BIOS und Netzwerk. Nur die grafische Oberflaeche wollte partout nicht starten, daher der Titel.

BIOS

TODO

Netzwerk

Da die Zuordnung der Netzdevices ueber die MAC-Adresse geschieht, waren die erwartungsgemaesz falsch. Ich hatte nach dem Start eth3, eth4 und eth5 anstatt eth0-2. BTW: Die dritte Karte ist eine LWL-Karte zur direkten Anbindung an das Backbone. Die Zuordnungsdatei ist bei OpenSuse 15.3 unter

1. /etc/udev/rules.d/70-persistent-net.rules

zu finden. Dort habe ich die alten Eintraege geloescht/auskommentiert(#) und die neuen Zuordnungen eingetragen. Die Uebernahme war nach einem Reboot richtig. Vielleicht waere es auch ohne Reboot gegangen, evtl. mit udevadm trigger

Bei der Gelegenheit bin ich noch ueber eine Beschriftung der unteren der beiden RJ45-Netzwerkbuchsen mit ASF gestolpert. ASF steht fuer Alert Standard Format der DMTF nicht zu verwechseln mit DTMF;-)

Grafische Oberflaeche

Es sei erwaehnt, dass ein startx mit einem User zum Erfolg fuehrt, aber das ist ja keine Dauerloseung. Es handelt sich also nicht um die mit jedem Update/Upgrade auftauchenden NVIDA-Treiber Probleme.

Erst einmal das default target kontrolliert.

server:~ # systemctl get-default
graphical.target

Das stimmt soweit. Wenn ein target "sein Ziel" nicht erreicht liegt es oft an fehlerhaften Services.

systemctl list-dependencies graphical.target

In der Ausgabe (Liste von Abhaengigkeiten) sind Dienste, etc. mit einer "farbigen" Markierung versehen.

• gruen in Ordnung
• rot Fehler
• schwarz/grau nicht aktiv(iert)

Ich habe alle "roten Dienste" disabled. z.B.

systemctl disable dhcpd

Aber obwohl danach alle Abhaengigkeiten gruen oder schwarz waren, hat es nicht den gewuenschten Erfolg gebracht.

Dann mal weitersuchen. Wo hat systemd seine configs versteckt?

server:~ # pkg-config systemd --variable=systemdsystemconfdir
/etc/systemd/system

In der Regel in /usr/local/lib/systemd/system und /usr/lib/systemd/system

Full list of directories is provided in systemd.unit(5).

In dem Verzeichnis /etc/systemd/system gibt es ein Verzeichnis graphical.target.wants in dem sich eine Service-Datei befindet.

server:/etc/systemd/system # ll graphical.target.wants/
insgesamt 0
lrwxrwxrwx 1 root root 47 28. Apr 2019  display-manager.service -> /usr/lib/systemd/system/display-manager.service

Daraufhin mal den Status gescheckt.

systemctl status display-manager.service

Und weird#unknown display-manager active and running. Mit Alt-F7 sieht man tatsaechlich einen Cursor blinken.

The Simple Desktop Display Manager (SDDM) a display manager. It is the recommended display manager for the KDE Plasma and LXQt desktop environments. 

Next weird#

server:/etc/systemd/system # psgrep sddm
1747 ?        Sl     0:00 /usr/bin/sddm

server:/etc/systemd/system # systemctl status sddm
● sddm.service - Simple Desktop Display Manager
    Loaded: loaded (/usr/lib/systemd/system/sddm.service; disabled; vendor preset: disabled)
    Active: inactive (dead)
      Docs: man:sddm(1)
            man:sddm.conf(5)

Grrrrrrrrr!

Zurueck auf Anfang. Bei ersten Booten (mit fehlerhaften Diensten) ist das System im Emegency-Mode gelandet.

Emergency and rescue targets
Both of these shells require the root password. The emergency target keeps the root file system mounted read-only, while rescue. target waits for sysinit. target to complete first so that more of the system will be initialized, for example, logging, file systems, etc.

server:/etc/systemd/system # systemctl --failed
 UNIT LOAD ACTIVE SUB DESCRIPTION
 0 loaded units listed.

Bei OpenSuse gibt es keine Xwrapper.config -> weird#++

lircd

2026-05-14 Heute wollte ich mal meinen lircd-Start automatisieren. Da ich noch so eine alte Homebrew Loesung am Start habe, muss ich zum Aktivieren folgende Schritte ausfuehren.

systemctl stop lircd
setserial /dev/ttyS0 uart none
modprobe serial_ir
systemctl start lircd
irexec /etc/lirc/irexec.lircrc

Der letzte Befehl dient mir als eine Art IR-Proxy. Die Befehle der IR-Fernbedienung werden entgegengenommen und per IP oder IR weitergegegeben.

Um es gleich vorweg zu nehmen, ChatGPT hat (fast) auf ganzer Linie versagt.

Der erste Vorschlag von ChatGPT die Befehle in eine Script zu packen, empfand ich zwar nicht so prickelnd, waere aber in der Nachbetrachtung der einfachere Weg gewesen.

Datei erstellen:

sudo nano /usr/local/bin/lirc-init.sh

Inhalt:

#!/bin/bash

# UART deaktivieren
setserial /dev/ttyS0 uart none

# IR-Treiber laden
modprobe serial_ir

# kurzen Moment warten
sleep 1

# lircd starten
systemctl start lircd.service

# irexec starten
irexec /etc/lirc/irexec.lircrc &

Ausführbar machen:

sudo chmod +x /usr/local/bin/lirc-init.sh

Auch einen eigenen systemd Service zu erstellen waere denkbar gewesen.

Datei:

sudo nano /etc/systemd/system/lirc-init.service

Inhalt:

[Unit]
Description=LIRC Initialisierung
Before=lircd.service
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/lirc-init.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Am elegantesten fand die ich den folgenden Loesungsvorschlag. Um es vorweg zu nehmen, so hat es nicht funktioniert.

1. Override-Datei erzeugen
sudo systemctl edit lircd.service

Dadurch öffnet sich ein Editor.

2. Folgenden Inhalt einfügen
[Service]
ExecStartPre=/usr/bin/setserial /dev/ttyS0 uart none
ExecStartPre=/usr/sbin/modprobe serial_ir
ExecStartPost=/usr/bin/irexec /etc/lirc/irexec.lircrc
3. systemd neu laden
sudo systemctl daemon-reload
4. Dienst neu starten
sudo systemctl restart lircd.service
5. Prüfen

Status anzeigen:

systemctl status lircd.service

Logs ansehen:

journalctl -u lircd.service

Auch ExecStartPost zu ersetzen war irgendwie nicht mein Ding.

ExecStartPost=/usr/bin/bash -c '/usr/bin/irexec /etc/lirc/irexec.lircrc &'

Bei der ganzen Aktion habe ich doch tatsaechlich eine neue Befehlsvarianten kennengelernt.

sudo systemctl edit lircd.service

Ich habe das irexec in einen eigenen service gepackt.

[Unit]
Description=LIRC irexec
After=lircd.service
Wants=lircd.service

[Service]
ExecStart=/usr/bin/irexec /etc/lirc/irexec.lircrc
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Danach..

sudo systemctl daemon-reload
sudo systemctl restart lircd.service
sudo systemctl restart irexec.service

Und dann eine Fehlermeldung, die mich locker eine Stunde gekostet hatte. ChatGPT war keine grosze Hilfe, hat aber an einer Stelle etwas ausgespuckt, was mich auf die richtige Faehrte gefuehrt hat.

modprobe: FATAL: Module serial_ir not found in directory /lib/modules/6.4.0-150600.23.84-default

Modprobe aus der Kommandozeile funktionierte, aber als ExecStartPre-Parameter nicht. Die Fehlermeldung ist irrefuehrend und hat auch ChatGPT den Fehler staendig bei falschen Pfaden, Dateinamen, Kernelversionen, ... suchen lassen.

Der Fehler lag in der eingeschraenkten Berechtigung (!!!) durch den Parameter ProtectKernelModules.

Sobald ich den Parameter auf no gestellt hatte, tat auch modprobe seinen Dienst.

ProtectKernelModules=no #!!!!!!!

Warum ChatGPT nicht gleich den Hinweis "Schaue nach dem Parameter ProtectKernelModules!" oder warum modprobe nicht den Fehler "Permission denied!" ausgibt, bleibt fuer mich unbeantwortet.