29 Jul
2007
29 Jul
'07
12:55
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/,); > >> 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/, ); 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 = ) ) { print "test: $n\t".$l; last if ($n++ >= 5); } close(F); sleep 1; print "NOW, read on closed handle..\n"; my $l = ; 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 ( ) { $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( ) { > >> 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