Liebes Forum, ich benutze einen Raspberry Zero mit einem USB-LAN-Adapter (Reichelt RPIZ MULTI HUB.Raspberry Pi Zero - Netzwerkkonverter + 3 Port USB-Hub, weiß, RT). Nach dem Start ist ein Python-Programm automatisch auszuführen, das das LAN für einen UDP-Server nutzt. Der Aufruf des Python-Programms erfolgt in rc.local. Das Python-Programm wird gestartet, aber die LAN-Verbindung funktioniert nicht. Ich nehme an, daß vor dem Start des Programms nicht alles nötige für das LAN gebootet wurde. Gibt es einen Workaround? Viele Grüße, Alexander P.S. Adapter funktioniert, wenn das Python-Programm nachträglich via Putty gestartet und ausgeführt wird.
Hallo Alexander, evtl. ist der USB LAN Adapter beim Aufruf des Scriptes noch nicht Betriebsbereit. rc.local würde ich nicht mehr verwenden. https://wiki.ubuntuusers.de/Archiv/rc.local/ Zitat: "Die Datei rc.local ist seit dem Jahre 1983 obsolet..." Erstelle wie im Link eine systemd-unit, die Angabe von: [Unit] After = network-online.target könnte das Problem schon lösen. Viele Grüße
Ich baue sowas in ein Skript ein, das per crontab gestartet wird:
1 | # m h dom mon dow user command |
2 | @reboot root /bin/sleep 10 && /home/uxdx/start.sh |
3 | ... |
Hallo Mattias und Stephan, danek an euch beide. Die Strategie könnte auf "Abwarten" hinauslaufen. Zur Not könnte ich im Python-Programm vor dem Anbinden des Sockets eine Wartepause von ein paar Sekunden einlegen, vor allem, wenn der USB-LAN-Adapter tatsächlich noch nicht betriebsbereit ist. rc.local ist schon lange out, aber die "Macht der Gewohnheit"... Viele Grüße, Alexander
Alexander P. schrieb: > danek an euch beide. Die Strategie könnte auf "Abwarten" hinauslaufen. > Zur Not könnte ich im Python-Programm vor dem Anbinden des Sockets eine > Wartepause von ein paar Sekunden einlegen, vor allem, wenn der > USB-LAN-Adapter tatsächlich noch nicht betriebsbereit ist. rc.local ist > schon lange out, aber die "Macht der Gewohnheit"... Wow: #1: Ich mach da so eine $Kacke, klappt aber nicht. #2: $Kacke ist doof, machs doch lieber $Richtig. #3: Also ich mach ja lieber $NochVielGroessereKacke. #1: Cool, dann mach ich auch $NochVielGroessereKacke. Echt jetzt, genau mein Humor.
Mattias S. schrieb: > https://wiki.ubuntuusers.de/Archiv/rc.local/ > > Zitat: "Die Datei rc.local ist seit dem Jahre 1983 obsolet..." Ein klarer Fall von "Totgesagte leben länger" ;) Wenn sogar systemd rc.local offiziell unterstützt, darf man es wohl benutzen. Außerdem läuft auf dem RPi wohl kein Ubuntu. https://manpages.debian.org/bookworm/systemd/rc-local.service.8.en.html Der eigentliche Fehler könnte auch an der unterschiedlichen Umgebung liegen, cronjobs scheitern gerne an $PATH. Oder: auf der Kommandozeile per Putty wird die bash benutzt, im rc.local die dash usw.
Lass' ihn doch seinen Koprolithenburger knabbern. Wäre sein Kommentar was anderes als ein Trollkommentar, hätte er ja schreiben können, wie man "es" seiner Ansicht nach besser machen kann. Mir fiele so als Hinweis ein, daß es doch möglich sein müsste, Abhängigkeiten zu definieren, anhand derer Programme gestartet werden. Solange der relevante Netzwerkdienst nicht gestartet ist, oder das relevante Treibermodul nicht geladen ist, hat es keinen Sinn, das Programm zu zünden. Im primitivsten Fall könnte das Programm selbst untersuchen, ob das Treibermodul geladen ist und das Netzwerkinterface initialisiert ist - letzteres ginge über eine Abfrage der zugewiesenen IP-Adresse und des Linkstatus ... In der Dokumentation der verwendeten Linux-Distribution wird man irgendwo entsprechende Hinweise finden können.
Bauform B. schrieb: > Wenn sogar systemd > rc.local offiziell unterstützt, darf man es wohl benutzen. Nur aus Kompatibilitätsgründen, das steht ausdrücklich auch im Unitfile rc-local.service: "/etc/rc.local Compatibility". > Außerdem läuft auf dem RPi wohl kein Ubuntu. Natürlich gibt es Ubuntu für den RasPi [1], das zuvor Gesagte gilt allerdings auch für Debian und das darauf basierende Raspberry Pi OS, sowie jede andere Distribution, die systemd verwendet. Auf Linux-Systemen, die systemd nicht nutzen, ist /etc/rc.local ebenfalls dämlich, denn auch die haben natürlich ein Init-System mit entsprechenden Möglichkeiten, Daemons in Abhängigkeit von der Verfügbarkeit des Netzwerks zu starten. [1] https://ubuntu.com/download/raspberry-pi
Harald K. schrieb: > Wäre sein Kommentar was anderes als ein Trollkommentar, hätte er ja > schreiben können, wie man "es" seiner Ansicht nach besser machen kann. Noch so eine Intelligenzbestie... Die richtige Lösung hatte #2 Mattias S. (dermatse) bereits geliefert, weswegen ich diese Lösung auch explizit als "$Richtig" bezeichnet hatte. Einen durchschnittlich intelligenten User dieses an überdurchschnittlich intelligenten Usern so überaus reichen Forums hätte diese Transferleistung sicherlich nicht überfordert. > Mir fiele so als Hinweis ein, daß es doch möglich sein müsste, > Abhängigkeiten zu definieren, anhand derer Programme gestartet werden. Nicht zu fassen, Du bist ja ein richtig kluger kleiner Held... und jetzt darfst Du dreimal raten, wozu systemd seine Targets und SysV-Init seine Runlevels verwendet. Wobei... ok, Du darfst natürlich neunmal raten. > Im primitivsten Fall könnte das Programm selbst untersuchen, ob das > Treibermodul geladen ist und das Netzwerkinterface initialisiert ist Wenn das System schon etwas Fertiges mitbringt, das genau für diese Aufgabe gedacht ist, muß man völlig irre sein, um es manuell nachzubasteln. Wegen so "kluger" Köpfen bekommt Linux dann den Ruch des "Gefrickels". Wie gesagt, genau mein Humor.
Ein T. schrieb: > Noch so eine Intelligenzbestie... Die richtige Lösung hatte #2 Mattias > S. (dermatse) bereits geliefert, weswegen ich diese Lösung auch explizit > als "$Richtig" bezeichnet hatte. Einen durchschnittlich intelligenten > User dieses an überdurchschnittlich intelligenten Usern so überaus > reichen Forums hätte diese Transferleistung sicherlich nicht > überfordert. In dem Scheißehaufen, den Du hier anstelle eines Kommentares abgesetzt hast, herumzustochern, mag das sein, was Du als "Dein Niveau" bezeichnest; ich aber mach sowas nicht. Da ich es wegen genau solcher Charakterdarsteller wie Dir vermeide, detaillierte Anleitungen zu Linux zu geben (die dann ja auch nur für eine der verschiedenen Volksfronten von Judäa richtig sein könnte), gebe ich hier nur vage Hinweise, die denkfähige Menschen in die richtige Richtung lenken können. Auffällig in Deinem erneuten Scheißhaufen ist die Häufung des Begriffes "Intelligent" - mir scheint, Du hast da irgendeine Fixierung.
Harald K. schrieb: > In dem Scheißehaufen, den Du hier anstelle eines Kommentares abgesetzt > hast, herumzustochern, mag das sein, was Du als "Dein Niveau" > bezeichnest; ich aber mach sowas nicht. Du schaffst es ja auch so, Dich zu disqualifizieren. > Da ich es wegen genau solcher Charakterdarsteller wie Dir vermeide, > detaillierte Anleitungen zu Linux zu geben Die "Qualität" von Ratschlägen, die Du geben könntest, haben wir ja jetzt in Deinem letzten Beitrag gesehen: "Im primitivsten Fall könnte das Programm selbst untersuchen, ...". Da ist es wahrlich ein riesiges Glück, daß Du auf "detaillierte Anleitungen zu Linux" verzichtest.
Harald K. schrieb: > Lass' ihn doch seinen Koprolithenburger knabbern. > > Wäre sein Kommentar was anderes als ein Trollkommentar, hätte er ja > schreiben können, wie man "es" seiner Ansicht nach besser machen kann. > Mir fiele so als Hinweis ein, daß es doch möglich sein müsste, > Abhängigkeiten zu definieren, anhand derer Programme gestartet werden. Ja, und genau das macht systemd. Deshalb hat Matthias S. das bereits in der ersten Antwort vorgeschlagen, wurde aber ignoriert. Einfach so lange zu warten, bis das Netzwerk wahrscheinlich läuft, ist halt Murks.
Rolf M. schrieb: > Ja, und genau das macht systemd. Danke für die sachliche Antwort. Genau sowas meinte ich. Da systemd nicht von allen Linux-Distributionen verwendet wird (https://de.wikipedia.org/wiki/Systemd#Kritik), müsste der Threadstarter natürlich prüfen, ob seine ungenannte Distribution das auch tut.
Zunächst ein Dankeschön an alle, die einen konstruktiven Beitrag veröffentlicht haben. Ich werde systemd ausprobieren oder eine Abfrageloop im Python-Programm. Für letzteres spricht, daß keine Änderung oder Ergänzung am Betriebssystem vorgenommen werden muß. Das Betriebssystem ist Raspberry Pi OS Lite (32Bit), Debian Bookworm, November 2024, beschafft mit PI Imager. Unabhängig davon denke ich, daß man unangemessene Schmähungen unterlassen sollte und auch verstehen könnte, daß nicht jedermanns Hauptgeschäft in der Beschäftigung mit Betriebssystemen besteht. Viele Grüße, Alexander
Alexander P. schrieb: > Zunächst ein Dankeschön an alle, die einen konstruktiven Beitrag > veröffentlicht haben. Ich werde systemd ausprobieren Guckstu hier [1]. Einziger Kritikpunkt: der Kollege will das Unitfile in
1 | /lib/systemd/system/ |
ablegen, besser ist aber
1 | /etc/systemd/system/ |
. Die Vorzüge des Unitfile an dieser Stelle sind: - Dein Skript kann zur Laufzeit des Systems mit den üblichen Befehlen von systemctl wie "enable", "disable", "start", "stop" verwaltet, mit "status" können der aktuelle Status und die neuesten Logs abgefragt werden. - Das Skript kann einfach auf stdout und / oder stderr loggen, und die Logeinträge landen automatisch in den systemweiten Logs mit journald, die Du mit "journalctl" abfragen kannst. - Durch weitere Einstellungen kann die Laufzeitumgebung Deines Skripts wie das Arbeitsverzeichnis, die Umgebungsvariablen etc. präzise eingestellt werden, es können auch definierte Bedingungen festgelegt sowie Namespace(s) und Control Groups festgelegt werden, Eigentümer und Gruppe, Prozeßpriorität, ... - systemd kann Deinen laufenden Prozeß überwachen und ihn zum Beispiel neu starten, wenn er mal abstürzen sollte. Einfach mal in die Manpages von systemd.unit(5) und systemd.service(5) schauen und staunen, was damit alles möglich ist. Einziger Wermutstropfen ist leider der Umgang mit Python Virtual Environments (venv / virtualenv), das benötigt einen (allerdings kleinen) Umweg. Aber wenn ich das richtig sehe, verwendest Du ohnehin kein Venv, oder? Empfehle ich für künftige Projekte wärmstens! [1] https://gist.github.com/emxsys/a507f3cad928e66f6410e7ac28e2990f > oder eine Abfrageloop im Python-Programm. Es ist gerade für einen Einsteiger schwierig, das zuverlässig hinzubekommen. Netzwerkinterface, IP-Adresse, Linkstatus... und Dein Skript würde dadurch abhängig von seiner Laufzeitumgebung, das heißt: wenn Du es morgen auf einem anderen Rechner, einer VM oder in einem Container nutzen willst, mußt Du es umschreiben oder konfigurierbar machen. > Für letzteres spricht, daß keine > Änderung oder Ergänzung am Betriebssystem vorgenommen werden muß. Das Verzeichnis /etc enthält die systemweiten Konfigurationsdat(ei)en und ist also dazu gedacht, Änderungen daran vorzunehmen. Genau dorthin, nämlich in
1 | /etc/systemd/system/ |
gehört auch das systemd-Unitfile für Deinen Service. (Ich muß hoffentlich nicht extra erwähnen, daß das gesamte Verzeichnis /etc natürlich auch ins Backup gehört, oder?) Also genau EINE "Änderung" am Betriebssystem in dem genau dafür vorgesehenen Bereich. > Unabhängig davon denke ich, daß man unangemessene Schmähungen > unterlassen sollte und auch verstehen könnte, daß nicht jedermanns > Hauptgeschäft in der Beschäftigung mit Betriebssystemen besteht. Das oben verlinkte Gist ist das erste Textergebnis für eine Suche nach "python service starten raspi", also offenbar nicht allzu schwer zu finden. Und meine "Schmähung" richtete sich nur gegen die Vorgehensweise, wie in "das kann man schon so machen, aber dann isses halt Kacke".
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.