• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Benachrichtigung beim Überschreiten einer Verzeichnisgröße

guelcki

Newbie
Hallo!

Ich möchte ein Skript erstellen, dass mittels eines Cronjobs überprüft, ob bei einem bestimmten Verzeichnis eine festgelegte Größe überschritten wurde.

Mir fehlt komplett der Ansatz, muss dazu aber auch sagen, dass ich relativ wenig Ahnung von der bash habe.

Vielen Dank für die Hilfe
gülcki
 

TomcatMJ

Guru
Hi!
Benutz mal die SuFu hier oder google und such dabei nach "Quota hardlimit softlimit",da solltest du eigentlich fündig werden, denn das ganze geht auch ohne explizites Selbstbau-Script und Cronjob mit SuSE-Bordmitteln :)
Verwaltbar ist sowas recht komfortabel wie auch vieles andere u.a. per Webmin.

Bis denne,
Tom
 
OP
G

guelcki

Newbie
Vielen Dank, ich möchte aber den Platz nicht begrenzen, sondern nur benachrichtigt werden , wenn eine bestimmte Größe überschritten wird.

Geht das?

Vielen Dank
gülcki
 

TomcatMJ

Guru
Klar geht das...Softlimit im jeweiligen Verzeichnis begrenzen und Hardlimit unbegrenzt lassen sowie Nachricht an root bzw. den entsprechenden User aktivieren ...

Bis denne,
Tom
 
A

Anonymous

Gast
Schau mal man du

könnte dann so ungefähr aussehen
Code:
typeset -i SIZE
SIZE=$(du -sk | cut -f1)
if [ $SIZE -gt 500000 ]
then
  echo "größer als 500MB"
else
  echo "kleiner als 500MB"
fi

robi
 

TeXpert

Guru
aber ein Cronjob mit regelmäßigem du-Polling verursacht dann doch mehr Last als das automagische Handling mit quotas...

Wobei die Quotas natürlich nur auf Dateisystemebene vorliegen, d.h. Du musst das spezifische Verzeichnis auf einem eigenen Dateisystem haben.
 
A

Anonymous

Gast
TeXpert schrieb:
aber ein Cronjob mit regelmäßigem du-Polling verursacht dann doch mehr Last als das automagische Handling mit quotas...

Ich glaube ja nicht dass man jede Stunde kontrollieren muss ob seine Verzeichnisse voll sind, einmal am Tag würde da sicherlich vollkommen reichen, bei Rechnern die duchlaufen macht man solche Jobs in den Nachtstunden, und bei Rechnern die täglich gebootet werden starten solche Sachen bei mir gestaffelt ab 30 min. nach dem boot mit einem hohem NICE-Wert.

robi
 

TeXpert

Guru
ja es kommt immer drauf an, was man erreichen will :) wenn es einmal pro Tag oder alle paar Stunden reicht passt das schon,


Allerdings: ich hab noch nicht in den Code von du reingesehen, aber ich vermute, dass "du" Dir auch den Cache kaputt macht... wenn Du also ein großes Verzeichnis scannst kommen zuviele unnötige inodes in den Cache und dass kann die restlichen Apps deutlich benachteiligen. (kann muss nicht)
 
A

Anonymous

Gast
TeXpert schrieb:
Allerdings: ich hab noch nicht in den Code von du reingesehen, aber ich vermute, dass "du" Dir auch den Cache kaputt macht... wenn Du also ein großes Verzeichnis scannst kommen zuviele unnötige inodes in den Cache und dass kann die restlichen Apps deutlich benachteiligen. (kann muss nicht)

Ich hab das jetzt mal versucht und mit sar überwacht, also es gibt schon ein paar Nadelimpulse auf der Grafik auf einigen Indikatoren, aber es normalisiert sich sofort wieder alles nach der Laufzeit.
Ein find hat aber ähnliche Ausschläge. Wenn find oder du einmal durch ist dann sind beim 2 Durchlauf die Ausschläge nur geringfügig kleiner. Habe aber jetzt keine Monsterverzeichnisse getestet sondern 4 ganz normale 5 bis 8GB belegte Devices mit typischen Daten vom Rootverzeichniss aus.

robi
 

TeXpert

Guru
sar kenn ich nicht, was misst das?

Misst das auch die Cache-beeinträchtigung? bei vielen, selten benutzten Dateien kann ein iterieren darüber ein ausgelastetes IO-System ganz schön ins Straucheln bringen.
 
A

Anonymous

Gast
was sar kann hier mal eine 2 Sekunden "Leerlauf"-aktiviät vom System mit Option -A
Code:
Linux 2.6.5-7.108-default (Pingu)       26.07.2005

21:58:40       proc/s
21:58:42         0,00

21:58:40      cswch/s
21:58:42       303,00

21:58:40          CPU     %user     %nice   %system   %iowait     %idle
21:58:42          all      3,00      0,00      0,50      0,00     96,50

21:58:40         INTR    intr/s
21:58:42          sum   1082,00

21:58:40     pgpgin/s pgpgout/s   fault/s  majflt/s
21:58:42         0,00      0,00    222,50      0,00

21:58:40     pswpin/s pswpout/s
21:58:42         0,00      0,00

21:58:40          tps      rtps      wtps   bread/s   bwrtn/s
21:58:42         0,00      0,00      0,00      0,00      0,00

21:58:40      frmpg/s   bufpg/s   campg/s
21:58:42       -21,00      0,00      0,00

21:58:40        IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
21:58:42           lo      0,00      0,00      0,00      0,00      0,00      0,00      0,00
21:58:42         eth0      0,00      0,00      0,00      0,00      0,00      0,00      0,00

21:58:40        IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s
21:58:42           lo      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00
21:58:42         eth0      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00

21:58:40          DEV       tps  rd_sec/s  wr_sec/s
21:58:42       dev2-0      0,00      0,00      0,00
21:58:42       dev1-0      0,00      0,00      0,00
21:58:42       dev1-1      0,00      0,00      0,00
21:58:42       dev1-2      0,00      0,00      0,00
21:58:42       dev1-3      0,00      0,00      0,00
21:58:42       dev1-4      0,00      0,00      0,00
21:58:42       dev1-5      0,00      0,00      0,00
21:58:42       dev1-6      0,00      0,00      0,00
21:58:42       dev1-7      0,00      0,00      0,00
21:58:42       dev1-8      0,00      0,00      0,00
21:58:42       dev1-9      0,00      0,00      0,00
21:58:42      dev1-10      0,00      0,00      0,00
21:58:42      dev1-11      0,00      0,00      0,00
21:58:42      dev1-12      0,00      0,00      0,00
21:58:42      dev1-13      0,00      0,00      0,00
21:58:42      dev1-14      0,00      0,00      0,00
21:58:42      dev1-15      0,00      0,00      0,00
21:58:42       dev7-0      0,00      0,00      0,00
21:58:42       dev7-1      0,00      0,00      0,00
21:58:42       dev7-2      0,00      0,00      0,00
21:58:42       dev7-3      0,00      0,00      0,00
21:58:42       dev7-4      0,00      0,00      0,00
21:58:42       dev7-5      0,00      0,00      0,00
21:58:42       dev7-6      0,00      0,00      0,00
21:58:42       dev7-7      0,00      0,00      0,00
21:58:42       dev3-0      0,00      0,00      0,00
21:58:42       dev9-0      0,00      0,00      0,00
21:58:42       dev8-0      0,00      0,00      0,00
21:58:42      dev22-0      0,00      0,00      0,00

21:58:40    kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
21:58:42         5640    250796     97,80     28988     69388    498052     15988      3,11      5652

21:58:40    dentunusd   file-sz  inode-sz  super-sz %super-sz  dquot-sz %dquot-sz  rtsig-sz %rtsig-sz
21:58:42        36340         0     37787         0      0,00         0      0,00         0      0,00

21:58:40       totsck    tcpsck    udpsck    rawsck   ip-frag
21:58:42          273        14        12         0         0

21:58:40      runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
21:58:42            0        99      0,02      0,05      0,01

Durchschn.:    proc/s
Durchschn.:      0,00

Durchschn.:   cswch/s
Durchschn.:    303,00

Durchschn.:       CPU     %user     %nice   %system   %iowait     %idle
Durchschn.:       all      3,00      0,00      0,50      0,00     96,50

Durchschn.:      INTR    intr/s
Durchschn.:       sum   1082,00

Durchschn.:  pgpgin/s pgpgout/s   fault/s  majflt/s
Durchschn.:      0,00      0,00    222,50      0,00

Durchschn.:  pswpin/s pswpout/s
Durchschn.:      0,00      0,00

Durchschn.:       tps      rtps      wtps   bread/s   bwrtn/s
Durchschn.:      0,00      0,00      0,00      0,00      0,00

Durchschn.:   frmpg/s   bufpg/s   campg/s
Durchschn.:    -21,00      0,00      0,00

Durchschn.:     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
Durchschn.:        lo      0,00      0,00      0,00      0,00      0,00      0,00      0,00
Durchschn.:      eth0      0,00      0,00      0,00      0,00      0,00      0,00      0,00

Durchschn.:     IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s
Durchschn.:        lo      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00
Durchschn.:      eth0      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00

Durchschn.:       DEV       tps  rd_sec/s  wr_sec/s
Durchschn.:    dev2-0      0,00      0,00      0,00
Durchschn.:    dev1-0      0,00      0,00      0,00
Durchschn.:    dev1-1      0,00      0,00      0,00
Durchschn.:    dev1-2      0,00      0,00      0,00
Durchschn.:    dev1-3      0,00      0,00      0,00
Durchschn.:    dev1-4      0,00      0,00      0,00
Durchschn.:    dev1-5      0,00      0,00      0,00
Durchschn.:    dev1-6      0,00      0,00      0,00
Durchschn.:    dev1-7      0,00      0,00      0,00
Durchschn.:    dev1-8      0,00      0,00      0,00
Durchschn.:    dev1-9      0,00      0,00      0,00
Durchschn.:   dev1-10      0,00      0,00      0,00
Durchschn.:   dev1-11      0,00      0,00      0,00
Durchschn.:   dev1-12      0,00      0,00      0,00
Durchschn.:   dev1-13      0,00      0,00      0,00
Durchschn.:   dev1-14      0,00      0,00      0,00
Durchschn.:   dev1-15      0,00      0,00      0,00
Durchschn.:    dev7-0      0,00      0,00      0,00
Durchschn.:    dev7-1      0,00      0,00      0,00
Durchschn.:    dev7-2      0,00      0,00      0,00
Durchschn.:    dev7-3      0,00      0,00      0,00
Durchschn.:    dev7-4      0,00      0,00      0,00
Durchschn.:    dev7-5      0,00      0,00      0,00
Durchschn.:    dev7-6      0,00      0,00      0,00
Durchschn.:    dev7-7      0,00      0,00      0,00
Durchschn.:    dev3-0      0,00      0,00      0,00
Durchschn.:    dev9-0      0,00      0,00      0,00
Durchschn.:    dev8-0      0,00      0,00      0,00
Durchschn.:   dev22-0      0,00      0,00      0,00


Durchschn.: kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
Durchschn.:      5640    250796     97,80     28988     69388    498052     15988      3,11      5652

Durchschn.: dentunusd   file-sz  inode-sz  super-sz %super-sz  dquot-sz %dquot-sz  rtsig-sz %rtsig-sz
Durchschn.:     36340         0     37787         0      0,00         0      0,00         0      0,00

Durchschn.:    totsck    tcpsck    udpsck    rawsck   ip-frag
Durchschn.:       273        14        12         0         0

Durchschn.:   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
Durchschn.:         0        99      0,02      0,05      0,01
so kann das natürlich niemand auswerten aber schau mal hier
http://www.linux-club.de/viewtopic.php?p=194748&highlight=#194748

robi
 

TeXpert

Guru
im Debian-Repository ist es nicht :) aber nach einem kurzen Googeln komme ich hier hin: http://www.computerhope.com/unix/usar.htm und da steht:
ABOUT SAR

Displays the activity for the CPU.
d.h. für mich :) zusammen mit den Daten, dass man leider _nciht_ die Buffer-Veränderung messen kann, das entscheidende ist ja hier nicht, dass es zu einem kurzen CPU-Peak kommt sondern, dass durch den (im Prinzip störenden) Dateidurchlauf andere inodes gecached werden.

aus praktischer Erfahrung: eine rsync-Spiegelung eines ganzen Rechners alle paar Stunden erzeugt eine erhebliche Belastung, nicht wegen der cpu sondern da die anderen Prozesse im Anschluß einen "vermüllten" Filebuffer haben und somit mehr Platten-IO stattfindet. Das kann ich jetzt nicht Quantitativ belegen, zumindest nicht in Abhängigkeit von Last und Dateizahl aber es war qualitativ Signifikant.
 
OP
G

guelcki

Newbie
Schon mal vielen Dank für die Hilfe!

Ich will tatsächlich nur einmal täglich ein Verzeichnis überprüfen (das nicht auf einer eigenen Partitionliegt), in dem auch nicht mehr als 5 Archive liegen. Die Last sollte also nicht sonderlich groß sein.

Ich werde den Code von dir gleich erstmal testen!

gülcki
 
A

Anonymous

Gast
TeXpert schrieb:
aus praktischer Erfahrung: eine rsync-Spiegelung eines ganzen Rechners alle paar Stunden erzeugt eine erhebliche Belastung, nicht wegen der cpu sondern da die anderen Prozesse im Anschluß einen "vermüllten" Filebuffer haben und somit mehr Platten-IO stattfindet. Das kann ich jetzt nicht Quantitativ belegen, zumindest nicht in Abhängigkeit von Last und Dateizahl aber es war qualitativ Signifikant.

bei rsync tar cpio oä werden ja auch die ganze Dateien angefasst zumindestens wenn sie dann letztlich doch transprotiert werden müssen, auch ist hier ein sehr intensives flash vonnöten und es müssen vom remote Host ja auch noch die INODE-Daten zum Vergleich vorliegen( ob das immer ohne irgendwelche Datenblöcke geht, weiß ich nicht), find und du dagegen greifen definitiv nur auf die Direktorydateien zu, um so an die INODE zu kommen. Und wenn so die komplette INODE-tabelle eines Filesystems in den Cache kommt ist mir das sicherlich lieber als wenn da von den letzen 10 mp3 Files die ich gehort habe jeweils noch ein paar Blöcke rumliegen.

robi
 
OP
G

guelcki

Newbie
So, der Code funktioniert schon mal, vielen Dank!

Habe jetzt jetzt noch ein Problem:

Ich möchte über ein Skript eine vorgefertigte Nachricht über einen SMTP Server versenden. Wie mache ich das?

Ich weiß nicht, wie die Konfiguration und der Befehl für die Konsole aussieht. Mit Kmail kann ich ja ganz einfach ein Konto einrichten, das klappt auch hervorragend. Aber mit der Konsole?

Für Hilfe wäre ich sehr dankbar
gülcki
 

TeXpert

Guru
guelcki schrieb:
Ich möchte über ein Skript eine vorgefertigte Nachricht über einen SMTP Server versenden. Wie mache ich das?
lokal einen SMTP einrichten, der entweder nur lokal versendet oder einen anderen Smarthost benutzt (-> Mail-Forum) altiernativ fällt mir da noch mutt mit einer Simplen-SMTP Engine (msmtp, nullmailer, etc) ein -> Mail-Forum


robi schrieb:
bei rsync tar cpio oä werden ja auch die ganze Dateien angefasst zumindestens wenn sie dann letztlich doch transprotiert werden müssen, auch ist hier ein sehr intensives flash vonnöten und es müssen vom remote Host ja auch noch die INODE-Daten zum Vergleich vorliegen( ob das immer ohne irgendwelche Datenblöcke geht, weiß ich nicht), find und du dagegen greifen definitiv nur auf die Direktorydateien zu, um so an die INODE zu kommen. Und wenn so die komplette INODE-tabelle eines Filesystems in den Cache kommt ist mir das sicherlich lieber als wenn da von den letzen 10 mp3 Files die ich gehort habe jeweils noch ein paar Blöcke rumliegen.

wo nimmst Du die Information her? wenn ich mir die Inode-Infos eines Verzeichnisses ansehe, ist die Größe unabhängig von der Größe der enthaltenen Dateien:

Code:
$ mkdir demo
xxxxxx@xxxx:/tmp$ stat demo
  File: ,,demo"
  Size: 6               Blocks: 0          IO Block: 4096   Verzeichnis
Device: fe04h/65028d    Inode: 4293867     Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ xxxxxx)   Gid: ( 1000/ xxxxxx)
Access: 2005-07-27 20:11:12.838465320 +0200
Modify: 2005-07-27 20:11:12.838465320 +0200
Change: 2005-07-27 20:11:12.838465320 +0200
xxxxxx@xxxx:/tmp$ dd if=/dev/urandom of=demo/foo bs=1 count=1
1+0 Datensätze ein
1+0 Datensätze aus
1 bytes transferred in 0,007200 seconds (139 bytes/sec)
xxxxxx@xxxx:/tmp$ stat demo
  File: ,,demo"
  Size: 16              Blocks: 0          IO Block: 4096   Verzeichnis
Device: fe04h/65028d    Inode: 4293867     Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ xxxxxx)   Gid: ( 1000/ xxxxxx)
Access: 2005-07-27 20:11:12.838465320 +0200
Modify: 2005-07-27 20:11:46.363368760 +0200
Change: 2005-07-27 20:11:46.363368760 +0200
xxxxxx@xxxx:/tmp$ dd if=/dev/urandom of=demo/foo bs=1 count=10000
10000+0 Datensätze ein
10000+0 Datensätze aus
10000 bytes transferred in 0,106027 seconds (94316 bytes/sec)
xxxxxx@xxxx:/tmp$ stat demo
  File: ,,demo"
  Size: 16              Blocks: 0          IO Block: 4096   Verzeichnis
Device: fe04h/65028d    Inode: 4293867     Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ xxxxxx)   Gid: ( 1000/ xxxxxx)
Access: 2005-07-27 20:11:12.838465320 +0200
Modify: 2005-07-27 20:11:46.363368760 +0200
Change: 2005-07-27 20:11:46.363368760 +0200
xxxxxx@xxxx:/tmp$ dd if=/dev/urandom of=demo/foo2 bs=1 count=1
1+0 Datensätze ein
1+0 Datensätze aus
1 bytes transferred in 0,007100 seconds (141 bytes/sec)
xxxxxx@xxxx:/tmp$ stat demo
  File: ,,demo"
  Size: 27              Blocks: 0          IO Block: 4096   Verzeichnis
Device: fe04h/65028d    Inode: 4293867     Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ xxxxxx)   Gid: ( 1000/ xxxxxx)
Access: 2005-07-27 20:11:12.838465320 +0200
Modify: 2005-07-27 20:12:08.332029016 +0200
Change: 2005-07-27 20:12:08.332029016 +0200
xxxxxx@xxxx:/tmp$ dd if=/dev/urandom of=demo/foo2 bs=1 count=10000
10000+0 Datensätze ein
10000+0 Datensätze aus
10000 bytes transferred in 0,102647 seconds (97421 bytes/sec)
xxxxxx@xxxx:/tmp$ stat demo
  File: ,,demo"
  Size: 27              Blocks: 0          IO Block: 4096   Verzeichnis
Device: fe04h/65028d    Inode: 4293867     Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ xxxxxx)   Gid: ( 1000/ xxxxxx)
Access: 2005-07-27 20:11:12.838465320 +0200
Modify: 2005-07-27 20:12:08.332029016 +0200
Change: 2005-07-27 20:12:08.332029016 +0200

ergo muss du die inodes _aller_ Dateien betrachten damit müssten alle inodes betrachtet werden und der Cache ist im Arsch.

Wenn rsync nichts übertragen muss (beide Dirs sind sync) dann reichen dafür auch die inode-infos, d.h. ich muss lokal auch die Inodes der Files betrachten und habe die gleiche Situation.
 
Oben