Script und alle benötigten Kommandos und Libs aus dem RAM?

[jahlives]

Hallo zusammen

hatte die letzten Tag in einem Thread zu tun wo es darum ging ein Script so auszuführen, dass die Festplatten der Hibernate nicht verlassen.
Ich dachte, dass müsse sich umsetzen lassen, indem man alle benötigten Kommandos nach /tmp kopiert. /tmp ist ja afaik ein RAM-Verzeichnis.

Jetzt habe ich /bin/busybox nach /tmp kopiert und in /tmp dann die benötigten Links auf busybox erstellt z.B. /tmp/ps -> /tmp/busybox
Wie es nun aber scheint werden die Platten trotzdem noch aufgeweckt. Die Frage die sich mir stellt wäre nun: Auf welche Komponenten greift denn busybox noch zu? Eigentlich habe ich gemeint, dass busybox statisch verlinkt kompiliert würde. Darum bin ich davon ausgegangen, dass alle benötigten Libs auch im Binary von busybox enthalten sein müssten.
Kann man irgendwie "herausfinden" auf welche Dateien ein bestimmter busybox-Befehl noch zugreift? Oder weiss jemand welche(s) Verzeichnis(se) man noch nach /tmp schieben müsste, damit busybox komplett aus dem Speicher laufen kann?

Thanks for any help/idea
Gruss

tobi

 

[goetz]

Hallo,
die busybox ist statisch gelinkt

DS-106> file /bin/busybox
/bin/busybox: ELF 32-bit (...), version 1 (SYSV), statically linked, for GNU/Linux 2.4.3, stripped
DS-106> ldd /bin/busybox
$       not a dynamic executable

Sind da nur busybox Befehle im Script?
Da gab es doch mal eine Hibernate-debug Anleitung von Syno.

Gruß Götz

 

[jahlives]

Hallo,
die busybox ist statisch gelinkt

DS-106> file /bin/busybox
/bin/busybox: ELF 32-bit (...), version 1 (SYSV), statically linked, for GNU/Linux 2.4.3, stripped
DS-106> ldd /bin/busybox
$       not a dynamic executable

Sind da nur busybox Befehle im Script?
Da gab es doch mal eine Hibernate-debug Anleitung von Syno.

Gruß Götz

Soweit sind nur noch busybox Befehle im Code. Aber gemäss dem User funzt Hibernate trotzdem nicht. Kann es leider bei mir nicht testen, das meine Platten eh nie schlafen
Der aktuelle Code sieht z.Z. so aus:

#!/tmp/sh

## Pfad zu getmail.sh hier anpassen
pfad_getmail="/path/to/getmail.sh"

if test -e /tmp/checkmail ; then
 echo "Code rennt bereits"
 exit
fi

if test "$(whoami)" = "root" ; then
 echo "Code darf NIEMALS unter root laufen. Das gibt Aerger mit dem Dovecot!"
 exit
fi

if test ! -e $pfad_getmail ; then
 echo "$pfad_getmail konnte nicht gefunden werden"
 exit
fi

## Benoetigte Kommandos in /tmp "erstellen", damit die Platten durchschlafen können
## WICTHIG: Der Link zwischen /tmp/busybox und /tmp/sh MUSS manuell vor dem Aufruf der Scriptes erstellt werden!!
cp -f /bin/busybox /tmp/ > /dev/null 2>&1
ln -s /tmp/busybox /tmp/grep > /dev/null 2>&1
ln -s /tmp/busybox /tmp/ps > /dev/null 2>&1
ln -s /tmp/busybox /tmp/sleep > /dev/null 2>&1
ln -s /tmp/busybox /tmp/expr > /dev/null 2>&1
ln -s /tmp/busybox /tmp/test > /dev/null 2>&1
ln -s /tmp/busybox /tmp/echo > /dev/null 2>&1
ln -s /tmp/busybox /tmp/touch > /dev/null 2>&1

## PATH auf /tmp "biegen", damit keine Kommandos von der Platte geladen werden koennen
## WICHTIG: In allen Scripten, die durch dieses aufgerufen werden PATH explizit wieder "zurückbiegen".
## Andernfalls werden wichtige Kommandos der aufgerufenen Scripte nicht gefunden!!
PATH=/tmp

i=0
touch /tmp/checkmail
echo $$ > /tmp/checkmail
while true; do
 s=`ps | grep imap | grep -v "imap-login" | grep -v "grep imap"`
 if test "$s" != '' ; then
  i=0
  $pfad_getmail > /dev/null 2>&1
  sleep 60
 else
  i=`expr $i + 1`
  sleep 1
  if test `expr $i % 3600` -eq 0 ; then
   i=0
   $pfad_getmail > /dev/null 2>&1
  fi
 fi
done

Eigentlich sind nur Kommandos innerhalb der while Schleife kritisch. Der Rest ausserhalb wird ja nur einmalig aufgerufen.
Geh ich aber richtig mit meiner Vermutung, dass durch das statische Linken der busybox eigentlich keine Files ausserhalb des busybox Binaries benötigt werden?
Ich werde heute abend mal den Webserver temporär zur Testkiste machen und die Sache mit dem Hibernate Debug mal durchprobieren. Leider habe ich ja keine Testkiste mehr seit mir meine DS107+ abgeraucht ist

Danke + Gruss

tobi

p.s. das Kernel Log bei Debug Hibernate ist "einfach" /var/log/messages, oder?

 

[itari]

Es werden, je nach BusyBox-Command weitere Dateien und Libs geöffnet. Mach mal

strings /bin/busybox | grep lib

und schon siehst was. Wenn du mit lsof die offenen Dateien anschaust, dann siehst auch, dass z.B. der inetd (Teil der BusyBox) die /lib/ld.so.1, /lib/libc.so.1 und die /lib/lib_nss_files.so.2 aufgemacht hat.

Ansonsten auch dran denken, dass die Swap-Partition leichten Traffic haben kann (deswegen sollte man den Swap so umkonfigurieren, dass er auch auf einen Stick geht) und auch die Superblöcke und ext3-Journale nicht unbedingt völlig ohne Bewegungen sind.

Itari

PS. recht bequem kannst das mit dem Admin Tool anschauen


Nachtrag: /tmp ist solange im RAM, wie dort Platz dafür ist, ansonsten wird auf die Platte ausgelagert (in den Swap)

 

[jahlives]

@itari
Siehst du denn einen Weg das obige Script komplett aus dem Speicher auszuführen? Einfach /lib nach /tmp zu kopieren würde ja wohl auch nix bringen bei das busybox Binary wohl immer noch die Daten aus /lib holen wird. Da müsste man ja dann busybox neukompillieren für eine /tmp-Version
Nachtragsfrage:
Könnte es sein, dass es bei dem fraglichen User daran scheitert, dass nicht genügend Platz im RAM ist und wie du sagst ausgelagert werden muss? Wäre es dann vielleicht noch ein Versuch wert, das Ganze via einen USB Stick zu erledigen?

 

[itari]

@itari
Siehst du denn einen Weg das obige Script komplett aus dem Speicher auszuführen? Einfach /lib nach /tmp zu kopieren würde ja wohl auch nix bringen bei das busybox Binary wohl immer noch die Daten aus /lib holen wird. Da müsste man ja dann busybox neukompillieren für eine /tmp-Version
Nachtragsfrage:
Könnte es sein, dass es bei dem fraglichen User daran scheitert, dass nicht genügend Platz im RAM ist und wie du sagst ausgelagert werden muss? Wäre es dann vielleicht noch ein Versuch wert, das Ganze via einen USB Stick zu erledigen?

zu 1] Man müsste schauen, ob man alle nicht benötigten Daemonen killen kann (z.B. inetd usw.), weil - so denke ich - man nicht wirklich die BusyBox nachbauen kann, weil da zu viel Synology-Zeugs und -Mods drinne sind. Guck dir alleine die vielen Links von Kommandos auf die BusyBox an.

zu 2] Ein Stick könnte ein erfolgreiche Idee sein.

Itari

 

[jahlives]

zu 1] Man müsste schauen, ob man alle nicht benötigten Daemonen killen kann (z.B. inetd usw.), weil - so denke ich - man nicht wirklich die BusyBox nachbauen kann, weil da zu viel Synology-Zeugs und -Mods drinne sind. Guck dir alleine die vielen Links von Kommandos auf die BusyBox an.

zu 2] Ein Stick könnte ein erfolgreiche Idee sein.

Itari

1) inetd braucht man ja aber, sonst ist nix mit telnet
2) Heisst das busybox und /lib auf den Stick? Wie bringt man aber der busybox bei, dass /lib nun auf dem USB Stick liegt? Geht das ohne Neukompillieren?

 

[itari]

2) Heisst das busybox und /lib auf den Stick? Wie bringt man aber der busybox bei, dass /lib nun auf dem USB Stick liegt? Geht das ohne Neukompillieren?

Könnte man doch mal mit einem (symbolischen) Link probieren. Wenn ich richtig informiert bin, dann liegen die Links (wenn sie kurz sind, direkt in der Inode. Da die Inode-Tabelle ja meist eh im File-System-Buffer (RAM) liegt, könnte es also sein, dass dies keinen wirklichen Plattenzugriff erfordert.

Aber mal was anderes, warum denkst du nicht in Richtung SSD? Du brauchst doch nicht gleich was Riesiges ... so 8-16 GB würden doch schon reichen (16GB = ca 50 Euro)

Itari

 

[jahlives]

Aber mal was anderes, warum denkst du nicht in Richtung SSD? Du brauchst doch nicht gleich was Riesiges ... so 8-16 GB würden doch schon reichen (16GB = ca 50 Euro)

Itari

Daran habe ich auch schon gedacht. Nur wie gesagt kommt bei mir der Hibernate eh nie zum Zuge. Drum konnte ich das auch nie richtig testen, ob es denn mit dem /tmp und Hibernate funzen würde.
Ich probiers heute Abend mal mit einem USB-Stick.
Was ich bei deinem Post noch nicht so ganz begriffen habe ist die Sache mit dem Symbolischen Link. Das Problem scheint ja zu sein, dass busybox je nach angefordertem Kommando noch Daten von der Platte lädt. Daher bin ich davon ausgegangen, dass diese Files hardcodiert irgendwo im Binary stehen würden. Wenn dem so wäre verstehe ich nicht wie genau hier ein SymLink helfen könnte resp wie der SymLink das Wecken der Platten verhindern könnte.

 

[goetz]

Hallo,

Wenn du mit lsof die offenen Dateien anschaust, dann siehst auch, dass z.B. der inetd (Teil der BusyBox) die /lib/ld.so.1, /lib/libc.so.1 und die /lib/lib_nss_files.so.2 aufgemacht hat.

das kann ich so nicht nachvollziehen.

DS-107plus> lsof  -p 1284
COMMAND  PID USER   FD   TYPE DEVICE    SIZE  NODE NAME
inetd   1284 root  cwd    DIR    8,1    4096     2 /
inetd   1284 root  rtd    DIR    8,1    4096     2 /
inetd   1284 root  txt    REG    8,1 1295012 32829 /bin/busybox
inetd   1284 root    0u   CHR    1,3         57681 /dev/null
inetd   1284 root    1u   CHR    1,3         57681 /dev/null
inetd   1284 root    2u   CHR    1,3         57681 /dev/null
inetd   1284 root    3u   CHR   4,65         57356 /dev/ttyS1
inetd   1284 root    4u   CHR  201,0         57829 /dev/synobios

Hast Du nen ipkg inetd?

Gruß Götz

 

[itari]

Synology> ps | grep inetd
 1605 root        604 S   /usr/sbin/inetd
Synology> lsof  -p 1605
COMMAND  PID USER   FD   TYPE DEVICE    SIZE   NODE NAME
inetd   1605 root  cwd    DIR    9,0    4096      2 /
inetd   1605 root  rtd    DIR    9,0    4096      2 /
inetd   1605 root  txt    REG    9,0 1291724 229416 /bin/busybox
inetd   1605 root  mem    REG    9,0   37048  33012 /lib/libnss_files.so.2
inetd   1605 root  mem    REG    9,0 1277616  32866 /lib/libc.so.6
inetd   1605 root  mem    REG    9,0   90220  32813 /lib/ld.so.1
inetd   1605 root    0u   CHR    1,3         295287 /dev/null
inetd   1605 root    1u   CHR    1,3         295287 /dev/null
inetd   1605 root    2u   CHR    1,3         295287 /dev/null
inetd   1605 root    3u   CHR   4,65         295148 /dev/ttyS1
inetd   1605 root    4u   CHR  201,0         295380 /dev/synobios
inetd   1605 root    6u  IPv4   1021            TCP *:telnet (LISTEN)
inetd   1605 root    7u  IPv4   1023            TCP *:swat (LISTEN)

Bei mir sieht es so aus. Bin per telnet drauf ...

Itari

 

[itari]

Wenn dem so wäre verstehe ich nicht wie genau hier ein SymLink helfen könnte resp wie der SymLink das Wecken der Platten verhindern könnte.

Symlink auf die Libs. Wahrscheinlich weise ja die 'eingebauten' Pfade auf die /lib. Um jetzt auf eine Bibliothek zuzugreifen (ohne den eingebauten Pfad ändern zu können, kann doch nur ein Link helfen, der als Platzhalter an der Stelle sitzt, wo die Bibliothek normalerweise steht und von dort auf den neuen Platz der Bibliothek auf deinem Stick weist ... so hatte ich es gemeint. Wenn der Symlink nun eh schon im File-Buffer steht, ist die Wahrscheinlichkeit, dass tatsächlich ein Plattenzugriff erfolgt, geringer.

Itari

 

[jahlives]

Symlink auf die Libs. Wahrscheinlich weise ja die 'eingebauten' Pfade auf die /lib. Um jetzt auf eine Bibliothek zuzugreifen (ohne den eingebauten Pfad ändern zu können, kann doch nur ein Link helfen, der als Platzhalter an der Stelle sitzt, wo die Bibliothek normalerweise steht und von dort auf den neuen Platz der Bibliothek auf deinem Stick weist ... so hatte ich es gemeint. Wenn der Symlink nun eh schon im File-Buffer steht, ist die Wahrscheinlichkeit, dass tatsächlich ein Plattenzugriff erfolgt, geringer.

Itari

Ich habe mir das in etwa so vorgestellt wie du es geschrieben hast: Nur /lib existiert ja bereits, müsste man ja löschen/umbennenen und dann einen SymLink auf /tmp/lib anlegen. Das würde dann ja aber alle Programme beeinflussen und nicht nur das Script selber.

 

[itari]

Ich habe mir das in etwa so vorgestellt wie du es geschrieben hast: Nur /lib existiert ja bereits, müsste man ja löschen/umbennenen und dann einen SymLink auf /tmp/lib anlegen. Das würde dann ja aber alle Programme beeinflussen und nicht nur das Script selber.

Ich würde auch nur die in Frage kommenden Libs verlinken, nicht alles. Ich hab da aber auch keine wirklich bessere Lösung. Neukompilieren der BusyBox kannst vergessen ... es sei denn, du hast eine Quelle mit den von Synology gemachten Änderungen/Erweiterungen.

Itari

 

[jahlives]

Habe mal ein bissl mit lsof rumprobiert. Dabei ist mir aufgefallen, dass ein Problem das su sein muss. Durch su wurde natürlich der folgende Prozess unter der dem User in /etc/passwd zugeordneten Shell ausgeführt. Und die lag natürlich nicht in /tmp
Wobei ich mich allerdings frage ob dies auch den Hibernate aufgehalten haben könnte, denn eigentlich wurde das Kommando ja nur einmal ausgeführt. Alles was innerhalb der Schleife wiederholt aufgerufen wird, zeigt ja nach /tmp.
Zusätzlich zeigte lsof noch den Zugriff auf das Homeverzeichnis des Users gemäss /etc/passwd, wobei ich mich auch hier frage ob hier ein ständiger Zugrff stattfindet oder nur einmal beim Aufruf geprüft wurde ob das User Home überhaupt existiert??
lsof hat mir für den Hauptprozess folgendes ausgespuckt

lsof -p 4077
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
sh      4077 mailman  cwd    DIR    9,2     4096 275546121 /volume1/homes/mailman
sh      4077 mailman  rtd    DIR    9,0     4096         2 /
sh      4077 mailman  txt    REG   0,11  1466720   7512554 /tmp/busybox
sh      4077 mailman    0u   CHR    3,0      0t0    131174 /dev/ttyp0
sh      4077 mailman    1u   CHR    3,0      0t0    131174 /dev/ttyp0
sh      4077 mailman    2u   CHR    3,0      0t0    131174 /dev/ttyp0
sh      4077 mailman   10u   CHR    5,0      0t0    131295 /dev/tty

eigentlich könnten ja nur die ersten 2 Einträge als Übeltäter in Frage kommen. Das Script selber habe ich als angemeldeter User mailman (also ohne su) so gestartet

/tmp/sh /path/to/script

Zusätzlich in /etc/passwd dem User mal als Shell noch /tmp/sh vorgesetzt. Oder ist das doppelt-gemoppelt weil /tmp/sh script die zu verwendende Shell ja eigentlich bereits vorgibt?

 

[jahlives]

Nach einem Test auf meiner DS107+ bei dem ich alle Dienste beendet habe glaube ich den Schuldigen zu haben: In den Logs taucht mit hibernate_debug (danke @ goetz für en Tipp) immer das Kommando ps auf, welches auf /etc/nsswitch.conf zugreift. Habe das File mal nach /tmp kopiert, in /etc umbenannt und in /etc einen Symlink auf /tmp/nsswitch.conf gesetzt. Mit dem Ergebnis, dass in den Logs immer noch die gleiche Meldung auftaucht.