systemd ohne Kommandos konfigurieren?

[fanwander]

Ich hab das Problem, dass ich ein (absichtlich) etwas korrumpiertes Arch-Linux-System, das eigentlich auf einem Raspberry Pi 2 laufen soll, nicht über Kommandos konfigurieren kann, sondern nur indem ich die microSD-Karte mit dem Filesystem auf einem anderen Rechner mounte, und da Konfigurationsfiles ändere.

Ich habe es zwar geschaft, das System ins rescue-target booten zu lassen (symlink von /etc/systemd/system/default.target nach /usr/lib/systemd/system/rescue.target), aber aber alle anderen default.targets führen zu einem System ohne Login-Prompt. Ziel wäre eigentlich Multi-User ohne Graphik.

Bei SystemV könnte ich jetzt einfach in der Reihe nach Scripte aus den Runleveln ausführen und damit rauskriegen wo es hakt. Aber eine solche Reihenfolge gibt es ja bei systemd nicht.

Leider finde ich keine Beschreibung des systemd-Systems, die nicht die üblichen Kommandos (systemctl...) verwendet. Ich bräuchte aber eine Beschreibung, an Hand der ich die Start-Reihenfolge nur auf Grund der Konfigfiles verstehe. Gibts sowas?

 

[ssssssssssss14316]

Ich bin mir nicht sicher, ob ich dein Problem richtig verstanden habe, deshalb nur folgender Link, dort ist rudimentär beschrieben, wie das ganze System zusammenspielt, die Keywords, hinter denen sich die Abhängigkeiten der einzelnen Dienste verstecken (Reihenfolgen, Voraussetzungen, Konflikte), sind da beschrieben. Damit müsste man sich auch händisch die systemspezifische Reihenfolge erstellen können.

Aber letztendlich müsstest du sie dann immer noch manuell einzeln nacheinander starten, wenn du auf Fehlersuche bist. Vielleicht mal die Logs konsultieren gleichzeitig? Viel Glück.

Systemd Unit Configuration Files Explained

This tutorial explains Systemd unit configuration files. Learn their configurations, types, and locations in detail.

www.computernetworkingnotes.com

 

[noir]

Wie siehts aus mit chroot auf nem anderen RasPi oder mit Qemu?

 

[roh'signal]

Versuche es mal an den üblichen Orten für solche Fragen...

Systemd dependencies and boot order

I need to specify a boot order for processes to start. I have 389 Directory Server and Samba running on Fedora 18. How can I have the network services boot, then 389 DS, then Samba? Is there a GUI to

serverfault.com

Is there any way to list systemd services in linux "in-the-order-of" they were loaded?

I am trying to understand the dependencies between different systemd services in my new project. We are using yocto build system and systemd/system services. If I perform, systemctl -l It wil...

stackoverflow.com

Services legt man mit eigenen Scripten an... funktioniert bei mir mal mehr oder weniger. In die man zu schauen, schadet auch nicht. Ich kenne Arch- Linux kaum - war mir nicht klar, dass es Images auch für den pi gibt. Ich selbst bin überzeugter Debianer

 

[roh'signal]

Evtl. ist auch hier etwas dabei, was Dir weiterhilft... viel Erfolg bei der Fehlersuche.

DebuggingSystemd - Ubuntu Wiki

Debug Systemd Service Units – Runbooks

Debugging a systemd service unit file, when systemctl status and journalctl just isn’t enough|

containersolutions.github.io

How to debug systemd problems

If you are experiencing a problem with system boot-up due to systemd, please see the commonbugs document before filing a bug. Some easy configuration tweaks that fix a wide range…

docs.fedoraproject.org

 

[tulle]

Die nötigen Pakete nachinstallieren ist keine Option?

 

[fanwander]

@SynthGate @randomhippie e.a. danke für die Seiten, aber das sind natürlich (zu Recht) die, die man beim googlen halt findet.

Vielleicht sollte ich mein Problem nochmals erläutern, das zu dieser seltsamen Fragestellung führt:

Ich habe einen ganzen Haufen "Raspberry Pi 2"-er geschenkt bekommen, und würde die gerne für Critter&Gutari ETC's hernehmen. Die ETC basiert auf Archlinux (allerdings einen andere Hardwareplattform). Es gibt für Raspberry ein Arch-Image, aber das hat kein Pygame für Python 2 drauf (und Python2 muss sein, weil das ganze ETC-System für Python2 geschrieben ist). Alle Versuche das dort zu installieren scheitern an massiven Fehlern beim kompilieren der Dependencies. Mindestens zwei der Fehler sind known issues, unfixed.

Also bin ich auf die Idee gekommen, /usr und /etc von der ETC-Installation auf die Rasp-Installation überzubügeln (mit cpio). Da muss man dann noch die symbolic Links nachziehen (keine Kopier-Funktion der Welt kopiert symbolic links - entweder werden die Links als Files hart kopiert oder die Links werden ignoriert); dafür hab ich mir ein Script geschrieben.

Das Rasp bootet damit tatsächlich und startet auch die ETC-Applikation, aber weder das Netz geht an, noch bekomme ich einen Login-prompt, wenn ich die ETC-Services deaktiviere. Wenn ich im Singleusermode hochfahre hab ich halt einen Login. Und von dort aus würde ich jetzt gerne schritt für Schritt einzelne Services hochfahren.
Dafür brauche ich aber eine Reihenfolge. Und genau das - eine Reihenfolge - kennt systemd eigentlich nicht. Deswegen brauche ich ein tieferes Verständnis. Das ist die Stelle wo meine Ausgangs-Frage ansetzt.



Als gesamt Alternative wäre noch ein Arch-Linux "from the Scratch" zu installieren, aber das geht wohl beim PI-2 noch nicht. Alle Anleitungen ArchLinux auf den Pi 2 zu bekommen benutzen eine fertiges ISO-Image, das auf die SD-Karte gedumpt wird.

Und letzte Möglichkeit wäre ETC ganz zu verlassen und das EYESY zu benutzen. Das schon dediziert für Raspberry Pi 3 gebaut wurde und vermutlich auch mit Python3 arbeitet. Allerdings benutze ich eine von mir massiv angepasste ETC-Version, und die ganzen Anpassungen müsste ich jetzt wirde in EYESY mühsam einbauen...

 

[roh'signal]

@SynthGate @randomhippie e.a. danke für die Seiten, aber das sind natürlich (zu Recht) die, die man beim googlen halt findet.

Vielleicht sollte ich mein Problem nochmals erläutern, das zu dieser seltsamen Fragestellung führt:

Ich habe einen ganzen Haufen "Raspberry Pi 2"-er geschenkt bekommen, und würde die gerne für Critter&Gutari ETC's hernehmen. Die ETC basiert auf Archlinux (allerdings einen andere Hardwareplattform). Es gibt für Raspberry ein Arch-Image, aber das hat kein Pygame für Python 2 drauf (und Python2 muss sein, weil das ganze ETC-System für Python2 geschrieben ist). Alle Versuche das dort zu installieren scheitern an massiven Fehlern beim kompilieren der Dependencies. Mindestens zwei der Fehler sind known issues, unfixed.

Also bin ich auf die Idee gekommen, /usr und /etc von der ETC-Installation auf die Rasp-Installation überzubügeln (mit cpio). Da muss man dann noch die symbolic Links nachziehen (keine Kopier-Funktion der Welt kopiert symbolic links - entweder werden die Links als Files hart kopiert oder die Links werden ignoriert); dafür hab ich mir ein Script geschrieben.

Das Rasp bootet damit tatsächlich und startet auch die ETC-Applikation, aber weder das Netz geht an, noch bekomme ich einen Login-prompt, wenn ich die ETC-Services deaktiviere. Wenn ich im Singleusermode hochfahre hab ich halt einen Login. Und von dort aus würde ich jetzt gerne schritt für Schritt einzelne Services hochfahren.
Dafür brauche ich aber eine Reihenfolge. Und genau das - eine Reihenfolge - kennt systemd eigentlich nicht. Deswegen brauche ich ein tieferes Verständnis. Das ist die Stelle wo meine Ausgangs-Frage ansetzt.



Als gesamt Alternative wäre noch ein Arch-Linux "from the Scratch" zu installieren, aber das geht wohl beim PI-2 noch nicht. Alle Anleitungen ArchLinux auf den Pi 2 zu bekommen benutzen eine fertiges ISO-Image, das auf die SD-Karte gedumpt wird.

Und letzte Möglichkeit wäre ETC ganz zu verlassen und das EYESY zu benutzen. Das schon dediziert für Raspberry Pi 3 gebaut wurde und vermutlich auch mit Python3 arbeitet. Allerdings benutze ich eine von mir massiv angepasste ETC-Version, und die ganzen Anpassungen müsste ich jetzt wirde in EYESY mühsam einbauen...

Okay, jetzt hab ich es verstanden (zumindest bilde ich mir das ein). Eine Bestandsaufnahme im Singleuser Mode über "systemctl list-units --all" der geladenen oder eben nicht geladenen Services hast Du sicherlich schon gemacht, korrekt? Auch wenn die Fehlermeldungen oft kryptisch sind... oft liegt da irgendwo die Lösung versteckt. Wobei Du ja im Prinzip schon weißt, woran es liegt.

 

[ssssssssssss14316]

Dafür brauche ich aber eine Reihenfolge. Und genau das - eine Reihenfolge - kennt systemd eigentlich nicht. Deswegen brauche ich ein tieferes Verständnis. Das ist die Stelle wo meine Ausgangs-Frage ansetzt.

Die Reihenfolge ergibt sich doch bei systemd implizit aus den Einträgen der Keywords "After", "Before", "Wants" und "Requires" innerhalb der einzelnen Konfigurationsdateien für systemd, weswegen ich auch Obiges schrieb. (Oder wir reden immer noch aneinander vorbei).

EDIT: Ich bleibe immer noch dabei, im Prinzip müsste man nur aus den vorhandenen Konfigurationsdateien die Reihenfolge/Dependencies extrahieren. Wo keine ist, ist es auch egal für den entsprechenden Service. Wo eine ist, muss man eben in umgekehrter Reihenfolge vorgehen/die Services starten. Ich bin mir nicht sicher, ob die systemd Tools so etwas nur für ins system integrierte Skripte tun können oder ob es etwas anderes gibt, mit dem man sich eine solche Reihenfolge ausgeben lassen könnte.

Und letzte Möglichkeit wäre ETC ganz zu verlassen und das EYESY zu benutzen. Das schon dediziert für Raspberry Pi 3 gebaut wurde und vermutlich auch mit Python3 arbeitet. Allerdings benutze ich eine von mir massiv angepasste ETC-Version, und die ganzen Anpassungen müsste ich jetzt wirde in EYESY mühsam einbauen...

Ich weiß ehrlich gesagt nicht, was du mit ETC meinst. Für mich war das immer das Konfigurationsverzeichnis auf Unixsystemem. Wenn ich etwas verpasst habe, bitte ich um Aufklärung.

EDIT: Hat durch unteren Post von @noir endlich Verständnis in mein verwinkeltes Hirn gebracht. (Danke!) Man sollte insbesondere beim Lesen immer langsam vorgehen, auch und gerade wegen der Abkürzungen, die das Gehirn da einschlagen kann.

 

[noir]

Ich habe einen ganzen Haufen "Raspberry Pi 2"-er geschenkt bekommen, und würde die gerne für Critter&Gutari ETC's hernehmen. Die ETC basiert auf Archlinux (allerdings einen andere Hardwareplattform). Es gibt für Raspberry ein Arch-Image, aber das hat kein Pygame für Python 2 drauf (und Python2 muss sein, weil das ganze ETC-System für Python2 geschrieben ist). Alle Versuche das dort zu installieren scheitern an massiven Fehlern beim kompilieren der Dependencies. Mindestens zwei der Fehler sind known issues, unfixed.

Also bin ich auf die Idee gekommen, /usr und /etc von der ETC-Installation auf die Rasp-Installation überzubügeln (mit cpio). Da muss man dann noch die symbolic Links nachziehen (keine Kopier-Funktion der Welt kopiert symbolic links - entweder werden die Links als Files hart kopiert oder die Links werden ignoriert); dafür hab ich mir ein Script geschrieben.

Bissl am Thema vorbei aber genau damit man sich wegen den Dependencies nicht mehr das System zerschießt gibt es Container wie Docker.

 

[noir]

ETC

Critter&Gutari ETC's

ETC

www.critterandguitari.com

 

[ssssssssssss14316]

Okay, jetzt hab ich es verstanden (zumindest bilde ich mir das ein). Eine Bestandsaufnahme im Singleuser Mode über "systemctl list-units --all" der geladenen oder eben nicht geladenen Services hast Du sicherlich schon gemacht, korrekt? Auch wenn die Fehlermeldungen oft kryptisch sind... oft liegt da irgendwo die Lösung versteckt. Wobei Du ja im Prinzip schon weißt, woran es liegt.

Ich habe verstanden, dass er systemctl nicht benutzen möchte, warum auch immer. Schriftliche zwischenmenschliche Kommunikation ist manchmal etwas problematisch.

 

[audiot.]

... Du willst Dich mit systemd-analyze beschäftigen:
man systemd-analyze

Ansonsten würde ich ernsthaft darüber nachdenken, die Software nach Python3 zu migrieren (so wie das fast alle Linux-Maintainer in den letzten Jahren getan haben).

Hey - ist schließlich nur eine häßliche Skriptsprache

 

[fanwander]

Um die Sache abzukürzen:
Ich hab jetzt mal einfach mal das EYESY-Image von Critter drauf, und das läuft erstmal auf Anhieb (auch wenn jetzt die Bedienelemente fehlen). Ich werde jetzt meine MIDI-Steuerung, die ich fürs ETC-Paket gebastelt habe, dort implementieren und dann habe ich was ich will. Insofern eigentlicher Anlass durch.

dass er systemctl nicht benutzen möchte

Naja, ich kann (bzw konnte) systemctl nicht benutzen, weil ich im laufenden Betrieb keinen Kommandozeilenzugang hatte. Weder per SSH noch auf der Konsole. Das war der Hintergrund.

Die Reihenfolge ergibt sich doch bei systemd implizit aus den Einträgen der Keywords "After", "Before", "Wants" und "Requires" i

Jein. Es gibt erst mal keine Reihenfolge. Erst mal läuft alles parallel los, was für das jeweilige target gebraucht wird und keine Requirements hat. Nur Services die Requirements haben, starten nicht.


Was mir übrigens nicht ganz klar ist: woher weiß "systemctl" den status eines services? Werden da irgendwelche Links gesetzt, die nur existieren, wenn ein service aktiv ist? Oder hält das der systemd Daemon im RAM?

 

[ssssssssssss14316]

Jein. Es gibt erst mal keine Reihenfolge. Erst mal läuft alles parallel los, was für das jeweilige target gebraucht wird und keine Requirements hat. Nur Services die Requirements haben, starten nicht.

Das habe ich im Prinzip auch geschrieben oder zumindest gemeint mit

Wo keine ist, ist es auch egal für den entsprechenden Service.

Aber egal. War vielleicht nicht gerade chirurgisch präzise ausgedrückt. Das ales parallel losrennt ist ja klar, da war ja überhaupt der Grund für systemd, um die Startzeiten deutlich zu verkürzen.

Was mir übrigens nicht ganz klar ist: woher weiß "systemctl" den status eines services? Werden da irgendwelche Links gesetzt, die nur existieren, wenn ein service aktiv ist? Oder hält das der systemd Daemon im RAM?

Naja, systemd startet die Services ja, also weiss er auch, wie der Zustand eines Services ist. Es gibt ja nicht so viele verschiede "States" (absichtlich wg. der Plural-Diskussion von "Status") ("active (...), inactive), zusammen mit dem Prozessinformationen sollten die leicht festzumachen sein. (Da habe ich aber nicht der Sourcecode konsultiert, sondern eher "intuitiv geraten".) Die Meta-States "Enabled", "Disabled" etc. unterliegen ja eh der Kontrolle des systemd.

Service status	Description
active (running)	Service or daemon is running in the background. For example, sshd or nginx/apache web server and listing for incoming traffic.
active (exited)	Service successfully started from the config file. Typically one time services configuration read before Service was exited. For example, AppArmor or Firewall service.
active (waiting)	Our service is running but waiting for an event such as CPUS/printing event.
inactive	Service is not running.
enabled	Service is enabled at boot time.
disabled	Service is disbled and will not be started at Linux server boot time.
static	Service cannot be enabled on Linux, but mostly started by another systemd unit automatically. In other words, the unit file is not enabled and has no provisions for allowing in the [Install] unit file section.
masked	Service is completely disabled and any start operation on it always fails.
alias	Service name is an alias. It means service is symlink to another unit file.
linked	Made available through one or more symlinks to the unit file (permanently in /etc/systemd/system/ or transiently in /run/systemd/system/), even though the unit file might reside outside of the unit file search path.

(Auszug aus https://www.cyberciti.biz/faq/systemd-systemctl-view-status-of-a-service-on-linux/ )

Vielen Dank übrigens, das ETC kannte ich noch gar nicht.

 

[fanwander]

Naja, systemd startet die Services ja, also weiss er auch, wie der Zustand eines Services ist.

Woher?
Die Services sind letztlich shell script Aufrufe. Ok, die geben Returncodes zurück. Aber was bedeutet ein Returncode. Ein JBoss.Stopp-Script zB besagt bei Return 0 nur, dass der Java-Prozess, der das JMS Kommando für "Stop" an den eigentlichen Prozess absetzen soll, erfolgreich gestartet wurde. Ob das Stop-Kommando selbst erfolgreich war, weiss das Shellscript, und somit der systemd nicht!

 

[roh'signal]

Aber egal. War vielleicht nicht gerade chirurgisch präzise ausgedrückt.

Schriftliche zwischenmenschliche Kommunikation ist manchmal etwas problematisch.

Wo Du recht hast, hast Du recht

 

[ssssssssssss14316]

Woher?

Ganz einfach, weil folgende Aussage

Die Services sind letztlich shell script Aufrufe.

ein wenig falsch ist. Und weil es etwas komplizierter ist, wie so oft.

Es waren bei SystemV Shellskripte. Die Konfigurationsdateien für den systemd sind eher Beschreibungen, auch zu erkennen am fehlenden

"#/bin/sh" oder "#/bin/bash" oder "#/bin/env /bin/sh" ...

In den Einträgen "ExecStart", "ExecStop", "ExecReload" könnten zwar Shellskript-Einträge stehen, müssen aber nicht, wenn nicht notwendig. Wenn ein Shellskript aber irgendeinen Prozess startet mittels exec(), ist es eh egal (siehe unten).

Um irgendetwas zu starten muss der systemd einen fork() ausführen (warum wird gleich klar, falls es nicht eh schon ist). Ist alles glattgelaufen bekommt er die PID vom Kindprozess (der geforkte Prozess). Im Kindprozess wird ganz grob dargestellt einer der exec() calls ausgeführt, um den eigentlichen Prozess zu starten. Aus einer exec-Beschreibung:

[B]execve[/B]() does not return on success, and the text, data, bss, and stack of the calling process are [B]overwritten[/B] by that of the program loaded. The program invoked [B]inherits the calling process’s PID[/B], and any open file descriptors that are not set to close-on-exec.

Damit besteht jetzt eine Verbindung (über die PID vom fork()) zw. systemd und dem eben gestartetem Service. Das war schon die ganze Magie, denn über die PID bekomme ich ja die Infos über den Prozess, wenn ich die Berechtigungen habe. Alles klar?

Das alles ist ohne Gewähr und auch nur aus eigenem Wissen ohne der entsprechenden Sourcecode-Kenntnisse "zusammengereimt", aller Fehler inbegriffen.
Hier noch einige Resourcen dazu (bessere wären willkommen, habe jetzt keinen Zugriff auf meine Linksammlung):

| Tutorialspoint

- Copyright © 2014 by tutorialspoint

www.tutorialspoint.com

| Tutorialspoint

- Copyright © 2014 by tutorialspoint

www.tutorialspoint.com

https://www.youtube.com/watch?v=TJzltwv7jJs

 

[haesslich]

Um die Sache abzukürzen:
Ich hab jetzt mal einfach mal das EYESY-Image von Critter drauf, und das läuft erstmal auf Anhieb (auch wenn jetzt die Bedienelemente fehlen). Ich werde jetzt meine MIDI-Steuerung, die ich fürs ETC-Paket gebastelt habe, dort implementieren und dann habe ich was ich will. Insofern eigentlicher Anlass durch.

Ich bin höchst interessiert an details dazu!

 

[fanwander]

Ich bin höchst interessiert an details dazu!

Guckst Du hier https://www.sequencer.de/synthesize...ritter-guitari-etc.129671/page-4#post-2205097