Beiträge von Manul

    leider geht es in meinen Augen nur so

    Dann würde ich Dir vorschlagen, noch weitere Augenpaare zu Rate zu ziehen – z.B. hier im Forum. Wenn Du uns Dein Projekt schildern würdest, statt technische Detailfragen zu stellen, könnten wir evt. andere Ansätze vorschlagen und Dir damit effektiver helfen.

    Wenn ich bei meinem PI "ps -ef |pgrep -f nummer_auslesen" aufrufe,

    Was soll denn das "ps -ef" da? Damit pipest Du den output des ps-Befehls nach pgrep. Keine Ahnung, was das damit macht, brauchen tut's das auf jeden Fall nicht. Der komplette Aufruf wäre also "pgrep -f nummer_auslesen", ohne "ps -ef|" davor.

    Warum sollte ich das im Script machen?

    Weil's am einfachsten und m.W. auch gängige Praxis ist.

    Diesem ist die PID vollkommen egal.

    Schon klar, aber trotzdem darf es nett sein und denen, die auf es aufpassen sollen, mitteilen, wo sie es finden. ;)

    Interessant wäre sie z.B. für eine Prozessüberwachung, doch die kann nicht aus dem Script selber kommen.

    Eben, die macht systemd. Dafür braucht es aber Zugriff auf die PID, den Du ihm auf diese Art am einfachsten zur Verfügung stellst.

    Offenbar werden Prozesse gestartet von einem daemon. (Nach Kill laeuft wieder ein prozess mit anderer PID)

    Ich bin mir nicht sicher, ob das wirklich so ist, oder ob auch da ein Missverständnis vorliegt.


    @sasatt: Kannst Du das mal bestätigen oder widerlegen? Wenn Du unmittelbar nach dem kill des hängenden Prozesses noch mal den fuser-Aufruf startest, wie ist dann die Ausgabe?


    Hast Du mal versucht, te923con mit der Option "-D" (debug output) zu starten?

    Dann wird aber nicht nach dem Namen des Programms gesucht, das den prozess offen hat, sondern nach einem Programm, das einen Parameter mit diesem Text hat. Und da ist eben (bei mir, beim aktuellen Stretch) pgrep dabei.

    Kann ich hier nicht nachvollziehen.

    Jetzt ist eben meine Frage, wie man das machen kann, denn ich bin etwa ratlos.

    Ich würde sagen: Im Skript selbst:

    Code
    1. import os
    2. with open("/var/run/rufnummer.pid","w") as f:
    3. f.write(os.getpid())

    oder so ähnlich.

    Irgendwie scheine ich Schwierigkeiten zu haben, mich verständlich auszudrücken. Ich versuch's nochmal. Was ich gerne sehen würde ist:


    5x Befehl ausführen, Output wegwerfen.


    sudo fuser -v dev/bus/usb/001/002


    strace -f te923con # Das ist jetzt der 6. Durchlauf, der noch nicht hängt. Der strace sollte also zum Ende kommen.


    sudo fuser -v dev/bus/usb/001/002


    strace -f te923con # Das ist jetzt der 7. Durchlauf, der hängt. Wie sieht das Fenster jetzt aus? Steht es oder läuft der strace weiter?


    Bis hierhin wurde alles in einem Fenster ausgeführt. Da dieses jetzt nach meinem Verständnis keinen prompt mehr hat, ist der Moment gekommen, ein zweites zu öffnen. In diesem:


    sudo fuser -v dev/bus/usb/001/002


    kill <PID>


    Was ist jetzt im ersten Fenster zu sehen?

    jetzt Fall A frisch rebootet und einmal ausgeführt-Werte erhalten


    fuser -v liefert nichts


    sudo fuser -v /dev/bus/usb/001/002 liefert nichts

    Das ist, wie es sein soll. Schon mal gut.

    Fall B

    hängt beim siebenten Aufruf

    Das wäre nach meiner Nomenklatur oben Fall C, oder reden wir aneinander vorbei?

    pi@pizero1:~ $ sudo fuser -v /dev/bus/usb/001/002

    BEN. PID ZUGR. BEFEHL

    /dev/bus/usb/001/002:

    pi 919 F.... te923con

    Ist das jetzt direkt vor dem Aufruf, der dann hängt?

    Im ersten Fenster erscheint "Beendet"


    sudo fuser -v /dev/bus/usb/001/002 ergibt danach keine Ausgabe mehr

    strace läuft ohne Ende mit Timeouts im Fenster

    Das verstehe ich nicht: Im ersten Fenster sollte doch genau das strace laufen. Wird das nun beendet oder nicht?

    Ich habe langsam ein bißchen den Überblick verloren, daher noch mal systematisch:


    Wir haben drei Sorten Aufrufe des Befehls:


    A - läuft durch, nächster Aufruf läuft auch durch

    B - läuft durch, nächster Aufruf hängt sich auf

    C - hängt sich auf


    Kannst Du von allen drei Sorten mal ein strace posten? Ich dachte eigentlich, das in #13 wäre von C, aber da scheint der Prozess sich am Ende ja zu beenden. Benutz beim strace bitte noch die Option "-f". Sieht zwar nicht aus, als würde der Befehl weitere Prozesse oder Threads starten, aber sicher ist sicher.


    Außerdem bitte vor und nach jedem strace die Ausgabe von fuser. Dann noch den hängenden Prozess killen (kill <PID, die Du aus dem fuser ouput ablesen kannst> und prüfen, ob der Prozess beendet wurde. Falls nicht, noch mal kill -9 <PID> und dito.


    Wenn wir dann immer noch nichts sehen, weiß ich allmählich auch nicht mehr weiter.

    ich hab Raspberry dort auch mit ip auf NFS freigegeben

    Kannst Du davon mal einen Screenshot posten?

    wenn ich die Abfrage auf Anbindung im Raspberry eingebe und Return drücke wird mir bestätigt das das Laufwerk erreichbar ist

    Was genau gibst Du ein? Welche Antwort erhältst Du?

    Sobald ich aber über den Mount Befehl die Verbindung anfordere sagt es kein Zugriff oder so ähnlich

    Wie genau sieht dieser Befehl aus? Wie lautet die exakte Rückmeldung? Sind das noch die selben wie in Beitrag #1?


    Wie ist auf dem Pi die Ausgabe von showmount -e <IP der NAS>?

    bei -v passiert keine Ausgabe

    Das heißt, daß kein Prozess mehr das device offen hat. Hm, auf Anhieb fällt mir jetzt nichts mehr ein. Merkwürdig. Ich schau morgen noch mal drüber.

    Was passiert denn, wenn Du bei hängendem Prozess in einer neuen ssh-Session den Befehl noch mal aufrufst. Kannst Du den hängenden Prozess identifizieren und abschießen? Macht das einen Unterschied bei einem Neuversuch?

    Hm. Zum call USBDEVFS_SETCONFIGURATION, der in Deinem ersten strace den Fehler produziert, habe ich das hier gefunden:

    Warning

    Avoid using this call until some usbcore bugs get fixed, since it does not fully synchronize device, interface, and driver (not just usbfs) state.

    Aber wenn's auf dem Pi 3 läuft, kann's das ja eigentlich nicht sein.

    Ich hoffe fuser richtig aufgerufen zu haben?

    Nein, durch die Option "-m" listest Du alle Prozesse auf, die irgendein file unter /dev offen haben. Lass die mal weg und verwende stattdessen "-l". "-u" gerne auch.

    raspiBackup and its installer supports englisch and german language. The default value is set by the system language.

    Ich kenne den Originalsatz nicht (und komme in absehbarer Zeit auch leider nicht dazu, mir den Installer anzuschauen), aber das klingt für mich sehr holprig. Gegenvorschlag:

    Zitat


    raspiBackup and its installer support english and german. The default ist set according to the system language.