openSUSE Users (Deutsch) October 2005

users-de@lists.opensuse.org

386 participants
609 discussions

Seltsames Problem: "syslog-ng" beendet sich oder crasht evtl. nach SIGHUP

by Steffen Moser

Hallo, ich habe seit einigen Wochen einen AMD-Opteron-basierten File-Server im Testeinsatz. Auf dieser Maschine ist SuSE Linux 10.0 installiert, als Kernel läuft ein Vanilla-2.6.14. Am Samstag um 10:30 Uhr hat "cron.daily" das Kommando "logrotate" ge- startet. So weit - so gut. Gegen Mittag wollte ich mich remote via SSH auf der Maschine einloggen. Zwar kam ich noch bis zur Passwortabfrage des SSH-Clients, aber dann hing das Login. Andere Dienste, die auf das ebenfalls auf dieser Ma- schine gehaltene OpenLDAP-Verzeichnis zugreifen wollten, hingen eben- falls. Der auf der selben Maschine laufende Webserver dagegen publizierte zur gleichen Zeit die vorhandenen Test-Webseiten absolut problemlos. Ich fuhr dann am Samstagnachmittag hin zum Standort des Servers und stellte fest: Auch an der Konsole ist kein Login mehr möglich. Eben- falls war nichts Spannendes auf der Konsole, die per "ALT+F10" erreich- bar ist, zu finden. Die Maschine an sich lief aber noch. Der darauf laufende Webserver antwortete einwandfrei und performant. Nach einem Reset lief der Rechner wieder "normal". Interessant war: Seit 10:30:01 Uhr gab es keine Logfile-Einträge in "/var/log/messages" bzw. "/var/log/warn" mehr. Also gut - ich dachte, der OpenLDAP-Server hatte sich aufgehängt und daher Probleme mit dem Login gemacht. Ich hatte anschließend auch in "/etc/ldap.conf" Timeout-Parameter gesetzt, damit im Falle eines nicht erreichabren OpenLDAP-Servers das PAM nicht ewig wartet, sondern lo- kale Benutzer "zur Not" auch bei nicht funktionierendem OpenLDAP-Server reinlässt. Also gut - getestet - Login klappt zur Not auch ohne einen laufenden OpenLDAP-Server nach einem gewissen Timeout von 30 Minuten. Über die Tatsache, weshalb seit 10:30:01 Uhr kein Logfile-Eintrag mehr geschrieben wurde, machte ich mir dort aber noch keine Gedanken. Nächstes Ereignis: Am Sonntag war ich schon am frühen morgen per SSH einloggt (besser ge- sagt - ich hatte die Shell noch vom Samstagabend her offen, und hatte den ganzen Sonntag noch nicht auf der Maschine gearbeitet). Gegen 14 Uhr wollte ich mich mit einer weiteren Shell einloggen, da ich zwei Kommandozeilenfenster zum Server haben wollte für diverse Arbeiten. Aber: Das selbe Problem wie am Tag zuvor: Auf der zweiten Shell war kein Login möglich. SSH-Daemon fordert (ziemlich träge) das Passwort an und macht nach Eingabe desselben gar nichts mehr. Ich beendete und restartete in der ersten Shell diverse Dienste, da ich dachte, sie seien evtl. für das Verhalten verantwortlich. Nichts zu sehen. Auch nichts, was massenhaft CPU oder Speicher in Anspruch nahm. Dann blickte ich nach "/var/log/messages" und sah mir gegen 14 Uhr die letzten Ausgaben an: | Oct 30 09:30:02 fsa01-neu slapd[5549]: conn=0 op=583 SRCH base="dc=egu,dc=schule,dc=ulm,dc=de" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=squid))" | Oct 30 09:30:02 fsa01-neu slapd[5549]: conn=0 op=583 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass | Oct 30 09:30:02 fsa01-neu slapd[5549]: <= bdb_equality_candidates: (uid) index_param failed (18) | Oct 30 09:30:02 fsa01-neu slapd[5549]: conn=0 op=583 SEARCH RESULT tag=101 err=0 nentries=0 text= | Oct 30 09:30:02 fsa01-neu syslog-ng[4813]: SIGHUP received, restarting syslog-ng | Oct 30 09:30:03 fsa01-neu slapd[5549]: conn=0 op=584 SRCH base="dc=egu,dc=schule,dc=ulm,dc=de" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=man))" Ah ja. Die Maschine hatte die ganze Nacht durch diverse Meldungen der OpenLDAP-DB nach "/var/log/messages" geschrieben. Ist ja auch okay. Aber um 09:30 Uhr, genau 24 Stunden nach dem Log-Stopp am Samstag (-> Zeitumstellung) hört das Logging erneut auf. Nach einem Restart des "syslog-ng"... | Oct 30 14:39:09 fsa01-neu syslog-ng[5985]: syslog-ng version 1.6.8 starting ...konnte ich mich dann problemlos wieder einloggen: | Oct 30 14:39:14 fsa01-neu sshd[5889]: Accepted keyboard-interactive/pam for root from 10.0.0.1 port 35203 ssh2 Nun habe ich nicht darauf geachtet, ob der "syslog-ng" tot war oder gar nicht mehr lief. Mein Verdacht war dann: "logrotate" schickt (wenn es was zu rotieren gibt) - laut der Da- tei "/etc/logrotate.d/syslog" ein "/etc/init.d/syslog reload". Das wiederum dürfte ein "SIGHUP" senden. Heute (Montag) ist nichts passiert. "syslog-ng" loggt einwandfrei und neue SSH-Connections sind auch kein Problem. Aber heute hat "logrotate" auch nichts zum Rotieren gehabt. Also auch keine "post- rotate"-Kommandos, und damit kein "/etc/init.d/syslog reload". Seltsamerweise kann ich das Aufhängen (oder Beenden) des "syslog-ng" nicht provozieren, indem ich den "/etc/init.d/syslog reload" manuell ausführe. Ich warte jetzt also ab bis "logrotate" wieder rotiert. Die Fragen, die sich mir stellen, sind jetzt: - Warum "spinnt" der "syslog-ng" herum, wenn er ein HUP-Signal ge- sendet bekommt? Warum hört er dann mit dem Logging auf? - Hat dieses Verhalten denn sonst schon jemand beobachtet, ins- besondere unter SuSE Linux 10.0 x86_64? Die neusten SuSE-Updates dürften alle eingespielt sein. Bis auf den Vanilla-2.6.14-Kernel sind eigentlich keine großartigen Ver- änderungen an der Standardinstallation vorgenommen worden. - Wie verhält sich denn ein Rechner, bei dem der Syslog-Daemon gar nicht mehr läuft? Kann es tatsächlich zu dem von mir beobachteten Fall kommen, dass nach einer gewissen Zeit die Dienste, die loggen wollen, hängen? Wenn ich das richtig sehe, schreiben die Dienste, die loggen wollen, in das "named socket" unter "/dev/log" rein. Was aber passiert, wenn dort niemand mehr rausliest? Puffert der Kernel eine Weile? Und erst nach einer gewissen Anzahl an Meldungen passiert's? Denn, wenn ich den "syslog-ng" manuell beende, kann ich mich (zumin- dest unmittelbar danach) noch problemlos via SSH einloggen oder an- dere Dienste benutzen, die loggen (z.B. OpenLDAP-Anfragen stellen). Längere Zeit hatte ich den Syslog-Daemon bisher nicht absichtlich beendet lassen. Oder treten die Hänger der Applikationen nur dann auf, wenn Syslog- Daemon-Prozess zwar noch läuft, sich aber aufgehängt hat? Fragen über Fragen. Vielleicht weiß ja hier jemand weiter oder kann zumindest Details zur Arbeit des Syslog-Daemons sagen. Ich wollte auf jeden Fall mal auf Nummer sicher gehen, bevor ich an SuSE einen Bug melde bzgl. "syslog-ng". Danke und Grüße, Steffen

16 years, 7 months

tun0 und qemu

by Jörg Dreßler

Hallo, ich hab da mal ne Frage, ich habe WinXP ind qemu installiert und wollte das Netzwerk über die tun0-Schnittstelle realisieren. Das klappt ganz grundsätzlich auch. Ich habe noch nen kleines Heimnetz auf 192.168.0.* und die VM sollte auf Grund der anderen Schnittstelle ins Netz 192.168.1.*. Mein Linuxrechner fungiert im Heimnetzt als Router/Gateway und macht das alles auch ganz toll, nur mit der VM nicht, von der aus komme ich nicht übers lokale Netz hinaus. Das ist dann auch mein Problem, da ich mit dem WinXP schon mal ins Netz möchte. Außerdem habe ich noch eine zweite Frage, in der Suse Firewall hab ich die tun0-Schnittstelle in die Interne Zone eingetragen, trotzdem komm ich sobald die Firewall aktiviert ist, nicht mla mehr mit nem ping auf den Linuxrechner, erst wenn ich wieder in die Einstellungen geschaut habe, funktioniert der Ping wieder. Ich arbeite mit Suse 9.3. Hab ich bei meiner config irgendwas übersehen? Danke Jörg Ausgaben: > ifconfig tun0 tun0 Protokoll:Ethernet Hardware Adresse 4A:4A:DB:67:1F:62 inet Adresse:192.168.1.1 Bcast:192.168.1.255 Maske:255.255.255.0 inet6 Adresse: fe80::484a:dbff:fe67:1f62/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:220 errors:0 dropped:0 overruns:0 frame:0 TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:500 RX bytes:22657 (22.1 Kb) TX bytes:3986 (3.8 Kb) > route Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.1.2 * 255.255.255.255 UH 0 0 0 tun0 192.168.1.0 * 255.255.255.0 U 0 0 0 tun0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo

16 years, 7 months

Bootkonzept SuSE 9.3

by Markus Heidinger

Hallo Liste! Zunächst sorry für das Doppelpost, ich hatte vergessen, die Signierung abzuschalten bzw hat damit offenbar etwas nicht funktioniert :-( Folgendes Problem: Irgendwann während der letzten Versionswechsel wurde das Bootkonzept von SuSE geändert/erweitert. Es geht dabei darum, dass Startskripte von unabhängigen (?!) Diensten parallelisiert wird. Gesteuert wird dies über die Konfiguration in den /etc/init.d/.depend.* Dateien, aus- und eingeschaltet über den Parameter "RUN_PARALLEL" in /etc/sysconfig/suseconfig. Mein Problem ist nun, dass Dienste, für die für den gewünschten Runlevel in /etc/rc.d/rc*.d ein korrekter SXXfoo Link für ein Startskript in /etc/rc.d erstellt wurde, unter Umständen gestartet wird, wenn kein Eintrag in /etc/rc.d/.depend.start erstellt wurde. Einen entsprechenden Eintrag dort zu erstellen ist grundsätzlich kein Problem, jedoch ist nicht ganz klar, wer dort noch Einträge erzeugt bzw wie es passieren kann, dass solche Einträge hin und wieder auf unerklärliche Weise wieder verschwindnen (YaST??). Der Runlevel-Editor kann es nicht alleine sein, denn den verwende ich ohnehin nicht. Konkret tritt bei mir das Problem zB im Zusammenhang mit einem Skript auf, das im Hintergrund läuft und meine DSL-Verbindung überwacht und diese ggf neu startet und dann sockd und xntpd neustartet. Die Sache ist auch die, dass das alles selbst ohne eigene Anpassungen der start/stop Skripte fehlerbehaftet ist, Beispiel: der xntpd ist von network und named abhängig, weil zunächst eine "initial time" geholt wird und erst dann der eigentliche xntpd gestartet wird. Ohne network startet der Dämon erst gar nicht richtig. Diese Abhängigkeit ist nicht korrekt in .depend.start verankert. Meine Fragen, nachdem ich nirgendwo entsprechende Information dazu gefunden habe, auch nicht in der SDB von SuSE: * Welcher Mechanismus ist für die Parallelisierung verantwortlich? * Wo wird festgelegt, welche Dienste von welchen anderen abhängig sind? * Wie kann ich erreichen, dass ein entsprechendes Startskript SXXfoo auf jeden Fall abgearbeitet wird, auch wenn kein Eintrag in der .depend.start erstellt wurde? * Wie kann ich erreichen, dass meine eigenen Einträge auf /etc/rc.d/.depend.start nicht verschwinden * Welche Nachteile - ausser einem langsameren Startprozess - hat das Abschalten dieses ominösen Parallelisierungsmechanismus? * Wo ist das ganze Ding dokumentiert? Vielleicht kann irgend jemand Licht in dieses Dunkel bringen - ich bedanke mich schon jetzt dafür ;-) Markus

16 years, 7 months

Kann meine Soundkarte nicht konfigurieren (SUSE 10.0)

by Kostas Georgokitsos

Liebe Liste, Ich habe vor kurzem von SUSE 9.2 auf 10.0 upgegradet. Nun kann ich meine on-board Soundkarte nicht mehr konfigurieren. Diese war auch mit 9.2 ein bisschen problematisch, aber immerhin kam ich damals mit alsaconf weiter. Jetzt haengt alsaconf den Rechner auf und Yast scheint Probleme mit einem Kernelmodul zu haben (alasconf ja vielleicht auch): An error occurred during the installation of: 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller The kernel module snd-intel8x0 for sound support could not be loaded. This can be caused by incorrect module parameters, including invalid IO or IRQ parameters. Mein Kernel ist 2.6.13-15-smp. Hat jemand aehnliche Probleme? Kostas

16 years, 7 months

xgettext

by Magnus Rosenbaum

Das Programm xgettext ist in SuSE 10 anscheinend nicht mehr enthalten, bei SuSE 9.3 war es noch im Paket gettext. Hat jemand ne Idee, warum das nicht mehr da ist oder wie ich es nun bekomme ohne gettext neu zu kompilieren? Oder gibt es noch ein anderes Tool, das die gettext-msgid's aus dem Quelltext extrahieren kann? Ciao, Magnum -- Carl Magnus Rosenbaum M.A. Tel: 089 - 700 666 26 Administration - Programmierung - Weiterbildung Fax: 089 - 700 666 86 http://cmr.forestfactory.de/ Mobil: 0163 - 700 666 2

16 years, 8 months

kernel neu kompilieren, GRUB

by Walter Ulmke

Hallo an alle: ich habe den Kernel neu kompiliert, einfach über den alten 'drüber (-default) Ich bin mir 100% sicher daß es mit der Kompilierung kein Problem gibt. Wenn der Rechner bootet, erscheint oben links im Display "GRUB" Sonst passiert nichts. Über die CD läßt sich der Kernel (mit einigen Fehlermeldungen) booten. Ich habe kompiliert (alles durchgelaufen) und installiert mit: make clean bzImage make modules INSTALL_PATH=/boot make install make modules_install cp /usr/src/linux/System.map /boot Ich bin mir sicher daß es ein GRUB Problem ist - nur was?!? Kann mir jemand helfen?? -- Regards, Walter Ulmke, momentan besser bekannt als "Verzweifelter von Hopsten" Ulmke Machine Tools, 48496 Hopsten, Germany

16 years, 8 months

Probleme mit Shellscript und "Befehl ausführen"

by Kay Patzwald

Hallo, ich habe hier ein kleines Shellscript, was Probleme macht, wenn ich es mit "Befehl ausführen" ausführe. Das Programm startet im Hintergrund, der Dialog von "Befehl ausführen" verschwindet nicht. Erst wenn ich das Programm beende, bekomme ich folgende Fehlermeldung: "KDEInit konnte "rssowl" nicht starten.". Wenn ich das Programm aus dem K-Menü aufrufe oder in der Konsole starte, gibt es keine Probleme. Auch wenn ich in "Befehl ausführen" ein Häkchen bei "In Terminal starten" mache, funktioniert es, ist allerdings unschön, da die Shell ja die ganze Zeit offen sein muss. Hier das Script: ------------------------------------ #!/bin/sh # # startscript for rssowl # cd /usr/share/rssowl exec java -jar -Djava.library.path=/usr/lib/ rssowl.jar "$@" ------------------------------------ Die Probleme mit dem Script sind erst aufgetauscht, seitdem ich exec verwende, um Kommandozeilenparameter an das Programm weiterleiten zu können. Gibt es dafür evtl. noch andere Möglichkeiten? MfG Kay

16 years, 8 months

Masquerading und transparenter Server laufen nicht unter 10.0

by Michael Wendt

Hallo Liste! Nachdem ich von 9.2 auf 10.0 upgedatet habe, kann ich von Windows Clients nur noch ins Internet, wenn Squid aktiviert und der Proxy im Browser manuell eingestellt ist. An der Firewall scheint es nicht zu liegen, denn selbst bei abgeschalteter Firewall bleibt das Problem. Auch wenn Masquerading angehakt ist, ändert das nichts. In welcher Datei muss ich nachsehen, um diesem Konfigurationsproblem auf die Spur zu kommen. Das System sieht so aus: Zunächst ist da die Suse-Kiste mit Suse 10.0 und mit DSL-Internetzugang, sowie zweiter Netzwerkkarte für die interne Kommunikation. Dann sind verschiedene Rechner über einen Switch an die zweite Netzwerkkarte angebunden. Da sie überwiegend mit Windows laufen, dient zur internen Kommunikation Samba. Auch das läuft noch nicht richtig. Muss aber nicht unbedingt Thema dieses Threads sein. Nur soviel: Ich kann von der Suse-Kiste im Konqueror mit 'smb://192.168.x' nicht auf Windows-Shares zugreifen. Alle in Betracht kommenden Dienste sind gestartet, d.h. smb, squid, network. Für die Neuinstallation habe ich eine neue Festplatte (hda) verwendet. Die alte mit der 9.2er Installation habe ich umgejumpert; sie ist jetzt hdb. Alle alten Konfigurationsdateien sind noch vorhanden. Ich habe versuchsweise nach vorheriger Sicherung das 'sysconfig/network'-Verzeichnis aus der alten Konfiguration in die neue übertragen; das funktionierte zwar, hat das Problem aber nicht gelöst. Die squid.conf und die smb.conf habe ich aus der alten Konfiguration unverändert übernommen. Wer kann mir weiterhelfen? MfG Michael

16 years, 8 months

SCSI Streamer blockiert das System -> wie Fehlersuche?

by Harald Oehlmann Elmicron

Hallo Liste, seit Juni habe ich folgendes Problem, was plötzlich aufgetaucht ist: System: SuSE-Linux 9.3, SCSI UW Bus mit Tandberg SLR75 Bandlaufwerk. Problem: sobald ich das Bandlaufwerk anspreche steht das Linux-System. Manchmal kommt noch die Ausschrift "Protection Fault", manchmal nicht. Beispiel: mt /dev/tape status -> System steht Wie kann ich sowas debuggen ? Woran kann es liegen ? Weitere Informationen: * Streamer ist schon getauscht * Am SCSI-Bus hängen noch 2 Festplatten (als RAID) die funktionnieren. * SCSI-Controler findet Bandlaufwerk * Linux findet Bandlaufwerk und läd tape driver * cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: Intel Model: Host Drive #00 Rev: Type: Direct-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 04 Lun: 00 Vendor: TANDBERG Model: SLR60 Rev: 0595 Type: Sequential-Access ANSI SCSI revision: 02 Vielen Dank, Harald

16 years, 8 months

Fehlende Pakete bei Upgrade SL9.3 -> SL10.0: Cyrus IMAP, svnd

by Harald Oehlmann Elmicron

Ich wollte gerade auf auf unserem Servirer von SL9.3 auf SL10.0 update fahren (wie seit Jahren). Es fehlen aber für mich essentielle Pakete: Cyrus IMAP Daemon SVN Daemon (Revisionsverwaltung) Kann ich die Pakete im alten Stand lassen ? Da ich gerne alles mit Yast verwalte ist mir das Fehlen des IMAP Daemon unangenehm. Wird der in Zukunft nicht mehr unterstützt ? Lohnt eine Umstellung auf den normalen IMAPD (ohne Cyrus) ? Ich empfand besonders sie Tatsache, daß die E-Mail Benutzer keinen Login benötigen als sehr angenehm. Viele dank, Harald

16 years, 8 months

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

openSUSE Users (Deutsch) October 2005