SystemError

Moin, also Linux kann NTFS Dateisysteme lesen: http://lists.debian.org/debian-laptop/2004/12/msg00127.html Imho muesste es eigentlich möglich sein aus der Sarge virtuellen Maschine heraus eine NTFS Partition (ReadOnly!) auf dem Win2K GastSystem zu mounten. Könnte aber problematisch werden weil die entsprechende Partition ja 2 mal gemounted wird und ich nicht weiss ob sich das mit Deiner VMSoftware verträgt. ... Bye SystemError

*autsch* Natürlich haben auch die von mir weiter oben genannten Tools strenggenommen nix mit Ethernet sondern mit TCP/IP zu tun. Bye SystemError

Heya, also mir fallen da noch die folgenden 3 kleinen Helferlein ein: - tcpdump, dump traffic on a network - ethereal, a GUI network protocol analyzer - nmap, a network exploration tool and security scanner Allesamt sehr nützlich. Bye SystemError

Moin, verlege mich jetzt einfach mal von wegen OffTopic und so auf PMs. Bye SystemError

Hey, Tivoli ja. Candle nein. Monitoring und Reportingsysteme sind einer meiner Interessensschwerpunkte; bin also für Anregungen auf dem Gebiet immer dankbar. Bye SystemError

Moin, den RHEL 3.0 wollte ich nicht schlecht machen. Schliesslich werden zur Zeit RHEL 2.1, 3.0 und 4.0 von RedHat supported. Wollte nur auf aktuelle Patches für den RHEL 3.0 hinweisen. Apropos Monitoring: Darf ich fragen welche Monitoringsoftware ihr einsetzt? Nur so aus Neugier. Bye SystemError

Der "DB2 Fault Monitor Coordinator" sorgt dafür dass eine Instanz, sollte Sie nicht ordnungsgemäß mit "db2stop" beendet worden sein, sofort neu gestartet wird. Sprich: Stürzt Deine DB2 Instanz ab dann startet der db2fmcd diese sofort nach. Auf Deine Datenbankanwendungen kann das Ding also gar keinen Einfluss haben. Wenn Du mich fragst kann ich darauf aber getrost verzichten, weil: - Meine Instanzen gefälligst nicht abzustürzen haben - Ich das Ding auf HACMP Systemen oder ähnlichen Clusterprodukten sowieso abschalten muss Ich hatte das Ding damals bei einem ganz ähnlichen Problem nach Rücksprache mit dem IBM UDB Support deaktiviert. Ich würde Dir jetzt aber trotzdem empfehlen einen PMR bei IBM auf zu machen sollte es sich bei Deiner Kiste um ein Produktivsystem handeln. Die Frage die Du Dir jetzt nur stellen musst ist: Wie bekommst Du mit wenn eine Deiner DB2 Instanzen dann doch mal abstürzt? Monotoringsoftware oder so? Ach ja, Stichwort RHEL 3.0: Ich würde dringenst empfehlen einen "halbwegs" aktuellen Patchstand in Verbingung mit DB2 zu verwenden. Bye SystemError Quelle:http://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0008221.htm

Hmmm... *strange* dachte eigentlich das wäre ein Bug in früheren FixPacks gewesen. *anyways* Du kannst den "DB2 Fault Monitor" auch einfach ausschalten, und zwar so: Du editierst die /etc/inittab als root und suchst nach einer Zeile im Stile von: fmc:2345:respawn:/opt/IBM/db2/V8.1/bin/db2fmcd #DB2 Fault Monitor Coordinator Das Ding dann einfach mit einem "#" auskommentieren und einen kill -HUP 1 absetzen. Sollten dann immer noch mehr Zombies auftauchen wird es Zeit für den IBM UDB Support. Bye SystemError

Moin, mich dünkt ich hatte damals ein ähnliches Problem auf RHEL 3.0 + DB2 UDB V8... verdammt das ist lange her. Bist Du bitte mal so lieb und postest die Ausgabe von db2level als Instanzenbenutzer? Tankö... Bye SystemError

Evtl. hilft da ein $ export TERM=vt100? Bye SystemError

Moin, schau Dir mal das Kommando "screen" an: http://www.die.net/doc/linux/man/man1/screen.1.html Zum Beispiel: 1.) Screen anlegen mit screen -dmS deinscreenname 2.) An den Screen connecten mit screen -r deinscreenname 3.) Interaktives Programm starten... 4.) Vom Screen disconnecten mit STRG-a d ---> ---> also strg und a drücken, dann loslassen, dann d drücken 5.) Ausloggen, Einloggen (selber Benutzer) gehe zu 2.) ... Bye SystemError

Hey, was ich natürlich vergessen habe zu erwähnen: Im Script musst eben noch jeweils $? der einzelnen Kommandos überprüfen. Bye SystemError

Hey, also ich weiss zwar nicht wie Du an den ExitStatus des gepipten Programmes rankommst, aber vielleicht hilft Dir ja das hier weiter: function logit { echo `/bin/date "+%Y-%m-%d %H:%M:%S"` "$1" "$2" >> $MYLOGFILE } ... logit INFO "FaselBlaBlubb" logit ERROR "FaselBlaBlubb" ... Ist ein KSH Beispiel. So erzeuge ich in den meisten meiner ShellScripte die LogAusgaben; ohne tee zu benutzen. Beim Aufruf des Scriptes achte ich dann darauf mit: meinscript.ksh >> $MYLOGFILE 2>&1 STDERR und STDOUT des gesamten Scriptes ebenfalls in die entsprechende LogDatei umzuleiten. Wäre das für Dich evtl. nützlich? Bye SystemError

Nun... es bestünde natürlich auch die Möglichkeit in ausreichend skalierbare Hardware zu investieren? Skalierbar nicht nur im Sinne von CPU und RAM Austattung sondern auch im Sinne von I/O Kapazität. Mit dem Oracle RAC kannst Du das von Dir gewünschte Maß an Flexibilität via (teurer) Software erreichen. Mit entsprechender (teurer) Hardware kommst Du aber auch zum Ziel... Bye SystemError

Kleiner Nachtrag: Sind MYISAM Tabellen. Bye SystemError

Hallo, als Workaround könntest Du auch ein neues LV erstellen, ein neues DateiSystem darauf erzeugen und an genau die Stelle nach /opt einhängen wo Du den Platz brauchst. Keine Ahnung: /opt/blubb23 Vorteil: Geht im laufenden Betrieb. Bye SystemError

@Schlaubi: Und wieder was gelernt... thx. Bye SystemError

Hallo Leute, schreibe hier gerade an einem BackupScript (KSH), das MySQL Datenbanken via LVM2 SnapShot sichern soll. Vor dem Erzeugen des LVM2 SnapShots ist es notwendig einen "FLUSH TABLES WITH READ LOCK" abzusetzen, siehe: http://dev.mysql.com/doc/mysql/en/flush.html Ungünstig (für meine Zwecke) ist jetzt nur, dass mir der ReadLock wieder flöten geht sobald die MySQL Client Verbindung, aus der der Lock abgesetzt wurde, beendet wird. Also starte ich aus dem Script einen KSH CoProzess in dem der MySQL Client läuft; mit print -p schreibe ich dann das FLUSH TABLES WITH READ LOCK Kommando an den CoProzess // MySQL Client. Sobald dieses Kommando zurück kommt; sprich sobald MySQL keine "Dirty Pages" mehr im RAM hält will ich dann den LVM2 SnapShot erzeugen. Und genau da habe ich dann auch mein eigentliches Problem: Ich muss sicherstellen dass der FLUSH TABLES durch ist bevor ich den SnapShot erzeuge. Wie? 2 Möglichkeiten sind mir so in den Sinn gekommen ...: 1.) Irgendwie die Query OK, 0 rows affected Zeile des zurückkommenden FLUSH TABLES abfangen. Evtl. mit read -p Ist wohl eher ein ShellProblem, hier bin ich nicht wirklich weitergekommen. 2.) Aus einer weiteren MySQL Client Verbindung irgendwie abfragen ob es noch "Dirty Pages" im RAM gibt. Blos wie? Optimal fände ich Anregungen zu letzterem. Ach ja: BetriebsSystem: RedHat Enterprise Linux 4 für Intel32 + alle verfügbaren Updates. MySQL: mysql-server-4.1.10a-2.RHEL4.1 Schon mal Danke && Bye SystemError

Hallo, @Schlaubi: Linux ---> Bash ---> .bash_profile? Oder dreht SuSe hier eine extra Wurst? Bye SystemError

Moin, sowas in der Art von: [thou@thyboxen thou]$ export CLASSPATH=$CLASSPATH:/dein/pfad/bin ? Bye SystemError

Na, na, na wer wird den gleich... Ein /etc/init.d/sshd reload sollte nun wirklich genügen. Bye SystemError

Moin, hmmm... läuft denn das InetDSubSystem überhaupt? was sagt denn die Ausgabe von lssrc -l -s inetd ? Sollte das InetDSubSystem nicht laufen kannst Du versuchen es mit: startsrc -s inetd nachzustarten. Der von Charmanta vorgeschlagene "refresh" auf InetD ist sicherlich ein guter Gedanke wird aber nur funktionieren wenn InetD überhaupt läuft. Bye SystemError

Hallo HubbeldiBUBB, äääähhh... das wird so nicht funktionieren! Bandlaufwerke kannst Du nicht so einfach wie DateiSysteme auf Blockgeräten (CDs, Platten...) ins DateiSystem einhängen. Du musst die entsprechende Geräte Datei (wahrscheinlich /dev/st0 bei einem SCSI Tape (?) ) direkt mit "tar" ansprechen. Ebenfalls nützlich ist wahrscheinlich das Kommando "mt". Schau mal hier: http://www.whoopis.com/howtos/tapebackup.html Bye SystemError

Heya Sanches, der von Dir gepostete Auszug aus der man Seite sieht mir nach einem "man sysctl" aus, der fängt bei mir zumindest genauso an. Probiers mal mit "man sysctl.conf". Auf RedHat und Fedora Systemen wird die "/etc/sysctl.conf" automatisch beim SystemStart angezogen; FreeBSD macht es eben so. Also vermute ich mal dass SuSe dies auch so macht. Ist aber nur ne (naheliegende) Vermutung; ich eben nix SuSe. Bye SystemError

Hallo, also mein System (nix SuSe, geb 's ja zu) sagt zu man sysctl.conf: ... DESCRIPTION The /etc/sysctl.conf file is read in when the system goes into multi-user mode to set default settings for the kernel. ... Solange SuSe an dieser Stelle nix besonderes treibt sollte die Datei also beim SystemStart ausgelesen werden. Bye SystemError