Skript per Cron --> Festplatten fahren hoch?

Status
Für weitere Antworten geschlossen.

onasco

Benutzer
Mitglied seit
04. Jan 2009
Beiträge
23
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
30. Nov 2009
Beiträge
2.244
Punkte für Reaktionen
2
Punkte
84
Liegt bestimmt daran, dass crond irgend eine Datei offen hat bzw. öffnet. Mit:

Rich (BBCode):
ls -l /proc/`pidof crond`/fd

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

gruss
dude
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
afaik loggt cron auch nach /var/log/messages was auch die Platten wecken dürfte.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
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 :D

Also z.B.

Rich (BBCode):
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

Benutzer
Mitglied seit
04. Jan 2009
Beiträge
23
Punkte für Reaktionen
0
Punkte
0
Seid gegrüsst, ihr Syno-Götter :)

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

Rich (BBCode):
ls -l /proc/`pidof crond`/fd

Ergibt folgendes:
Rich (BBCode):
/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

Benutzer
Mitglied seit
23. Sep 2009
Beiträge
138
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
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

Benutzer
Mitglied seit
23. Sep 2009
Beiträge
138
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
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

Benutzer
Mitglied seit
04. Jan 2009
Beiträge
23
Punkte für Reaktionen
0
Punkte
0
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

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Mit meinem Serverskript müsste ich unter anderem die Namen div. Hosts auflösen. nslookup, ping und adnshost wecken leider allesamt die Platte
**Offtopic**
Code:
cp -R / /tmp
;) ;)
**/Offtopic**
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
**Offtopic**
Code:
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

Benutzer
Mitglied seit
12. Dez 2015
Beiträge
192
Punkte für Reaktionen
41
Punkte
28
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

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
13.638
Punkte für Reaktionen
3.657
Punkte
468
Leichenschänder - Kommt halt drauf an, was das Script macht. Wenn es mit den Platten arbeitet, werden die wohl aufwachen ;)
 

tokon

Benutzer
Mitglied seit
12. Dez 2015
Beiträge
192
Punkte für Reaktionen
41
Punkte
28
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

Benutzer
Mitglied seit
12. Dez 2015
Beiträge
192
Punkte für Reaktionen
41
Punkte
28
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

Benutzer
Mitglied seit
21. Mrz 2016
Beiträge
32
Punkte für Reaktionen
0
Punkte
12
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!
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat