RunLevel-Script startet bei Stop, aber nicht bei Start

  • Moin @ all

    Ich habe ein Beispielscript hier aus dem Forum für meine Bedürfnisse und für meinen RPi mit Raspian Wheezy ein wenig abgewandelt und es entsprechend dem Beispiel auch in die Runlevels eingetragen. Merkwürdig ist, dass es nur bei "Stop" aufgerufen wird. Ich habe direkt oben im Script mal eine Debug-Zeile echo "Started: "$1 >>~/vl_boot.log... tja, bei "Start" wirds nicht aufgerufen. Manuell mit Cmd-Line-Param "Start" macht es alles, was es soll, nur leider nicht über die Runlevels. Ich habe die entsprechenden Runlevels kontrolliert: Das Script ist überall korrekt platziert.

    Hat jemand vielleicht eine Idee oder einen Rat, wie ich zur weiteren Fehlersuche vorgehen könnte?

    Danke im Voraus.

    vg, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (4. März 2015 um 12:38)

  • RunLevel-Script startet bei Stop, aber nicht bei Start? Schau mal ob du hier fündig wirst!


  • Das Script ist überall korrekt platziert.

    Hast Du auch die Festlegungen aus der:

    Code
    /etc/init.d/README


    -Datei beachtet?

    EDIT:

    Siehe auch den vorletzten Beitrag und den letzten Beitrag (Stand: 04.03.2015, 18:48 Uhr) in diesem Thread: Init-Script bie Runlevel 0? Wer kann beim schreiben helfen?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (4. März 2015 um 18:48)

  • Hallo


    Hast Du auch die Festlegungen aus der:

    Code
    /etc/init.d/README

    -Datei beachtet?
    Siehe auch den vorletzten Beitrag und den letzten Beitrag (Stand: 04.03.2015, 18:48 Uhr) in diesem Thread: Init-Script bie Runlevel 0? Wer kann beim schreiben helfen?

    Ja, ich denke mal, dass ist alles ok. Ich habe ja nix neues gemacht, sondern von hier ein fertiges Script genommen, und zwar "varlog", welches /var/log nach tempfs mountet. In dem Thread steht ja alles beschrieben, was zu tun ist. Ich habe am Script-Header natürlich nichts verändert und dass das Script mit update.rc korrekt in den Runlevels eingetragen ist, leite ich daraus ab, weil es ja bei "stop" korrekt ausgeführt wird. Das ist ja genau der Effekt, den ich nicht verstehe... weils bei "start" eben nicht gestartet wird.

    Merkwürdig ist, dass mein altes Varlog-Script (was ich auch schon verändert habe) ja ordentlich gestartet und gestoppt wurde. Nur jetzt tut diese Variane genau das eben nicht.

    Ich habe das Script für folgende Anforderungen verändert:
    1. /var/log soll analog eines normalen PC vollständig nur auf Platte erfolgen
    2. Das gleiche Script muss auf 3 RPis mit der gleichen Zielplatte laufen
    3. Unterschieden werden die Ziel-Logs durch je eine lokale /etc/varlog.conf mit folgendem Ergebnis
    - Raspi 1 Log-files nach /media/HD_1/Log/var.log.RasPi_Srv
    - Raspi 2 Log-files nach /media/HD_1/Log/var.log.RasPi_2
    - Raspi 3 Log-files nach /media/HD_1/Log/var.log.RasPi_3

    Von Hand gestartet funktionierts.... über die Runlevels leider nicht. Das ist das Script:

    Einmal editiert, zuletzt von WinterUnit16246 (15. März 2015 um 18:43)

  • Hallo @ all

    Hat den wirklich keiner eine Idee, wo und wie ich mit einer Ursachen-Suche anfangen kann? Kann das vielleicht auch im Zusammenhang mit dem aktuellen Februar-Image stehen? Beispielsweise habe ich (ebenfalls in der Bootphase) auf 2 RPi's mit diesem Image das Problem, dass nicht via fstab gemountet wird. Beide PI's brauchen ein "mount -a" in der rc.local damit die Mounts durchgeführt werden. Sind da vielleicht allgemeine Probleme bekannt .... ?.... so dass mein Problem gar nicht lokal gelöst werden kann? Das muss doch ne Ursache haben.... :s

    Gruss, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (5. März 2015 um 18:09)

  • Moin

    Das gleiche Script läuft auf einem Raspi B+ mit "älterem" Image fehlerlos. Auf einem zweiten Raspi B+ und dem Raspi 2 Mod. B, beide mit dem "neueren" Image existiert jedoch dieser Fehler in der Bootphase. Beide Pi's mounten ausserdem auch nicht über die fstab, sondern benötigen einen zusätzlichen Anschub über rc.local.

    Ich finde das jetzt sehr irritierend, dass niemand hier dazu eine Meinung hat.... und das ich möglicherweise als einziger dieses Problem habe. Ein Pi mit dem Problem wäre ja noch verständlich, aber 2 unterschiedliche PI mit identischem Problem ist doch sehr merkwürdig. Ich habe doch hoffentlich nicht ein Tabu-Thema angesprochen.... :s

    An dem Punkt beschäftigt mich gerade noch eine andere Frage: Wird das "ältere" (Image) Raspian des einen funktionierenden Pi mit den upgrades automatisch zu dem Stand portiert, den das aktuelle Image für das Modell 2 ausmacht? Oder bleiben da dauerhaft Unterschiede bestehen?

    vg, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (6. März 2015 um 16:08)


  • Beide Pi's mounten ausserdem auch nicht über die fstab, ...

    Versuch mal bei diesen Pi's mit:

    Code
    max_usb_current=1


    in der "/boot/config.txt", aber nur wenn Du auch ein dafür geeignetes Netzteil benutzt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo rpi444

    Danke, dass Du Dir kurz Zeit für mein Problem genommen hast. Ich glaube, ich muss aber noch was ergänzend erklären.


    Versuch mal bei diesen Pi's mit:

    Code
    max_usb_current=1


    in der "/boot/config.txt", aber nur wenn Du auch ein dafür geeignetes Netzteil benutzt.

    Ich habe hier zwei Raspberry Pi Modell B+ nebeneinander stehen. Der eine wurde schon vor Monaten mit dem damaligen Image aufgesetzt, der zweite ist mein "alter" Server und wurde jetzt als Testrechner mit dem Februar-Script neu aufgesetzt.
    - Beide habe NICHTS am USB-Port angeschlossen, sondern sind nur via Patchkabel mit dem Netz verbunden.
    - Beide haben eine fast identische fstab
    - Beide haben auf gleiche Art und Weise mein geändertes Varlog installiert.

    Der neu aufgesetzt Pi mountet nicht die Festplatten und startet bei Boot nicht das Varlogscript. Der alt aufgesetzte macht alles Fehlerfrei. Ich habs mehrfach getestet und überprüft und vorher sogar von meinem PC dafür gesorgt, dass die Platten am Server definitiv aus dem Schlaf aufgeweckt sind. Und interessant ist, dass der neue Server (jetzt Modell 2) ebenfalls die gleichen Probleme hat, kein Mount, kein Varlog. Die einzige Gemeinsamkeit bei den beiden Maschinen ist, dass sie mit dem gleichen Februar-Image installiert wurden. Der Pi mit dem alten Image machts perfekt. Und ein wenig irritierend ist, dass mit uname -a alle drei den gleichen Kernelstand anzeigen. Aber irgendwo muss und wird etwas unterschiedlich sein.

    Das ist jetzt insgesamt kein Drama, ich habs ja über den genannten Umweg gelöst. Mich interessiert jetzt mehr, ob ich das vielleicht einfach aussitzen soll und darauf warte, dass das irgendwann nach einem dist-upgrade gefixed ist, oder ob ich besser doch irgendwas unternehmen sollte. Und ich bin schon neugieirig, ob jemand dieses Phänomen vielleicht auch beobachtet hat.

    vg, Thomas


  • Und ich bin schon neugieirig, ob jemand dieses Phänomen vielleicht auch beobachtet hat.

    Ja, dieses Phänomen ist schon von mehreren beobachtet worden, u. a. auch von: http://forum.ubuntuusers.de/topic/fstab-ko…tioniert-nicht/

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Moin rpi444

    Es gibt anscheinend im Moment keine ordentliche Lösung, nur eine, die funktioniert.... ist aber schon sehr merkwürdig. Interessant ist, dass es auch mit dem mount -a in rc.local nicht ordentlich funktioniert. Anscheinend wartet die Warteschleife in varlog nicht auf den mount in rc.local, sondern blockiert sogar die Ausführung von rc.local. Varlog wird definitiv (entgegen meiner ersten Annahme) ausgeführt, macht aber nix, weil die Platte nicht verfügbar ist. Und rc.local wird erst dann ausgeführt, wenn varlog beendet wurde, erfolgreich oder nicht. Nur ist es dann zu spät.

    Ich habe den mount -a jetzt wieder aus der rc.local entfernt und mit einer Prüfung direkt in das varlog-script eingebaut. Jetzt funktionierts. Ist zwar nicht die perfekte Lösung, aber es funktioniert.... da scheint also wohl wirklich noch ein Fehler im System vorzuliegen.

    Ich habe beispielsweise mal beide PI's parallel gestartet, beide identisch in fstab und script. Ich habe danach das Boot-Log von beiden PI's nebeneinander gestellt und Zeilenweise verglichen. Es gibt keine inhaltlichen Unterschiede... ausser im Timestamp und der Anzeige der Größe von der SD-Card. Nur.... der eine hat gemountet, der andere nicht :s

    Tja, mal abwarten, ob der Fehler irgendwann mal raus-ge-dist-upgraded wird....

    vg, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (15. März 2015 um 19:05)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!