Festplatte abschalten

22 Jul 2007

Am Samstag, 28. Juli 2007 schrieb David Haller:
> Hallo,
>
> Am Fre, 27 Jul 2007, gooly@gmx.at schrieb:
> >Am Donnerstag, 26. Juli 2007 schrieb David Haller:
> >> Am Mit, 25 Jul 2007, gooly@gmx.at schrieb:
> >> [..]
>
> Du weißt aber schon, was "bzw." bedeutet? sysctl zu verwenden ist
> jedenfalls besser.
ok, ich hatte es von der Web-Seite dessen der laptop_mode entwickelt hat 
und habe damit dann mir geholt, was ich brauchte..
>
> >> Mit perl besser:
> >>
> >> ====
> >> open(PROC, ">/proc/sys/vm/block_dump") or die "$!\n";
> >> print PROC 1;
> >> close(PROC) or die "$!\n";
> >> ====
> >>
> >> system sollte man eher vermeiden
> >
> >warum?
> >
> >> und wenn doch sollte man den Rückgabewert auswerten!
>
>                                 ^^^^^^^^^^^^^^^^^^^^^^
>
> Einen weiteren Prozess zu starten ist langsam und unnötig.
Tja, nicht immer. Hab auch so gedacht, aber, nachdem mir ein Programm 
mit dem Perl-Thread-Paket einfach mal so auffhörte zu arbeiten (ohne 
crash, ohne Fehler ohne Kommentar, es stand einfach still), erhielt ich 
dazu als Antwort: "Ja, kann passieren, wenn einer der threads stark 
belastet wird", und es gäbe zwar den yield-command, aber wirklich zu 
empfehlen sei der auch nicht, weil ..
Also, alles was geht hab ich jetzt 'rausgebracht'.
>
> Generell:
>
> Es öffnet eine Sicherheitslücke, wenn man nicht 100% selber festlegt,
> was per system ausgeführt wird. D.h. system mit einem Kommando, das
> von "aussen" beeinflußt werden kann (Argumente wie z.B. auch
> Dateinamen), aufzurufen ist eine Sicherheitslücke.
>
> Besonders wenn system ein String und keine Liste übergeben wird, dann
> wird eine Shell gestartet die Wildcards und anderes im Übergebenen
> String auswertet...
Ahh, das meinst Du, aber auf meinem pc arbeite nur ich, es sei denn er 
wird gestohlen, ...
>
> >> >Perl:
> >> >	system ( "dmesg |grep READ  >$f   2>&1");
> >>
> >> *urgsl*
> >
> >warum?
>
> Gleiche Gründe wie oben.
>
> >> ====
> >> open(DMESG, "dmesg |") or die "$!\n";
> >> print grep( /READ|WRITE/, <DMESG>);
> >> close(DMESG) or die "$!\n";
> >> ====
> >
> >und warum ist das besser?
>
> Siehe oben.
>
> >Ich brauch nur eine Zeile, Du 3;
>
> Also _das_ ist wirklich das dümmste "Argument", was ich bisher von
> dir gelesen habe. 
Bitte? Ein Programm mit 65 Zeile (ca. 1 Din A 4 Seite) ist weit aus 
besser lesbar und schneller handhabbar als des Gleich auf 3 Seiten mit 
fasat 200 Zeilen ..

> Aber bitte, sogar mit Fehlerbehandlung was du nicht 
> machst:
> open(D,"dmesg|") or die; print grep( /READ|WRITE/, <D>); close(D) or
> die;
Naja.
>
> >Perl gibt Speicher nicht wirklich wieder her,
> >ich hab daher alles 'externalisiert' und der Speicher ist dann
> > wieder frei..
>
> Und _das_ ist das zweitdümmste "Argument".
Widerspruch.
> Perl verwendet intern den Speicher wieder.
hmm, manchmal ja, manchmal nein!
Hier ein Bispiel der Wiener Perl-Liste. Obwohl nur eine richtige ($s) 
und eine interne ($_) gibt, steigt der Speicherverbrauch an und an und 
an, bis zur Schleife, dann bleibt er konstant (hoch) - der Speicher 
wurde (erstmal) nicht wiederverwendet..

#!/usr/bin/perl
use warnings;
use strict;

my $s;
print "me:$$\n";
   # A
   $s = "A" x 10_000_000;
   print "A\n";
   sleep 10;
   $s = "x";
   print "x\n";
   sleep 10;
   # B
   $s = "B" x 10_000_000;
   print "B\n";
   sleep 10;
   $s = "x";
   print "x\n";
   sleep 10;

   # C
   $s = "C" x 10_000_000;
   print "C\n";
   sleep 10;
   $s = "x";
   print "x\n";
   sleep 10;
   # [ ... ]
# bis hier wird steigt der Speicherverbrauch immer weiter an jedesmal 
# ab hier ist der verbrauchte Speicher dann konstant (hoch):

for ('A' .. 'Z') {
   $s = $_ x 10_000_000;
   print "$_\n";
   sleep 10;
   $s = "x";
   print "x\n";
   sleep 10;
}
# beobachtar mit top -p ProgID
>
> >Dies File kann sehr groß werden und das Programm soll quasi ewig
> >laufen..
>
> Dann kann man das anpassen. Aber du verrätst ja keine Details, wie
> die zu verarbeitende Ausgabe von dmesg aussieht, was du damit machen
> willst etc.
Stand weiter oben im thread, herausfinden welches Programm war die 
Ursache, dafür dass die Platte 'hoch' kam.
>
> [..]
>
> >> >if ( -s $f > 10 ) {
> >>
> >> Wieso 10 Byte?
hat sich irgendwann mal so ergeben..
> >>
> >> >   open F, "< $f" or warn "Can't open READ_File:$f< :$!\n";
> >>
> >> Du liest aber trotzdem? *waaah*
und? 
Das erzeugt in Perl eine Warn-Meldung (use warnings;) aber das Prg läuft 
weiter bis zum Ende:
	open F, '-|','./myPrg.pl' or die "can't start Foxi: $!\n"; 
	my $n = 0;
	while ( defined (my $l = <F>) ) {
	      print "test: $n\t".$l;
	      last if ($n++ >= 5);
	   } 
	   close(F);
	   sleep 1;
	   print "NOW, read on closed handle..\n";
	   my $l = <F>;
	   print "und  >$l<\n\t done\n";
	print "bye\n";
	exit 0;

NOW, read on closed handle..
readline() on closed filehandle F at ./test.pl line 15.
Use of uninitialized value in concatenation (.) or string at ./test.pl 
line 16.
und  ><
         done
bye


> >
> >Naja, lesen geht doch nicht und Perl erzeugt eine Fehlermeldung,
> > aber dies Programm und seine Kinder laufen weiter, nur das
> >hd-Aufwachdebugging funktioniert halt nicht. Klar, nicht schön, aber
> >möglich und funktioniert.
>
> Tolle Ansicht. Arbeitest du in Redmond?
Wieso, ach SuSe Linux kommt jetzt auch aus Redmont?
Jetzt verstehe die viele Fehler und Probleme: 
- 10.0, 10.1, 10.2,
- KDEwallet, speicherte plötzlich nicht mehr die neuen Schlüssel, 
- nach update auf 9.3 funktieniert plötzlich der Sound nicht mehr, und 
- die Micros waren dabei ein extra Problem, 
- wenn ich die aktuelle KDE-Sitzung beenden will muss ich das immer
	zweimal machen, das erstemal werd ich immer wieder gleich 
	eingeloggt, das zweite Mal dann nich??

Versteh(t) mich nicht falsch, ich will auf keinen Fall Linux oder gar 
die Leute, die daran arbeiten schlecht machen, im Gegenteil, aber Dein 
Vergleich mit Redmond ist nicht wirklich mehr aktuell.
>
> >> >   foreach (<F>) {   $show{READ}{"$1_$3"} = "$2 $3\t$1\n"  if
> >> > (/^(.+?): (.+?)(hda[23])[\n\r]*/) }
> >> >   close(F);
> >> >}
>
> Hier liest du die Datei, egal ob sie geöffnet werden konnte oder
> nicht. Was soll der Mist?
Perl fängt das ab, das 'Feature' ist halt nicht da, aber das Programm 
läuft weiter und das ist das was mir wichtig ist!
>
> [..]
>
> >> *urgsl* Ich block da nicht durch, v.a. was du da eigentlich machen
> >> willst, daher nur "in grob".
> >
> >Ich will ja nur wissen welche Programme durch READ oder WRITE die hd
> >aufgeweckt haben ergo brauch ich sie nur einmal und nicht jedesmal
> > mit jedem Knötchen den sie gelesen oder geschrieben haben: Perls
> > Hash.
>
> S.o. Wie sieht die Ausgabe aus? Was willst du damit anstellen?
Aussehen: 
In jeder Zeile steht ein Programmname, der für der up-spin der hd 
verantwortlich sein könnte, im File steht jeder Programmname nur einmal 
bzüglich READ und WRITE.


Grund: 	Welche Programme verursachen das spinup der hd
Konsequenz: Das verhindern!
   a)  durch zB noatim und commit, 
   b) Prg.-Aufe zeitl. verlegen, dann wenn hd ist up.
   c) durch einen Aufruf dieser Programme - solange die hd 'oben'
       ist - diese in den chache holen, dann verursacht der Aufruf
       spinup.

>
> >> ====
> >> open(DMESG, "dmesg |") or die "$!\n";
> >> while(<DMESG>) {
> >>     next unless /READ|WRITE/;
> >>     if (/(.+?):(.+?)(hda[23])[\n\r]*/) {
> >>         print "hd:  $2 $3\t$1\n";
> >>     }
> >> }
> >> close(DMESG) or die "$!\n";
> >> ====
> >
> >Puuhh, so bekam ich 100.000 Einträge vom pdflush und kjournald..
>
> Ich hab dein Gewurstel nicht genauer analysiert und eben kein Hash
> verwendet um die Einträge zu "filtern". Aber das ist ja trivial zu
> beheben. Je nachdem was man machen will mit unterschiedlichen
> Varianten. Aber ich rate jetzt nicht weiter.
Dann einen schönen Sonntag,
Calli

-- 
Um die Liste abzubestellen, schicken Sie eine Mail an:
    opensuse-de+unsubscribe@opensuse.org
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@opensuse.org

Walter Müller

Sandy Drobic

Walter Müller

Sandy Drobic

Walter Müller

David Haller

gooly＠gmx.at

Walter Müller

gooly＠gmx.at

Walter Müller

Andre Tann

gooly＠gmx.at

David Haller

gooly＠gmx.at

David Haller

gooly＠gmx.at

tags

participants (5)