Rechner nicht mehr arbeitsfähig wegen hoher Plattenaktivität
N'Abend, vielleicht kann mir mal jemand einen Hinweis geben. Folgendes Problem: Es kommt hin und wieder vor, dass der Rechner (Opensuse 11.0 (x86_64)) für mehr als eine Stunde nicht mehr arbeitsfähig ist, weil der aus irgendeinem Grund auf der Platte herumrödelt. Das ist so problematisch, dass jedesmal ein Loginversuch auf der Konsole wegen des 60 Sekunden-Limits abbricht, dass man sich nicht mal mehr dort anmelden kann, um den Rechner herunterzufahren. Da hilft dann nur noch ein Strg+Alt+Entf. Ist das Problem bekannt? Ich meine in Erinnerung zu haben, dass dort irgendein Daemone die Aktivität verursacht. Wenn ich mich richtig erinnere war das kswapd. Der Rechner ist ein AMD Atholon 64 mit 2GB Hauptspeicher und 160 GB SATA HD. fdisk -l Platte /dev/sda: 250.0 GByte, 250059350016 Byte 255 Köpfe, 63 Sektoren/Spuren, 30401 Zylinder Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes Disk identifier: 0xc82cd17e Gerät boot. Anfang Ende Blöcke Id System /dev/sda1 * 1 10199 81923436 7 HPFS/NTFS /dev/sda2 10200 10201 16065 c W95 FAT32 (LBA) /dev/sda3 10202 12812 20972857+ c W95 FAT32 (LBA) /dev/sda4 12813 30401 141283642+ f W95 Erw. (LBA) /dev/sda5 12813 13074 2104483+ 82 Linux Swap / Solaris /dev/sda6 13075 15685 20972826 83 Linux /dev/sda7 15686 23518 62918541 83 Linux /dev/sda8 23519 26129 20972826 83 Linux /dev/sda9 26130 27435 10490413+ 83 Linux /dev/sda10 27436 30401 23824363+ 83 Linux df Dateisystem 1K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/sda6 20641788 13286604 6306544 68% / udev 964944 136 964808 1% /dev /dev/sda8 20641788 14597788 4995360 75% /home /dev/sda9 10325748 249376 9551852 3% /srv /dev/sda7 61931268 28563716 30221628 49% /usr /dev/sda1 81923432 34614492 47308940 43% /windows/C /dev/sda3 20962592 11824320 9138272 57% /shared /dev/sda10 23450036 22227276 31544 100% /srv/ftp Gruss, Oliver Block -- 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
Oliver Block wrote:
N'Abend,
vielleicht kann mir mal jemand einen Hinweis geben. Folgendes Problem: Es kommt hin und wieder vor, dass der Rechner (Opensuse 11.0 (x86_64)) für mehr als eine Stunde nicht mehr arbeitsfähig ist, weil der aus irgendeinem Grund auf der Platte herumrödelt. Das ist so problematisch, dass jedesmal ein Loginversuch auf der Konsole wegen des 60 Sekunden-Limits abbricht, dass man sich nicht mal mehr dort anmelden kann, um den Rechner herunterzufahren. Da hilft dann nur noch ein Strg+Alt+Entf.
Ist das Problem bekannt?
Ich meine in Erinnerung zu haben, dass dort irgendein Daemone die Aktivität verursacht. Wenn ich mich richtig erinnere war das kswapd.
Vielleicht beagle oder updatedb. Gehe mal alle deine Cronjobs durch, ob dort der Schuldige dabei ist. Helfen würde es schon, wenn du wüsstest, ob diese Zeiten immer die gleichen sind oder zu wechselnden Zeiten. Eine andere Richtung ist die Überwachung der IO-Aktivität mit sar und der Prozesse mit top. Logge die Aktivität in eine Datei und schaue später nach, was für Prozesse sich zu der Zeit der Plattenprügelei ausgetobt haben. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@)drobic (.) de -- 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
Hallo, Am Mittwoch, 17. Juni 2009 schrieb Sandy Drobic:
Oliver Block wrote:
N'Abend,
vielleicht kann mir mal jemand einen Hinweis geben. Folgendes Problem: Es kommt hin und wieder vor, dass der Rechner (Opensuse 11.0 (x86_64)) für mehr als eine Stunde nicht mehr arbeitsfähig ist, weil der aus irgendeinem Grund auf der Platte herumrödelt. Das ist so problematisch, dass jedesmal ein Loginversuch auf der Konsole wegen des 60 Sekunden-Limits abbricht, dass man sich nicht mal mehr dort anmelden kann, um den Rechner herunterzufahren. Da hilft dann nur noch ein Strg+Alt+Entf.
Ist das Problem bekannt?
Ich meine in Erinnerung zu haben, dass dort irgendein Daemone die Aktivität verursacht. Wenn ich mich richtig erinnere war das kswapd.
Vielleicht beagle oder updatedb. Gehe mal alle deine Cronjobs durch, ob dort der Schuldige dabei ist. Helfen würde es schon, wenn du wüsstest, ob diese Zeiten immer die gleichen sind oder zu wechselnden Zeiten. beagle oder updatedb sind zwar nervig, aber normalerweise (bei intakter Platte) dürften die ein System nicht so lahmlegen (die haben normalerweise nicht die Priorität dafür), dass eine Anmeldung an der Konsole scheitert - es sei denn, dass dabei auch soviel RAM verbraten wird, dass kräftig ausgelagert werden muss. Und wenn nach obiger Beschreibung tatsächlich der kswapd so aktiv war, klingt das doch sehr nach swap-Aktivitäten.
Ich würde dafür allerdings auch top (oder im Grafikmodus KDE-Systemüberwachung und zuerst xosview) empfehlen, um den Übeltäter zu ermitteln, der da soviel Speicher frisst. Gruß Martin -- 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
Moin, On Wed, 17 Jun 2009, 23:20:10 +0200, Martin Hofius wrote:
Hallo,
Am Mittwoch, 17. Juni 2009 schrieb Sandy Drobic:
Oliver Block wrote:
N'Abend,
vielleicht kann mir mal jemand einen Hinweis geben. Folgendes Problem: Es kommt hin und wieder vor, dass der Rechner (Opensuse 11.0 (x86_64)) für mehr als eine Stunde nicht mehr arbeitsfähig ist, weil der aus irgendeinem Grund auf der Platte herumrödelt. Das ist so problematisch, dass jedesmal ein Loginversuch auf der Konsole wegen des 60 Sekunden-Limits abbricht, dass man sich nicht mal mehr dort anmelden kann, um den Rechner herunterzufahren. Da hilft dann nur noch ein Strg+Alt+Entf.
Ist das Problem bekannt?
Ich meine in Erinnerung zu haben, dass dort irgendein Daemone die Aktivität verursacht. Wenn ich mich richtig erinnere war das kswapd.
Vielleicht beagle oder updatedb. Gehe mal alle deine Cronjobs durch, ob dort der Schuldige dabei ist. Helfen würde es schon, wenn du wüsstest, ob diese Zeiten immer die gleichen sind oder zu wechselnden Zeiten. beagle oder updatedb sind zwar nervig, aber normalerweise (bei intakter Platte) dürften die ein System nicht so lahmlegen (die haben normalerweise nicht die Priorität dafür), dass eine Anmeldung an der Konsole scheitert - es sei denn, dass dabei auch soviel RAM verbraten wird, dass kräftig ausgelagert werden muss. Und wenn nach obiger Beschreibung tatsächlich der kswapd so aktiv war, klingt das doch sehr nach swap-Aktivitäten.
Ich würde dafür allerdings auch top (oder im Grafikmodus KDE-Systemüberwachung und zuerst xosview) empfehlen, um den Übeltäter zu ermitteln, der da soviel Speicher frisst.
ich war bislang auch immer davon ausgegangen, dass da ein Speicherfresser am Werke ist... dem scheint aber nicht (unbedingt) so zu sein. In Anlehnung an ein Anwenderszenario, in dem ein grosser Prozess (braucht also viel Speicher) laeuft, der in Echtzeit Simulationsdaten berechnet und grafisch rendert, waehrenddessen andere, bereits berechnete Dateien (die ebenfalls sehr gross sind) wegkopiert werden sollen, habe ich das mal in unterschiedlichen Setups wie folgt nachvollzogen: 1. Hauptspeicher auf 2GB beschraenkt (mem=2G) 2. Eine 16 GiB grosse Datei erzeugt 3. Diese Datei wird per "cp -va src dst" kopiert 4. 45 Sekunden, nachdem der Kopiervorgang gestartet wurde, versuche ich, einen Firefox zu starten; danach werden weitere Prozesse gestartet. Als Ergebnis muss man leider feststellen, dass im Default-Setup (openSUSE-11.1, XFS oder ext3 spielen keine Rolle - ausser dass das Kopieren auf dem ext3 30-50% langsamer ist, single Disk oder MD-raid10 aendern auch nichts an der grundsaetzlichen Charakteristik) das System nach dem Starten des Kopierens annaehernd unbenutzbar wird. So dauert es ueber eine Minute, bis der Firefox da ist... Wenn man den Kopiervorgang per "ionice -c3 cp -va src dst" laufen laesst, ist Firefox bereits nach 18 Sekunden da. Das Haessliche an "ionice" ist aber, dass ueber den Desktop gestartete Kopiervorgaenge nur nachtraeglich mit "ionice -c3 -p pid" ueber die Kommandozeile eingefangen werden koennen. Wenn man aber den Default-Elevator von "cfq" auf "deadline" stellt, hat man voellig ohne Aufwand ploetzlich ein benutzbaren System; man verliert kaum I/O Performance, gewinnt aber deutlich an Interaktion bei solchen I/O intensiven Jobs. Auch hier war der Firefox bereits nach 18 Sekunden da. Ich denke, dass alle Desktops oder sonstigen Systeme, bei denen eine gewisse Interaktion gefordert ist (ich wuerde einen Webserver z.B. durchaus dazu zaehlen), aktuell mit dem "deadline" Elevator viel besser funktionieren (und werde das auch intern bei Novell/SUSE propagieren); der "cfq" hat entweder einen richtig dicken Bug, oder er funktioniert eben nur richtig gut mit den ganz dicken DB oder sonstigen Workloads. Ach ja, zwischen den verschiedenen Testlaeufen habe ich natuerlich immer wieder aufgeraeumt: sudo swapoff -va sudo swapon -va sudo /bin/sh -c 'echo 3 > /proc/sys/vm/drop_caches' Damit sollten die Ausgangsvoraussetzungen fuer die Laeufe zumindest annaehernd identisch gewesen sein. Probiert's mal aus, indem ihr beim Booten den Default-Elevator per elevator=deadline setzt; kann natuerlich zum Testen auch zur Laufzeit des Systems per echo deadline > /sys/block/DRIVE/queue/scheduler fuer jedes DRIVE einzeln umgeschaltet werden; mit cat /sys/block/DRIVE/queue/scheduler koennt ihr euch den aktuellen Elevator von DRIVE ansehen. HTH, cheers. l8er manfred -- 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
On 18.06.2009, Manfred Hollstein wrote:
1. Hauptspeicher auf 2GB beschraenkt (mem=2G) 2. Eine 16 GiB grosse Datei erzeugt 3. Diese Datei wird per "cp -va src dst" kopiert 4. 45 Sekunden, nachdem der Kopiervorgang gestartet wurde, versuche ich, einen Firefox zu starten; danach werden weitere Prozesse gestartet.
Mit dem Erzeugen einer 16 GB Datei erzeugst du auch gleichzeitig massiven I/O. Dafuer ist ext3 nur bedingt ausgelegt.
Als Ergebnis muss man leider feststellen, dass im Default-Setup (openSUSE-11.1, XFS oder ext3 spielen keine Rolle
Die Betonung liegt auf "default setup".
Wenn man aber den Default-Elevator von "cfq" auf "deadline" stellt, hat man voellig ohne Aufwand ploetzlich ein benutzbaren System; man verliert kaum I/O Performance, gewinnt aber deutlich an Interaktion bei solchen I/O intensiven Jobs. Auch hier war der Firefox bereits nach 18 Sekunden da.
Nach 18 sekunden? Das ist ja unertraeglich!
Ich denke, dass alle Desktops oder sonstigen Systeme, bei denen eine gewisse Interaktion gefordert ist (ich wuerde einen Webserver z.B. durchaus dazu zaehlen), aktuell mit dem "deadline" Elevator viel besser funktionieren (und werde das auch intern bei Novell/SUSE propagieren); der "cfq" hat entweder einen richtig dicken Bug, oder er funktioniert eben nur richtig gut mit den ganz dicken DB oder sonstigen Workloads.
Dieses Thema wurde vor ca. 2 Monaten intensivst auf der lkml diskutiert, und ich habe selber mit Benchmarks und Tests beigetragen. CFQ hat so einige sehr performante Updates erfahren, die man allerdings mit den "veralteten" Distributions Kernen nicht mitbekommt. Ausserdem liegt das Hauptproblem am Filesystem.
elevator=deadline
Der dl Scheduler hat einige richtig dicke Bremsen, bei unbelastetem Betrieb setzt er naemlich die Latenz enorm hoch. Wiederhole doch deinen Versuch bitte nochmal, wenn du alle beteiligten ext3 Partitionen vorher mittels mount -o rw,noatime,data=writeback gemountet und den Kernel auf 2.6.30 upgedatet hast (mit cfq). Ich habe noch irgendwo den fsync-tester von Theodore Tso auf der Platte, den kann ich dir fuer solche Zwecke gerne raussuchen, wenn du willst. Ich selber benutze xfs und habe keine Latenz-Probleme :-) -- 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
On Fri, 19 Jun 2009, 11:43:56 +0200, Heinz Diehl wrote:
On 18.06.2009, Manfred Hollstein wrote:
1. Hauptspeicher auf 2GB beschraenkt (mem=2G) 2. Eine 16 GiB grosse Datei erzeugt 3. Diese Datei wird per "cp -va src dst" kopiert 4. 45 Sekunden, nachdem der Kopiervorgang gestartet wurde, versuche ich, einen Firefox zu starten; danach werden weitere Prozesse gestartet.
Mit dem Erzeugen einer 16 GB Datei erzeugst du auch gleichzeitig massiven I/O. Dafuer ist ext3 nur bedingt ausgelegt.
Unter Anderem deshalb benutze ich standardmaessig auch nur XFS, aber viele Leute wollen/muessen leider mit den Defaults leben...
Als Ergebnis muss man leider feststellen, dass im Default-Setup (openSUSE-11.1, XFS oder ext3 spielen keine Rolle
Die Betonung liegt auf "default setup".
Yep.
Wenn man aber den Default-Elevator von "cfq" auf "deadline" stellt, hat man voellig ohne Aufwand ploetzlich ein benutzbaren System; man verliert kaum I/O Performance, gewinnt aber deutlich an Interaktion bei solchen I/O intensiven Jobs. Auch hier war der Firefox bereits nach 18 Sekunden da.
Nach 18 sekunden? Das ist ja unertraeglich!
Wohl gemerkt, waehrend des Kopierens; normalerweise ist Firefox frisch gestartet bei mir nach ca. 8 Sekunden da, was auch eher sehr schlecht ist, aber da hatten wir ja auch schon diverse Threads...
Ich denke, dass alle Desktops oder sonstigen Systeme, bei denen eine gewisse Interaktion gefordert ist (ich wuerde einen Webserver z.B. durchaus dazu zaehlen), aktuell mit dem "deadline" Elevator viel besser funktionieren (und werde das auch intern bei Novell/SUSE propagieren); der "cfq" hat entweder einen richtig dicken Bug, oder er funktioniert eben nur richtig gut mit den ganz dicken DB oder sonstigen Workloads.
Dieses Thema wurde vor ca. 2 Monaten intensivst auf der lkml diskutiert, und ich habe selber mit Benchmarks und Tests beigetragen. CFQ hat so einige sehr performante Updates erfahren, die man allerdings mit den "veralteten" Distributions Kernen nicht mitbekommt. Ausserdem liegt das Hauptproblem am Filesystem.
Ich weiss.
elevator=deadline
Der dl Scheduler hat einige richtig dicke Bremsen, bei unbelastetem Betrieb setzt er naemlich die Latenz enorm hoch.
Wiederhole doch deinen Versuch bitte nochmal, wenn du alle beteiligten ext3 Partitionen vorher mittels
mount -o rw,noatime,data=writeback
gemountet und den Kernel auf 2.6.30 upgedatet hast (mit cfq).
Den Test mit "noatime,data=writeback" habe ich gemacht, wodurch die Responsiveness zwar (etwas) besser wurde, dafuer aber die Zeit fuers Kopieren erstaunlicherweise deutlich laenger wurde... Ich kann Kernels (leider) nicht beliebig wechseln, stimme dir aber sehr wohl zu, dass mit einem 2.6.30 dieses Szenario wahrscheinlich besser laufen wuerde; ich habe aber auch lange genug selber entwickelt, um zu wissen, dass mit jeder neuen Version oftmals in anderen Bereichen dann wieder etwas verschlimmbessert wurde... Im Produktiveinsatz gibt es aber Gruende (Applikationszertifizierungen etc.), warum das eben nicht geht. Den Upgrade auf 2.6.30 werde ich dann machen, wenn er auf meinen ansonsten produktiv genutzten Systemen moeglich sein wird, soll heissen, dann, wenn's ihn in einem offiziell gewarteten Zustand in einem SLES geben wird, also wohl eher nie...
Ich habe noch irgendwo den fsync-tester von Theodore Tso auf der Platte, den kann ich dir fuer solche Zwecke gerne raussuchen, wenn du willst.
Ich selber benutze xfs und habe keine Latenz-Probleme :-)
Hmm, auch nicht mit dem cfq, dem 2.6.27.23-0.1 Kernel, und in einem vergleichbaren Anwendungs-Szenario? Cheers. l8er manfred -- 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
On 19.06.2009, Manfred Hollstein wrote: [....] Hier noch einer der Artikel von mir auf der lkml, der auch eine meiner damaligen Benchmarks beinhaltet: http://lkml.org/lkml/2009/4/8/688 -- 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
Hallo, Am Mittwoch, 17. Juni 2009 schrieb Oliver Block:
N'Abend,
vielleicht kann mir mal jemand einen Hinweis geben. Folgendes Problem: Es kommt hin und wieder vor, dass der Rechner (Opensuse 11.0 (x86_64)) für mehr als eine Stunde nicht mehr arbeitsfähig ist, weil der aus irgendeinem Grund auf der Platte herumrödelt. Das ist so problematisch, dass jedesmal ein Loginversuch auf der Konsole wegen des 60 Sekunden-Limits abbricht, dass man sich nicht mal mehr dort anmelden kann, um den Rechner herunterzufahren. Da hilft dann nur noch ein Strg+Alt+Entf.
Ist das Problem bekannt?
Ich meine in Erinnerung zu haben, dass dort irgendein Daemone die Aktivität verursacht. Wenn ich mich richtig erinnere war das kswapd.
Schau' mal nach nepomukservice und -server. Dieser Müll hängt mir auch jedes Mal das System fast auf, bis ich es mehrmals abgeschossen habe. Mal davon abgesehen, dass heutzutage kein Dienst die Festplatte automatisch zu durchsuchen hat ohne dass es augenscheinlich mitgeteilt wird. Da unter openSuSE nicht allzuviel mitgeteilt wird, sollten diese Dienste per default deaktiviert sein und nicht deaktiviert werden müssen. -- gruß Oliver -- 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
Hallo Oliver, Am Donnerstag 18 Juni 2009 schrieb Oliver:
Am Mittwoch, 17. Juni 2009 schrieb Oliver Block:
vielleicht kann mir mal jemand einen Hinweis geben. Folgendes Problem: Es kommt hin und wieder vor, dass der Rechner (Opensuse 11.0 (x86_64)) für mehr als eine Stunde nicht mehr arbeitsfähig ist, weil der aus irgendeinem Grund auf der Platte herumrödelt.
Ist das ein Grafisches System? Fast Stillstände tauchen bei mir leider öfter auf als mir lieb ist, wenn der Konqui sich an irgendeinem Website-Müll (Popups) verschluckt. Wahlweise ist es auch der Akgregator. Manchmal kann ich dann gar nicht mehr arbeiten und komme dann auch nicht mehr aufs System drauf. Wenn ich es rechtzeitig merke, hilft Konqui abschießen, dann kommen hängende, leere Fenster zum Vorschein, denen man auch den Garaus macht. Dann ist Ruhe bis zur nächsten Ekelwebsite mit Werbeangriff. (Auf kde-look war's richtig extrem). Erst vor ein paar Tagen habe ich mein System retten können, in dem ich alle http-kioslaves beendet habe. Da musste ich aber einen Zweitrechner hochfahren, Maus und Tastatur mochten nicht mehr.
Ich meine in Erinnerung zu haben, dass dort irgendein Daemone die Aktivität verursacht. Wenn ich mich richtig erinnere war das kswapd.
Schau' mal nach nepomukservice und -server. Dieser Müll hängt mir auch jedes Mal das System fast auf, bis ich es mehrmals abgeschossen habe.
Beagle! Nepomuk läuft bei mir immer, der hat noch nie gestresst. Ich benutze das Ich-kann-Dateien-kommentieren-Feature des Dophin einfach zu gerne. Ohne Nepomuk geht es nicht.
Mal davon abgesehen, dass heutzutage kein Dienst die Festplatte automatisch zu durchsuchen hat ohne dass es augenscheinlich mitgeteilt wird. Da unter openSuSE nicht allzuviel mitgeteilt wird, sollten diese Dienste per default deaktiviert sein und nicht deaktiviert werden müssen.
Yo. locate installiere ich immer nach. Das landet nicht automatisch auf der Platte. Das hat aber auch noch nie gestresst oder das System so ewig ausgebremst, dass ich es bemerkt hätte. Helga -- ## Technik: [http://de.opensuse.org] ## Politik: [http://www.piratenpartei.de] ## Privat: [http://www.eschkitai.de] -- 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
On Wed, 17 Jun 2009 22:38:10 +0200, Oliver Block
/dev/sda10 23450036 22227276 31544 ====> 100% /srv/ftp
Wenn die Partion zu 100% belegt ist, könnte es doch sein, dass dem System die Luft ausgeht. Versuch doch mal, etwas Platz zu schaffen, vielleicht ändert sich das Verhalten danach. Jürgen -- 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
participants (8)
-
Heinz Diehl -
Helga Fischer -
Juergen Langowski -
Manfred Hollstein -
Martin Hofius -
Oliver -
Oliver Block -
Sandy Drobic