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
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
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
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
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
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
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
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
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
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