Cronjob-Dateien landen in "root", NAS über Web nicht mehr erreichbar

[oese]

Hallo,

vorweg: Ich bin absolut Linux-unerfahren, habe es aber dank guter Anleitungen geschafft, für ein Automatisierungssystem (X-Control) die Web-Oberfläche "xsxcontrol" zu meiner vollen Zufriedenheit auf meiner Synology zum laufen zu bringen. Dazu gehört auch die Einrichtung von Cronjobs, mit welchen Aktoren und Sensoren abgefragt werden.

Allerdings habe ich seit gestern das Problem, dass ich nicht mehr auf mein NAS komme (WebAdmin) und xsxcontrol nicht mehr erreichbar, da der Systemspeicher voll ist.

Ich habe nach Suche hier im Forum folgende Abfragen auf dem NAS mit folgenden Ergebnissen ausgeführt:

DiskStation> df -h
Filesystem Size Used Available Use% Mounted on
/dev/md0 2.3G 2.3G 0 100% /
/tmp 249.7M 144.0K 249.6M 0% /tmp
/run 249.7M 1.6M 248.1M 1% /run
/dev/shm 249.7M 0 249.7M 0% /dev/shm
/dev/md2 1.3T 504.5G 866.3G 37% /volume1
/dev/md3 2.7T 1.2T 1.5T 44% /volume2


DiskStation> du -d 1 -x /
760 /bin
16 /.system_info
4 /.old_patch_info
4 /volumeUSB1
6300 /etc
4 /initrd
188940 /lib
4 /mnt
5672 /.syno
4 /lost+found
1886332 /root
4216 /sbin
275416 /usr
5964 /var
6032 /etc.defaults
2120 /var.defaults
4 /tmpRoot
2381804 /


Wenn ich das richtig verstanden habe, zeigen die folgenden zwei Zeilen das Problem:

/dev/md0 2.3G 2.3G 0 100% /

und

1886332 /root


Also habe ich in das Root Verzeichnis per "ls" geschaut und dort unendlich viele Einträge wie die folgenden gefunden:

cronjob.update.aktoren.php.1462 lib.inc.statistics.log.php.997
cronjob.update.aktoren.php.14620 lib.inc.statistics.log.php.998
cronjob.update.aktoren.php.14621 lib.inc.statistics.log.php.999


Könnte es sein, dass hier das Problem liegt? Und wenn ja, wie bekomme ich die Einträge möglichst einfach gelöscht (einzeln würde ewig dauern...) und wie kann ich das in Zukunft verhindern? Oder liege ich völlig falsch? Ich hoffe, ihr könnt mir helfen - danke!


Torsten

 

[Benares]

Die Datei kannst du leicht weghauen mit z.B. "rm /root/cronjob*" bzw. "rm /root/lib.inc.*". Die Frage ist aber, was/wer sie dort ablegt.

Was steht in /etc/crontab?
Ist ein zeitlicher Zusammenhang zwischen dem Zeitstempel der Dateien und einem der Jobs erkennbar?

Edit:
Uups - grad oben nochmal gelesen - da steht ja alles. Wird wohl an den selbst eingerichteten cronjobs liegen, die halt ins falsche Verzeichnis schreiben.

 

[oese]

Hi,

danke für die schnelle Antwort - Dateien sind gelöscht... Könntest du mir vielleicht noch beim zweiten Schritt helfen, nämlich zu verhindern, dass das noch mal passiert? Wo muss ich etwas an den cronjobs verändern?

Torsten

 

[Benares]

Was hast du denn in die /etc/crontab eingetragen?

 

[oese]

Hier sind die Einträge:

#minute hour mday month wday who command
0 0 1 * * root /usr/syno/bin/syno_disk_health_record
7 20 * * 0,1,2,3,5 root /usr/syno/bin/synopkg chkupgradepkg
*/4 * * * * root /usr/syno/bin/wget 192.168.178.13/xsxcontrol/cronjob.update.sensoren.php
*/12 * * * * root /usr/syno/bin/wget 192.168.178.13/xsxcontrol/lib.inc.statistics.log.php
*/2 * * * * root /usr/syno/bin/wget 192.168.178.13/xsxcontrol/cronjob.update.aktoren.php
* */1 * * * root /usr/syno/bin/wget 192.168.178.13/xsxcontrol/cron.diagramme1.php
* 4 * * * root /usr/syno/bin/wget 192.168.178.13/xsxcontrol/cron.diagramme2.php
* */24 * * * root /usr/syno/bin/wget 192.168.178.13/xsxcontrol/cron/maintenance.php

 

[Benares]

Ich verstehe nicht wozu diese wgets gut sind, aber es ist klar, dass so Dateien unter /root entstehen. Ich versteh aber nicht wieso diese Dateien ein .<nummer> am Ende haben.

Ergänze bitte die xscontrol-Zeilen mit ">/dev/null 2>&1" also z.B.

...
*/4 * * * * root /usr/syno/bin/wget 192.168.178.13/xsxcontrol/cronjob.update.sensoren.php >/dev/null 2>&1
...

Das lenkt die Ausgabe der Befehle ins Nirwana.

 

[luddi]

Entweder so, oder aber wenn die php scripte nur ausgeführt werden sollen dann verwende anstelle von "wget" den Befehl "php".
Das müsste doch völlig ausreichen oder nicht?

...
*/4 * * * * root /usr/bin/php -f 192.168.178.13/xsxcontrol/cronjob.update.sensoren.php
...

Gruß
luddi

 

[oese]

Gut, mache ich - danke für den Tipp. Mal schauen, ob das Programm an sich, in welchem die Daten protokolliert werden (SQL-Datenbank), auch so funktioniert. Wie gesagt, ich bin da absolut unbedarft und habe alles Punkt für Punkt nach Anleitung eingerichtet....

Torsten

EDIT: jetzt bin ich wieder verwirrt - welche der beiden Lösungen wäre die Bessere für mich? Wie gesagt, die Ergebnisse der Abfragen (z.B. Temperaturen) sollen in einer SQL-Datenbank abgespeichert werden...

 

[luddi]

EDIT: jetzt bin ich wieder verwirrt - welche der beiden Lösungen wäre die Bessere für mich?

Das solltest du selbst mal ausprobieren ob denn beide Vorschläge auch genau so funktionieren wie du es dir vorstellst. Und wenn beide zum gewünschten Ergebnis führen dann kannst du das für dich selbst entscheiden welchen Befehl du lieber verwenden möchtest...

Wie gesagt, die Ergebnisse der Abfragen (z.B. Temperaturen) sollen in einer SQL-Datenbank abgespeichert werden...

Das erledigt ja nicht der Crontab, sondern die einzelnen php scripte werden sicher dafür sorgen die Daten zu verwalten.

Gruß
luddi

 

[oese]

Alles klar, danke! Dann werde ich mal probieren...

Viele Grüße an euch
Torsten

 

[luddi]

Dieser xsxcontrol Server läuft wenn ich das richtig verstanden habe auf der Syno. Die Dateien bzw. das gesamte Verzeichnis liegt dann bei dir auf dem System unter /web?

Gruß
luddi

 

[Benares]

Ich hab grad mal mit wget rumgespielt.
wget scheint von sich aus eine .<zahl> anzuhängen, wenn die Datei bereits existiert. Dadurch entstehen diese vielen Dateien.
Soll die Datei immer überschrieben werden, hilft evtl. "wget -N ...".
Trotzdem ist mir nicht klar, was diese Dateien unter /root zu suchen haben.

 

[oese]

Dieser xsxcontrol Server läuft wenn ich das richtig verstanden habe auf der Syno. Die Dateien bzw. das gesamte Verzeichnis liegt dann bei dir auf dem System unter /web?

Gruß
luddi

Ja, richtig.

 

[luddi]

Trotzdem ist mir nicht klar, was diese Dateien unter /root zu suchen haben.

Das /root ist das user home Verzeichnis von 'root'. Und der default Pfad für den User ist eben sein eigenes User home. Sobald du nun ein wget ausführst dann wird diese Datei geladen und exakt dort gespeichert von welchem Pfad aus der Befehl ausgeführt wurde.

Das ist völlig korrekt.

Gruß
luddi

 

[oese]

Falls es von Interesse ist, hier ist das system bzw. die Installation beschrieben:

http://www.xsxcontrol.de/homeautomation/installation/

Ich habe die dort beschriebene Variante 2 über cronjobs gewählt, weil Variante 1 (Auslesen in Echtzeit) nur für QNAP beschrieben ist und mich daher überfordert hat....

Ich teste gerade die Version "wget" durch "php" ersetzt, muss ich jetzt mal ein paar Minuten beobachten...

Torsten

 

[luddi]

Ja, richtig.

Ok dann liegen die Web Verzeichnisse auf deinem System mit großer Wahrscheinlichkeit unter '/volume1/web'.

Dann müsste man den php Befehl den ich dir vorgeschlagen habe nochmal anpassen und anstelle der IP Adresse den lokalen Pfad angeben. Denn es kann nämlich sein dass die Datei sonst über die IP Adresse nicht ausführbar ist (je nachdem wie die Rechte sind bzw. der Zugriff über eine mögliche .htaccess gehandhabt wird).

...
*/4 * * * * root /usr/bin/php -f /volume1/web/xsxcontrol/cronjob.update.sensoren.php
...

Gruß
luddi

 

[luddi]

Falls es von Interesse ist, hier ist das system bzw. die Installation beschrieben:

http://www.xsxcontrol.de/homeautomation/installation/

Ja in der Tat habe ich Interesse daran. Danke für den Link.

Aber jetzt mal zu Variante 2 die du ja angeblich in Betracht gezogen und dein System danach eingerichtet hast.

www.xsxcontrol.de

Variante 2:In einem festen Intervall die Aktor- und Sensordaten auslesen
Cronjob einrichten für Aktordaten
Beispiel crontab-Eintrag, um die Aktordaten alle zwei Minuten neu einzulesen:
# m h dom m dow cmd
*/2 * * * * /mnt/ext/opt/apache/bin/php -q /<PfadzumWebspace>/cronjob.update.sensoren.php

Hier werden die Scripte auch mit dem Befehl 'php' aufgerufen. Wie bitte bist du denn auf wget gekommen? Denn wenn man auf dieser Seite nach 'wget' sucht, so landet man keinen einzigen Treffer.

Gruß
luddi

 

[oese]

Tja, wenn ich das wüsste....

Aber nun scheint alles wunderbar zu laufen - danke für eure Hilfe!

Torsten

 

[oese]

Hmm, die einfache Änderung von "wget" in "php" scheint doch nicht zu laufen, ich habe keine Frotschreibung mehr seit 17.00 uhr. Dann muss ich morgen mal die andere Lösung probieren - jetzt komme ich nicht mehr dazu...

 

[Benares]

Da musst du wohl besser jemand fragen, der dieses "xscontrol" besser kennt. Grundkenntnisse in crontab&Co helfen hier nicht weiter.