Dotaz: Syslogd - vytuhnuti

[dsumsky]

Dobry den, bohuzel nahodne se mi na jednom linux. serveru stava, ze syslogd demon se dostane do podezreleho stavu a prestane odpovidat a logovat zpravy. Server bezi na CentOS 4 update 5. Problem je v tom, ze sluzby, ktere vyuzivaji syslog rozhrani, pak "visi" a cekaji na zpracovani pozadavku demonem. Situaci jsem simuloval tak, ze jsem se pokusil shodit napr. nscd demona pomoci init skriptu:

/etc/init.d/nscd stop

V init skriptu se spusti system logger:

initlog -q -n /etc/init.d/nscd -s 'nscd shutdown' -e 2

A na tomto prikazu se vykonani init skriptu zastavi. Trasovanim systemovych volani visiciho procesu initlog pomoci strace jsem zjistil nasledujici:
socket(PF_FILE, SOCK_DGRAM, 0) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
sendto(3, "<189>Sep 20 23:10:41 nscd: nscd "..., 47, MSG_NOSIGNAL, NULL, 0

Soket pro komunikaci se syslogd demonem se otevre, ale na volani sendto vse skonci a zatuhne. Problem je v tom, ze to ovlivni beh vsech sluzeb, ktere syslog vyuzivaji. Pomuze az nasilne zabiti procesu syslogd a jeho znovu nastartovani.

Nesetkali jste se nekdo s podobnym chovanim?!?

Odpovědi

[Vladimir Dvorak]

Zdravim,

na tento problem jsem take narazil. Predtim ale nasledovala hardwarova chyba:

ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back

Na jinem stroji, ktery bezi temer stejnou konfiguraci (jak HW tak SW), se mi to nestalo. Zkontrolujte predne tedy, zda je Vas hw v poradku.

V.

[edois]

předtím následovala? :)

[Vladimir Dvorak]

... mohu nejak pomoci s vysvetlenim? ;)

[michich]

A co dělá v tu chvíli samotný syslogd? V jakém stavu je jeho proces? Můžeš ho straceovat? Můžeš nainstalovat debuginfo a pomocí gdb získat backtrace? Máš něco zajímavého v syslog.conf? Není plný disk?

[Vladimir Dvorak]

... tato situace u me nastala pred nedavnem a od te doby se neopakovala. Muj ambulantni zasah mel za cil opravit chybu ASAP, takze jsem prilis nezkoumal dany proces (syslogd). Proces sel zabit pouze -9 signalem. U me se jedna s nejvyssi pravdepodobnosti o hw selhani, nebot, jak jsem psal, na zadnem jinem stoji se mi to nestalo (velice podobne konfigurace, stejne verze OS Debian, stejne architektury).

[pupu]

To je nejake podivuhodne. Co dela touhle dobou vlastni syslogd? Nevisi na tom soketu nakonec neco uplne jineho? Kdyz tam zkusite dat treba syslog-ng a klasicky syslog uplne zahodite? Ja bych osobne tipoval, ze ten soket drzi neco uplne jineho, pripadne ze to vubec datagramovy soket neni. Nebo je problem v kernelu...

ls -l /dev/log strace -p pid_syslogd lsof -p pid_syslogd lsof /dev/log ...