Skript per Cron --> Festplatten fahren hoch?

[onasco]

Gibt es eine Möglichkeit auf der DS ein Skript ausführen zu lassen ohne dass dabei die Festplatten hochfahren? Selbst ein simples echo "Hallo" gestartet von /tmp/hallo.sh via cron fährt die Festplatten hoch.

 

[thedude]

Liegt bestimmt daran, dass crond irgend eine Datei offen hat bzw. öffnet. Mit:

ls -l /proc/`pidof crond`/fd

Kannst Du sehen was er offen hat... keine Ahnung ob Dir das weiterhilft.

gruss
dude

 

[jahlives]

afaik loggt cron auch nach /var/log/messages was auch die Platten wecken dürfte.

 

[itari]

Wenn man das Skript auf /tmp zum Server macht, dann geht es vermutlich:

Ein Server(programm) ist ein Programm, dass nicht mehr von alleine aufhört und seinen Ausgabe in eine Datei schreibt

Also z.B.

while true; do                  # Endlosschleife
echo 'hallo' > /tmp/myfile.txt  # hier wird der Inhalt immer überschrieben
sleep 600                       # 5 Minuten
done

Das kannst händisch starten (oder aus einem Startskript /etc/rc.local oder /usr/syno/etc/rc.d/S99_myscript.sh)

Itari

 

[onasco]

Seid gegrüsst, ihr Syno-Götter

Liegt bestimmt daran, dass crond irgend eine Datei offen hat bzw. öffnet. Mit:

ls -l /proc/`pidof crond`/fd

Ergibt folgendes:

/proc/3966:
-r--------    1 root     root            0 Jan 18 21:45 auxv
-r--r--r--    1 root     root            0 Jan 18 21:45 cmdline
lrwxrwxrwx    1 root     root            0 Jan 18 21:45 cwd -> /var/spool/cron/crontabs
-r--------    1 root     root            0 Jan 18 21:45 environ
lrwxrwxrwx    1 root     root            0 Jan 18 21:45 exe -> /bin/busybox
dr-x------    2 root     root            0 Jan 18 21:45 fd
-r--r--r--    1 root     root            0 Jan 18 21:45 maps
-rw-------    1 root     root            0 Jan 18 21:45 mem
-r--r--r--    1 root     root            0 Jan 18 21:45 mounts
-rw-r--r--    1 root     root            0 Jan 18 21:45 oom_adj
-r--r--r--    1 root     root            0 Jan 18 21:45 oom_score
lrwxrwxrwx    1 root     root            0 Jan 18 21:45 root -> /
-r--r--r--    1 root     root            0 Jan 18 21:45 smaps
-r--r--r--    1 root     root            0 Jan 18 21:45 stat
-r--r--r--    1 root     root            0 Jan 18 21:45 statm
-r--r--r--    1 root     root            0 Jan 18 21:45 status
dr-xr-xr-x    3 root     root            0 Jan 18 21:45 task
-r--r--r--    1 root     root            0 Jan 18 21:45 wchan

1844/fd:
lrwx------    1 root     root           64 Jan 18 21:39 0 -> /dev/null
lrwx------    1 root     root           64 Jan 18 21:39 1 -> /dev/null
lrwx------    1 root     root           64 Jan 18 21:39 2 -> /dev/null
lrwx------    1 root     root           64 Jan 18 21:39 3 -> /dev/ttyS1
lrwx------    1 root     root           64 Jan 18 21:39 4 -> /dev/synobios
lr-x------    1 root     root           64 Jan 18 21:39 5 -> /etc/TZ
lrwx------    1 root     root           64 Jan 18 21:39 6 -> socket:[1024]

Auch wenn mir das kaum was bringen wird, rein aus Neugierde: Welche Dateien sind potentiell schuld?

afaik loggt cron auch nach /var/log/messages was auch die Platten wecken dürfte.

Tönt plausibel, scheint aber nicht der Fall zu sein. Könnte es eine andere Logdatei sein? Das Logging liesse sich wohl aber kaum deaktivieren, oder?

@itari: Die Idee mit dem Serverprogramm tönt genial kreativ! Werde ich ausprobieren.

Danke und Gruss
onasco

 

[mkl0815]

Der crond startet für jeden Eintrag in der crontab den er ausführt eine Shell und die wird nun mal von der Platte geladen.
Das Problem wird weiterhin sein, wenn Du die Lösung von itari (eigenes Script ohne cron) verwendest, das Du in Deinem Script nur Befehle verwendn kannst, die in die Shell eingebaut sind. Alles andere wird sonst auch wieder nachgeladen und startet damit die Platten.

 

[itari]

Der crond startet für jeden Eintrag in der crontab den er ausführt eine Shell und die wird nun mal von der Platte geladen.
Das Problem wird weiterhin sein, wenn Du die Lösung von itari (eigenes Script ohne cron) verwendest, das Du in Deinem Script nur Befehle verwendn kannst, die in die Shell eingebaut sind. Alles andere wird sonst auch wieder nachgeladen und startet damit die Platten.

Wobei wir immer denken müssen, dass wir auf der DS mit einer Busybox-Implementation spielen; die Busybox enthält ja so ziemlich alle Linux-Commands/Tools. Die Busybox ist quasi resident (weil sie auch der 'init' ist). Aber im Grund ist das schon richtig gedacht mit dem Nachladen ... Um dem auch noch aus dem Weg zu gehen, müsste man eine Kopie der Programme, die in der Schleife stehen, ins Verzeichnis /tmp machen oder eine Mem-Stick als externe Platte verwenden, wo die Programme als Kopie drauf sind ...

Ich wollte mit meinem Beispiel eigentlich nur den Weg aufzeigen, wie man auch ohne crond/crontab periodisch wiederkehrende Programmausführungen realisieren kann ...

Itari

 

[mkl0815]

Ich wollte mit meinem Beispiel eigentlich nur den Weg aufzeigen, wie man auch ohne crond/crontab periodisch wiederkehrende Programmausführungen realisieren kann ...

Das habe ich mir schon gedacht und mein Post sollte auch keine Kritik sein.
Leider wird wahrscheinlich trotz der permanent geladenen busybox immer ein Plattenzugriff erfolgen. Denn die ganzen Tools liegen ja als Symlink auf der Platte. Der crond weiß ja nix davon, der startet nur stur sein "/bin/sh" für den auszuführenden Befehl. Der ist ein Symlink auf der Platte, der auf die busybox zeigt, welche geladen wird, einen Prozess forkt und losläuft.
Selbst wenn man also alles nach /tmp/ (Ramdisk?) auslagert, bleibt der Hook über die Shell die der crond startet, wobei man die glaub ich in der /etc/crontab festlegen kann.

 

[itari]

Leider wird wahrscheinlich trotz der permanent geladenen busybox immer ein Plattenzugriff erfolgen. Denn die ganzen Tools liegen ja als Symlink auf der Platte.

Ich kann mit den Busybox-Commands ein zeitlang im telnet spielen, bevor die Platten wieder anlaufen, obwohl die Symlinks da sind. Vermutlich liegt es daran, dass das Zeugs noch im File-System-Buffer steht. Symlinks werden ja in ext3 nicht als File gespeichert, sondern stehen (solange sie nicht wirklich lang sind) direkt in der Inode (kann auch sein, dass sie sogar im directory-file stehen - hab da mal was zu gefunden gehabt). Wie dem auch sein, es kann also gut sein, dass man ohne Plattenzugriffe eine zeitlang hinkommt.

Itari

PS. es gab hier im Forum schon öfters mal eine Diskussion über Sticks usw. und wie man es verhindern kann, dass die Platten aufgeweckt werden. Am besten ist natürlich ne kleine SSD und die Auflösung des md0- und md1-RAIDs

 

[onasco]

Hab mal ein wenig mit der Idee von itari gespielt. Wenn man die Programme, welche im Serverprogramm verwendet werden, inkl. sh, ebenfalls nach /tmp kopiert und im Skript darauf verweist, springen die Festplatten tatsächlich nicht mehr an. Allerdings betrifft das nur einfache Programme wie z.B. echo. Andere Programme wie nslookup oder ping fahren die Platten aber hoch. Wahrscheinlich greifen die noch auf irgendwelche Librarys, Cache-Dateien oder was auch immer zu.

Mit meinem Serverskript müsste ich unter anderem die Namen div. Hosts auflösen. nslookup, ping und adnshost wecken leider allesamt die Platten.

 

[jahlives]

Mit meinem Serverskript müsste ich unter anderem die Namen div. Hosts auflösen. nslookup, ping und adnshost wecken leider allesamt die Platte

**Offtopic**

cp -R / /tmp

**/Offtopic**

 

[itari]

**Offtopic**

cp -R / /tmp

**/Offtopic**

Du denkst aber auch daran, dass das /tmp im virtuellen Memory steht? Wenn das physikalische RAM nicht ausreicht, wird wieder geswappt ... und damit entstehen wieder Plattenaktivitäten

Itari

 

[tokon]

Ich hole mal diesen alten Thread nochmal raus.

Ist dieses Verhalten bei Synology noch immer so, dass ein Skript welches per Cron oder Aufgabenplaner aus /tmp gestartet wird die Festplatten aufweckt?
Aktuell habe ich noch eine QNAP, hier bleibt die HDD aus, wenn ich Skripte aus /tmp starte. Wenn dies bei Synology nicht funktioniert kann ich den HDD-Standby schon mal vergessen.

 

[Benares]

Leichenschänder - Kommt halt drauf an, was das Script macht. Wenn es mit den Platten arbeitet, werden die wohl aufwachen

 

[tokon]

So wie ich das hier verstanden hab lag es damals eher an cron selbst als am Script.

In meinem Fall würde das Scripts zunächst nur mal ein Datum aus einer Datei einlesen (liegt ebenfalls unter /tmp) und mit dem aktuellen vergleichen. Solange das Datum nicht erreicht ist bricht das Script ab. Bis hierhin gäbe es also keinen Grund die Platte zu wecken.
Nächste Woche sollte die Syno kommen, dann muss ich das mal testen und falls es nicht wie gewünscht funktioniert überlegen, was ich dann mache.

 

[tokon]

So, NAS ist eingerichtet, Test abgeschlossen. Aktuell sieht es wie folgt aus:
- Script per Aufgabenplaner weckt die HDD auf
- Script manuell in Crontab eingetragen lässt die HDD ruhen

 

[DarkZone-World]

Kann mir vielleicht jemand helfen. Ich habe ein Script manuell in Crontab eingebunden und das hat immer funktioniert, ohne dass die HDD aufgeweckt werden.

Seit dem Update auf DSM 5.2 werden nach ausführen des Scripts die HDDs geweckt.

Hier mein Script:

* * * * * root echo "6" > /dev/ttyS1 || true

Warum ging das vor dem Update und jetzt nicht mehr.

Für jede Hilfe wäre ich sehr dankbar!