Странное поведение Linux клиентов LDAP (ldap, linux)

[bombording]

Добрый день.

Имеется сервер на SLES 10.1. Ldap + bind + dhcp + samba
Используется как контроллер домена для Windows и Linux (OpenSUSE) машин.

Все работало идеально. Недавно упал Raid. После перезагрузки сервера произошел rebuld и все заработало.
Сейчас Windows машина отлично работают в домене.
Возникла проблема с поведением Linux машин в домене.
Пользователи заходят в систему, но документы офисные и почтовый клиент mozilla thunderbird не открываются. Тупо виснет на стадии открытия.
Все профиля хранятся на том же сервере LDAP и грузятся Linux машины тоже с него.


Подскажите, куда копать?
С правами все вроде ок. Все службы работают отлично.
На сервере аппаратный RAID + программный LVM. Boot утилита говорит что Raid цел и находится в Optimal.
Но у меня есть опасения что дело все таки в дисковой подсистеме.
И ещё запускаются процессы nfsd под 30-50% CPU

Спасибо!

[Bluetooth]

Но у меня есть опасения что дело все таки в дисковой подсистеме.

С чего это? Рейд не поврежден, выпал только один диск, который и заменили успешно. Т.е. ничего нештатного не происходило. Так что смотрите в сторону ldap

[bombording]

Но у меня есть опасения что дело все таки в дисковой подсистеме.

С чего это? Рейд не поврежден, выпал только один диск, который и заменили успешно. Т.е. ничего нештатного не происходило. Так что смотрите в сторону ldap

В том то и дело что проверяли все что можно. Вроде вся структура ldap работает. Некоторые Linux машины авторизируется и работают с системой нормально, до поры до времени. Потом резко виснут все приложения и файлы не открываются.
Все профиля Linux машин расположены на ldap сервере.
Если профиль скопировать на локальную машину и не монтировать профиль на сервере LDAP. То Linux машина авторизируется и все прекрасно открывается.
И сегодня был случай, что мы запустили поиск по корневому каталогу на ldap серверу, после этого сервер попросту перестал отвечать на запросы...завис.

[Bizdelnick]

Смотрите логи ldap'а.

[bombording]

Смотрите логи ldap'а.

Вот последние логи mldap

Код: Выделить всё

Nov 14 17:14:07 mldap nmbd[2868]: [2012/11/14 17:14:07.836930,  0] nmbd/nmbd_namequery.c:108(query_name_response)
Nov 14 17:14:07 mldap nmbd[2868]:   query_name_response: Multiple (3) responses received for a query on subnet UNICAST_SUBNET for name WWW.SEPUSA.COM<00>.
Nov 14 17:14:07 mldap nmbd[2868]:   This response was from IP 192.168.2.160, reporting an IP address of 0.0.0.0.
Nov 14 17:14:07 mldap nmbd[2868]: [2012/11/14 17:14:07.861915,  0] nmbd/nmbd_namequery.c:108(query_name_response)
Nov 14 17:14:07 mldap nmbd[2868]:   query_name_response: Multiple (4) responses received for a query on subnet UNICAST_SUBNET for name WWW.SEPUSA.COM<00>.
Nov 14 17:14:07 mldap nmbd[2868]:   This response was from IP 192.168.2.160, reporting an IP address of 0.0.0.0.
Nov 14 17:14:07 mldap nmbd[2868]: [2012/11/14 17:14:07.886892,  0] nmbd/nmbd_namequery.c:108(query_name_response)
Nov 14 17:14:07 mldap nmbd[2868]:   query_name_response: Multiple (4) responses received for a query on subnet UNICAST_SUBNET for name WWW.SEPUSA.COM<00>.
Nov 14 17:14:07 mldap nmbd[2868]:   This response was from IP 192.168.2.160, reporting an IP address of 0.0.0.0.
Nov 14 17:14:07 mldap nmbd[2868]: [2012/11/14 17:14:07.911872,  0] nmbd/nmbd_namequery.c:108(query_name_response)
Nov 14 17:14:07 mldap nmbd[2868]:   query_name_response: Multiple (4) responses received for a query on subnet UNICAST_SUBNET for name WWW.SEPUSA.COM<00>.
Nov 14 17:14:07 mldap nmbd[2868]:   This response was from IP 192.168.2.160, reporting an IP address of 0.0.0.0.
Nov 14 17:15:09 mldap smbd[23144]: [2012/11/14 17:15:09.332448,  0] lib/util_sock.c:1441(get_peer_addr_internal)
Nov 14 17:15:09 mldap smbd[23144]:   getpeername failed. Error was Transport endpoint is not connected
Nov 14 17:15:09 mldap smbd[23144]: [2012/11/14 17:15:09.332924,  0] lib/util_sock.c:474(read_fd_with_timeout)
Nov 14 17:15:09 mldap smbd[23144]: [2012/11/14 17:15:09.333011,  0] lib/util_sock.c:1441(get_peer_addr_internal)
Nov 14 17:15:09 mldap smbd[23144]:   getpeername failed. Error was Transport endpoint is not connected
Nov 14 17:15:09 mldap smbd[23144]:   read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
Nov 14 17:15:09 mldap smbd[23145]: [2012/11/14 17:15:09.609771,  0] lib/util_sock.c:474(read_fd_with_timeout)
Nov 14 17:15:09 mldap smbd[23145]: [2012/11/14 17:15:09.609918,  0] lib/util_sock.c:1441(get_peer_addr_internal)
Nov 14 17:15:09 mldap smbd[23145]:   getpeername failed. Error was Transport endpoint is not connected
Nov 14 17:15:09 mldap smbd[23145]:   read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
Nov 14 17:15:09 mldap smbd[23146]: [2012/11/14 17:15:09.613920,  0] lib/util_sock.c:1441(get_peer_addr_internal)
Nov 14 17:15:09 mldap smbd[23146]:   getpeername failed. Error was Transport endpoint is not connected
Nov 14 17:15:09 mldap smbd[23146]: [2012/11/14 17:15:09.614362,  0] lib/util_sock.c:474(read_fd_with_timeout)
Nov 14 17:15:09 mldap smbd[23146]: [2012/11/14 17:15:09.614422,  0] lib/util_sock.c:1441(get_peer_addr_internal)
Nov 14 17:15:09 mldap smbd[23146]:   getpeername failed. Error was Transport endpoint is not connected
Nov 14 17:15:09 mldap smbd[23146]:   read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
Nov 14 17:15:09 mldap smbd[23147]: [2012/11/14 17:15:09.775362,  0] lib/util_sock.c:474(read_fd_with_timeout)
Nov 14 17:15:09 mldap smbd[23147]: [2012/11/14 17:15:09.775475,  0] lib/util_sock.c:1441(get_peer_addr_internal)
Nov 14 17:15:09 mldap smbd[23147]:   getpeername failed. Error was Transport endpoint is not connected
Nov 14 17:15:09 mldap smbd[23147]:   read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer.


Nov 14 17:19:58 mldap rpc.mountd: authenticated mount request from opensuse09.domen.ru:951 for /shares/DiskH (/shares/share1)
Nov 14 17:19:58 mldap rpc.mountd: authenticated mount request from opensuse09.domen.ru:720 for /shares/DiskG (/shares/share2)
Nov 14 17:19:58 mldap rpc.mountd: authenticated mount request from opensuse09.domen.ru:941 for /shares/DiskH (/shares/share3)
Nov 14 17:19:59 mldap rpc.mountd: authenticated mount request from opensuse09.domen.ru:818 for /shares/insurance (/shares/share4)
Nov 14 17:19:59 mldap rpc.mountd: authenticated mount request from opensuse09.domen.ru:732 for /home (/home)

[Bluetooth]

Но у меня есть опасения что дело все таки в дисковой подсистеме.

С чего это? Рейд не поврежден, выпал только один диск, который и заменили успешно. Т.е. ничего нештатного не происходило. Так что смотрите в сторону ldap

В том то и дело что проверяли все что можно. Вроде вся структура ldap работает. Некоторые Linux машины авторизируется и работают с системой нормально, до поры до времени. Потом резко виснут все приложения и файлы не открываются.
Все профиля Linux машин расположены на ldap сервере.
Если профиль скопировать на локальную машину и не монтировать профиль на сервере LDAP. То Linux машина авторизируется и все прекрасно открывается.
И сегодня был случай, что мы запустили поиск по корневому каталогу на ldap серверу, после этого сервер попросту перестал отвечать на запросы...завис.

Стоило это сразу описать, это гораздо больше относится к проблеме, чем рассказ про рейды.
Сервер зависает полностью(вся ось?) или ldap сервис? Если полностью, то действительно, похоже на проблему с железом.
dmesg что говорит? что говорит smartctl на винтах?

[bombording]

Но у меня есть опасения что дело все таки в дисковой подсистеме.

С чего это? Рейд не поврежден, выпал только один диск, который и заменили успешно. Т.е. ничего нештатного не происходило. Так что смотрите в сторону ldap

В том то и дело что проверяли все что можно. Вроде вся структура ldap работает. Некоторые Linux машины авторизируется и работают с системой нормально, до поры до времени. Потом резко виснут все приложения и файлы не открываются.
Все профиля Linux машин расположены на ldap сервере.
Если профиль скопировать на локальную машину и не монтировать профиль на сервере LDAP. То Linux машина авторизируется и все прекрасно открывается.
И сегодня был случай, что мы запустили поиск по корневому каталогу на ldap серверу, после этого сервер попросту перестал отвечать на запросы...завис.

Стоило это сразу описать, это гораздо больше относится к проблеме, чем рассказ про рейды.
Сервер зависает полностью(вся ось?) или ldap сервис? Если полностью, то действительно, похоже на проблему с железом.
dmesg что говорит? что говорит smartctl на винтах?

Машина перестала пинговаться.

В dmesg вроде бы нет ошибок.
smartctl буду смотреть чуть позже, но он походу не включен на винтах.
И при boot загрузке, все Raid стоят в состоянии Optimal.

Код: Выделить всё

mldap:/var/log # dmesg |grep sda


Kernel command line: root=/dev/sda1 vga=0x317 resume=/dev/sda2 splash=silent
SCSI device sda: 155987857 512-byte hdwr sectors (79866 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
sda: asking for cache data failed
sda: assuming drive cache: write through
SCSI device sda: 155987857 512-byte hdwr sectors (79866 MB)
sda: Write Protect is off
sda: Mode Sense: 00 00 00 00
sda: asking for cache data failed
sda: assuming drive cache: write through
 sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
ReiserFS: sda1: found reiserfs format "3.6" with standard journal
ReiserFS: sda1: using ordered data mode
ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda1: checking transaction log (sda1)
ReiserFS: sda1: Using r5 hash to sort names
ReiserFS: sda1: Removing [163 14559836 0x0 SD]..done
ReiserFS: sda1: There were 1 uncompleted unlinks/truncates. Completed
Adding 1646652k swap on /dev/sda2.  Priority:-1 extents:1 across:1646652k


mldap:/var/log # dmesg |grep sdb


SCSI device sdb: 976495669 512-byte hdwr sectors (499966 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 00 00 00
sdb: asking for cache data failed
sdb: assuming drive cache: write through
SCSI device sdb: 976495669 512-byte hdwr sectors (499966 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 00 00 00
sdb: asking for cache data failed
sdb: assuming drive cache: write through
 sdb: unknown partition table
sd 0:0:12:0: Attached scsi disk sdb

Код: Выделить всё

mldap:/var/log # dmesg | grep Error
ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative [20060127]
ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative [20060127]
ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative [20060127]
ACPI Error (nsxfeval-0242): Handle is NULL and Pathname is relative [20060127]

[Bluetooth]

smartctl буду смотреть чуть позже, но он походу не включен на винтах.

Не, я не про демон, я про текущие значения смарта:
smartctl -a /dev/sdX

А просто dmesg, без грепа, не смотрели?

Машина перестала пинговаться.

Ммм, а на консоль что-нибудь выдала? Если не посмотрели, то стоит подвесить еще раз, будучи у консольки :) Заодно и проверите - полностью ли ушла в нирвану или что-то работает, клавиатура, например.