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

[oese]

Ja,

ich bin mit der Frage jetzt auch im entsprechenden Forum unterwegs....

 

[luddi]

Aber wenn es mit "wget" vorher funktioniert hat und das einzige Problem ein vollgemüllter Speicherplatz unter /root war, dann würde ich es wie Benares schon unter Post #6 vorgeschlagen hat die Ausgabe einfach ins "Nichts" umleiten mit ">/dev/null 2>&1"

EDIT: scheint doch nicht zu funktionieren, denn es wird ja nur die Ausgabe umgeleitet. Aber die Datei wird trotzdem heruntergeladen... habe es selbst gerade ausprobiert.

Gruß
luddi

 

[hvkls]

Ich gehe mal davon aus, dass du gar keine Datei speichern willst, sondern nur einen 'Schalter' betätigen willst, richtig?

...
*/4 * * * * root /usr/syno/bin/wget [B]-qO- http://[/B]192.168.178.13/xsxcontrol/cronjob.update.sensoren.php [I]>/dev/null 2>&1[/I]
...

EDIT: Vielleicht doch nicht, sollen irgendwie Statistiken erstellt werden und es soll genau eine Version jeder Datei behalten werden? Oder wieviele?

 

[oese]

Hm, ich habe heute über nacht die Cronjobs wie folgt laufen lassen:

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

Klappt alles, die Daten werden abgefragt, geliefert und in der SQL-Datenbank abgespeichert, aber auch root wird wieder zugemüllt. Ich probiere jetzt mal die von Benares unter Post #6 genannte version...

 

[luddi]

[...] aber auch root wird wieder zugemüllt. [...]

Mit was zugemüllt, mit genau den gleichen Dateien wie zuvor auch?

Gruß
luddi

 

[oese]

Ja, genau. Ist schon komisch. Mit der Ergänzung ">/dev/null 2>&1" klappt es gar nicht, da kommen keine Werte an.

 

[luddi]

Dann würde mich jetzt interessieren was in den php files steht. Ich wollte das Tool selbst mal herunterladen aber man müsste sich dort im Forum anmelden. Könntest du die php files mal zur Verfügung stellen?

Gruß
luddi

 

[oese]

Hi, super, danke für deine Hilfe. Wie soll ich dir die Dateien am besten zusenden?

 

[luddi]

Pack sie in ein *.zip Archiv, benenne das Archiv um in *.pdf und häng es hier im Post mit an. Das müsste funktionieren...

 

[oese]

Na, dann testen wir mal....ist angehängt. Ansonsten könnte ich per PN auch nen dropbox-link zusenden...Anhang anzeigen xsxcontrol.pdf

 

[luddi]

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

Was steht denn eigentlich in diesen Dateien die das /root Verzeichnis zumüllen? Das scheint mir so als wären das die Logfiles die von den entsprechenden php files geschrieben werden...

Gruß
luddi

 

[Benares]

Die Datei sind m.E. Überbleibsel von den wget-Versuchen, keine Log-Files. oese sollte sie einfach noch einmal löschen.
Ich dachte erst auch das seien Log-Files, daher der Vorschlag mit der Ausgabeumlenkung nach /dev/null. Aber wget selbst versioniert die Downloads, wenn die Datei bereits existiert.

 

[luddi]

Ja, das stimmt. Ich dachte er hat alle Überbleibsel schon gelöscht... wäre schön wenn er uns mal den Zeitstempel der Dateien aus /root zeigt
@oese: Einfach mal die Ausgabe von "ls -la /root" zeigen.

luddi

 

[oese]

Hi,

ich hatte zwischendurch wieder alles gelöscht... Ich mache jetzt folgendes:
Ich lasse die cronjobs mal eine halbe Stunde laufen (mit "php -f" anstat "wget"), lese dann "root" aus, falls sich dort wieder Dateien angesammelt haben, poste ich hier ihren Inhalt und dazu poste ich die Ausgabe von "ls -la /root"... Wäre das so o.k. und würde das weiterhelfen?

Danke für eure Geduld!

Torsten

 

[luddi]

Ja das wäre äußerst interessant.

Gruß
luddi

 

[oese]

Mir ist da noch eine Idee gekommen:

Wäre es nicht auch eine (einfachere) Lösung, das Verzeichnis "root" z.B. täglich per cronjob zu säubern? Also alle cron*-Dateien automatisch zu löschen?

 

[luddi]

Die Idee ist prinzipiell gut, das kannst du als workaround machen. Nur wundert es mich warum überhaupt Daten in dem Verzeichnis abgelegt werden.

 

[Benares]

@oese: Poste doch bitte den aktuellen Inhalt der /etc/crontab.

Bevor du mit der crontab weitermachst, lass jeden Befehl einmal manuell laufen und schau, ob/was sich in /root ändert. Also z.B.

cd /root
/usr/syno/bin/php -f /volume1/web/xsxcontrol/cronjob.update.sensoren.php
ls -als
/usr/syno/bin/php -f /volume1/web/xsxcontrol/cronjob.update.sensoren.php
ls -als

Edit: Hab mal kurz gegoogelt. Andere nutzen "php -q ..." in der crontab für xsxcontrol-Scripte. Die Option -q find ich aber beim Syno-php nicht.

 

[oese]

Was bezweckt denn eigentlich -f?

 

[luddi]

Wenn du die Hilfe aufrufst "php -h" findest du folgendes.

-f <file> Parse and execute <file>.