staging.inyokaproject.org

Hallo und guten Abend

Ich bin am verzweifeln, ich habe einen cronjob der zum Schluss ein script aufruft was eigen dich nur eine datei kopieren soll und dabei eine älter überschreiben soll ohne nach zu fragen.

1
2
3
4

#!/bin/bash
filename=/tmp/status.txt
filecopy=/opt/fhem/status.log
\cp -r $filename $filecopy

das script wird ausgeführt und kopiert auch aber es entsteht immer einen leer Datei ich habe es auch direkt versucht aber der gleiche erfolg es entsteht eine Datei mit der Größe 0

1
2
3
4

#!/bin/bash
filename=/tmp/bluetooth.txt
filecopy=/opt/fhem/bluetag.log
\cp -r status.txt status.log

aber es steht immer eine leere Datei.... was mache ich nur falsch... der cronjob wird als root ausgeführt

1

-rwxrwxrwx  1 user user        0 Okt  3 19:00 status.log

wenn ich das in der Konsole aus führe

1

cp status.txt status.log 

funktioniert es ohne Probleme

comp2000 schrieb:

1 2	... \cp -r $filename $filecopy

... wenn ich das in der Konsole aus führe

1	cp status.txt status.log

funktioniert es ohne Probleme

Hallo!

Versuchst du eigentlich rekursiv Ordner zu kopieren oder tatsächlich nur eine Datei? Dann wäre -f sinnvoller, als -r. Zudem solltest du auf Konsole immer auch das ausprobieren, was du im Script verwendest.

Was sagt ein ls -lha status.txt? Hat die Datei denn Inhalt?

ja es soll nur die Datei immer wieder überschrieben werden habe es gerade auch cp -f versucht und wieder eine 0 Datei

und ja die Ursprungsdatei hat immer den aktuellen Inhalt

1
2

henry@NUC-Server:/opt/fhem$ ls -lha status.txt
-rwxrwxrwx 1 root root 132 Okt  3 16:41 status.txt

Versuch es mal mit vollständigem Pfad für cron: /usr/bin/cp anstatt nur cp.

Und lösche mal die leere Zieldatei. Ich vermute die wird gar nicht angefasst.

also das habe ich schon versucht wenn die Zieldatei lösche wird eine leere also 0 Datei erstellt

habe es jetzt so versucht

1
2
3
4

#!/bin/bash
filename=/tmp/bluetooth.txt
filecopy=/opt/fhem/bluetag.log
/usr/bin/cp -f $filename $filecopy

aber dann wird der Befehl nicht ausgeführt

Wie rufst du das Script auf? Unter welchem Benutzer? Kann dieser den Inhalt der Zieldatei lesen?

wird als sudo fhem aufgerufen

1

*  *    * * *   fhem    sudo /opt/fhem/lescan.sh

ist berechtigt das als sudo ohne password auszuführen und klappt auch aber dadurch sind alle entstehende Dateien root Dateien

1
2
3
4
5
6

!/bin/bash
filename=/tmp/bluetooth.txt
filecopy=/tmp/bluetrans.sh
hcitool lescan > $filename & sleep 5
pkill --signal SIGINT hcitool
/opt/fhem/bluetrans.sh

Dann kann der Kopiervorgang, der ohne sudo ausgeführt wird natürlich den Dateiinhalt nicht lesen.

Du könntest mittels chmod und chown die Dateirechte so anpassen, dass sie ausreichend sind. Also entweder lesend für "alle" machen, oder den Eigentümer auf den ändern, der es lesen können soll.

Alternativ könntest du den Kopiervorgang auch im Hauptscript laufen lassen.

ich denke mal mehr an Dateirechte geht nicht oder

ich werde noch irre warum ein 0 Datei beim kopieren entsteht

1
2

-rwxrwxrwx  1 fhem dialout      0 Okt  5 16:30 bluetag.log
-rwxrwxrwx  1 fhem dialout    132 Okt  5 16:30 bluetooth.txt

edit so hatte gerade das script so geändert

1
2
3
4

#!/bin/bash
filename=/opt/fhem/bluetooth.txt
filecopy=/opt/fhem/bluetag.log
\cp -f $filename $filecopy

danach wurde die Datei einmal richtig überschrieben aber bei der nächsten Ausführung des gleich script wurde wieder die 0 Datei erstellt. So jetzt blicke ich gar nicht mehr durch das script wird ja durch cronjob jede Minute ausgeführt und nach 4 maliger Ausführung wurde die Datei richtig kopiert und danach wieder eine 0 Datei ohne das ich am script was geändert habe. wer kann mir das erklären dachte immer Computer machen nur was sie sollen

1
2
3
4
5
6
7
8

-rwxrwxrwx  1 fhem dialout      0 Okt  5 17:15 bluetag.log
-rwxrwxrwx  1 fhem dialout    160 Okt  5 17:19 bluetag.log
-rwxrwxrwx  1 fhem dialout      0 Okt  5 17:20 bluetag.log
-rwxrwxrwx  1 fhem dialout    160 Okt  5 17:24 bluetag.log
-rwxrwxrwx  1 fhem dialout      0 Okt  5 17:25 bluetag.log
-rwxrwxrwx  1 fhem dialout      0 Okt  5 17:34 bluetag.log
-rwxrwxrwx  1 fhem dialout    160 Okt  5 17:59 bluetag.log
-rwxrwxrwx  1 fhem dialout      0 Okt  5 18:03 bluetag.log

keine Logik kein System wie geht das

Habe das mal eben unter nem Ubuntu Server gestestet. Da ist cp unter /bin/cp ohne /usr/.

Davon abgesehen lief das kopieren problemlos mit ner Testdatei.

Wenn die Datei an sich richtig kopiert wird, aber nicht jedesmal, könnte es an verzögerten Aufrufen liegen, die Datei könnte für den Moment nicht lesbar sein oder wird gerade geschrieben. Kann das leider gerade nicht nachstellen. Bin auch gerade zeitlich etwas knapp, um mir eine Testumgebung zu basteln.

Versuch mal Infos zu loggen, oder Fehler. Siehe Shell/Umleitungen

@comp2000: Bist Du ganz sicher das die Ursprungsdatei mehr als 0 Byte hat? Du startest ja einen Prozess dessen Ausgabe in diese Datei umgeleitet wird und killst den nach fünf Sekunden. Wenn in dieser Zeit nichts in die Datei geschrieben wird, oder vielleicht auch wenn da nicht genug geschrieben wird das der Dateipuffer tatsächlich rausgeschrieben wird, dann ist die Datei vielleicht tatsächlich leer.

@Marc_BlackJack_Rintsch ja die Ursprungsdatei ist gefüllt

@ChickenLipsRfun2eat ja das Gefühl hatte ich auch, das die vom cronjob erzeugte Datei irgend wie blockiert wird.

da du meinen Verdacht bestätigt hast habe ich folgendes probiert:

1
2
3
4
5
6
7
8

!/bin/bash
filename=/opt/fhem/bluetooth.txt
filecopy=/tmp/bluetrans.sh
hcitool lescan > $filename & sleep 3
pkill --signal SIGINT hcitool
sleep 1
/opt/fhem/bluetrans.sh
exit

und es funktioniert ☺ drei mal auf Holz klopfen aber kann es mir jemand erklären? Ich bin kein Profi will aber Linux verstehen

@comp2000: pkill sendet dem hcitool-Prozess die Aufforderung sich zu beenden, und danach wird dann gleich die Datei kopiert. Der hcitool-Prozess muss da aber noch gar nicht wirklich zu Ende sein, der kann immer noch damit beschäftigt sein sich zu beenden und Ressourcen aufzuräumen, und eben auch die Dateien zu schliessen und die Daten aus Puffern rauszuschreiben. Wenn er dazu noch nicht gekommen ist wenn cp seinen Job macht, dann ist die Datei noch leer.

Eine Sekunde warten kann helfen, wäre mir aber zu unsicher, denn wenn gerade viel I/O-Last herrscht kann das nicht lang genug sein. Andererseits kann das auch in vielen Fällen unnötig lang sein. Besser man wartet bis der Prozess sich beendet hat. Also wait statt sleep 1.

@Marc_BlackJack_Rintsch genau so ist es gekommen .... es funktionierte 20min und dann kam es zu Problemen diese treten nicht Zeitlich nachvollziehbar auf. könnte wirklich sein das es System abhängig ist. wer das mal mit deinen Tipp ausprobieren.