Процесс SSSD не умрет

Спасибо, что нашли время, чтобы проверить мою проблему.

В настоящее время я работаю над проблемой, которая появилась только один раз. Еще 3 января, когда это впервые появилось, мы смогли перезагрузить сервер, и все выглядело нормально, но теперь он вернулся. Это система производственной базы данных, поэтому иногда бывает сложно найти окно для перезагрузки. Я надеюсь получить четкое представление о том, что на самом деле может произойти в этот раз, прежде чем мы перезагрузим компьютер через несколько дней, чтобы обеспечить еще одно временное решение проблемы. Вот так...

Аутентификация пользователя для рассматриваемой системы выполняется с помощью LDAP через Red Hat Directory Server 9. Описанная ниже проблема видна только на этом одном сервере, и даже его аналог, который совместно использует базу данных, не отображает те же симптомы. На данный момент ни одна учетная запись LDAP не может проходить проверку подлинности и входить на сервер. Аутентификация LDAP обрабатывается SSSD, который в настоящее время не может быть остановлен или перезапущен. При попытке сделать либо консоль SSH перестает отвечать на запросы. (Ctrl-C не может выйти из введенной команды)

PS показывает, что обычные связанные с sssd процессы запущены, но пытаются kill -9 на них, кажется, не удается успешно остановить ни одного из них.

ps aux | grep sss | grep -v grep
root      1150  0.0  0.0 150828  2908 ?        D    09:05   0:00 /usr/libexec/sssd/sssd_nss -d 0 --debug-to-files
root      7025  0.0  0.0  93616  2504 pts/2    D    16:18   0:00 /usr/sbin/sssd -f -D
root     11148  0.0  0.0 179436  5672 ?        D    Jan08  16:22 /usr/libexec/sssd/sssd_be -d 0 --debug-to-files --domain default
root     32700  0.0  0.0 150784  2908 ?        D    10:10   0:00 /usr/libexec/sssd/sssd_pam -d 0 --debug-to-files

С помощью strace getent -s sss passwd Я вижу, что некоторые попытки подключения отклоняются, но я не совсем уверен, что с ними делать.

connect(3, {sa_family=AF_FILE, path="/var/lib/sss/pipes/nss"...}, 110) = -1 ECONNREFUSED (Connection refused)
close(3)                                = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
connect(3, {sa_family=AF_FILE, path="/var/lib/sss/pipes/nss"...}, 110) = -1 ECONNREFUSED     (Connection refused)
close(3)                                = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
connect(3, {sa_family=AF_FILE, path="/var/lib/sss/pipes/nss"...}, 110) = -1 ECONNREFUSED (Connection refused)

проверка lsof | head -n1; lsof | grep /var/lib/sss/pipes/ показывает гораздо меньше открытых каналов между хорошей и плохой системой. PID для этих труб одинаковы из ps auxтак стараюсь kill -9 на них тоже было бесплодно.

Bad SSSD

lsof | head -n1; lsof | grep /var/lib/sss/pipes/
COMMAND     PID         USER   FD      TYPE             DEVICE    SIZE/OFF       NODE NAME
sssd_be   11148         root   15u     unix 0xffff8806635911c0         0t0   31817638 /var/lib/sss/pipes/private/sbus-dp_default.11148
sssd_be   11148         root   16u     unix 0xffff880d443d6180         0t0   31783555 /var/lib/sss/pipes/private/sbus-dp_default.11148
sssd_be   11148         root   17u     unix 0xffff880c536d94c0         0t0   31783560 /var/lib/sss/pipes/private/sbus-dp_default.11148

хорошо сссд

lsof | head -n1; lsof | grep /var/lib/sss/pipes/
COMMAND     PID         USER   FD      TYPE             DEVICE    SIZE/OFF       NODE NAME
sssd      26793         root   13u     unix 0xffff88030b5d8c40         0t0 3248762734 /var/lib/sss/pipes/private/sbus-monitor
sssd      26793         root   14u     unix 0xffff8808cc064bc0         0t0 3248762735 /var/lib/sss/pipes/private/sbus-monitor
sssd      26793         root   15u     unix 0xffff880a9d9bc840         0t0 3248768164 /var/lib/sss/pipes/private/sbus-monitor
sssd      26793         root   16u     unix 0xffff880040a32f00         0t0 3248768165 /var/lib/sss/pipes/private/sbus-monitor
sssd_be   26794         root   15u     unix 0xffff8808cc064200         0t0 3248767368 /var/lib/sss/pipes/private/sbus-dp_default.26794
sssd_be   26794         root   16u     unix 0xffff880a9d9bd880         0t0 3248763661 /var/lib/sss/pipes/private/sbus-dp_default.26794
sssd_be   26794         root   17u     unix 0xffff8809841b4480         0t0 3248763662 /var/lib/sss/pipes/private/sbus-dp_default.26794
sssd_nss  26795         root   16u     unix 0xffff880a9d9bd200         0t0 3248751954 /var/lib/sss/pipes/nss
sssd_pam  26796         root   16u     unix 0xffff880859e26180         0t0 3248774325 /var/lib/sss/pipes/pam
sssd_pam  26796         root   17u     unix 0xffff880859e27b80         0t0 3248774326 /var/lib/sss/pipes/private/pam

Кроме того, /var/log/secure содержит несколько записей

sshd[9177]: pam_succeed_if(sshd:auth): error retrieving information about user
su: pam_sss(su-l:session): Request to sssd failed. Connection refuse
crond[29568]: pam_sss(crond:session): Request to sssd failed. Connection refused

Кроме того, первое, что я заметил, было то, что файл /var/log/messages не содержал данных. Кажется, что и it, и /var/log/sssd/ logs перестали собирать около 9:03 утра, /var/log/secure продолжала накапливать данные без проблем. Перезапуск системного журнала исправил проблему для сообщений, но журналы sssd все еще не работают.

Последнее, что я заметил, dmesg заполняется сообщениями вроде audit: backlog limit exceededaudit: audit_backlog=322 > audit_backlog_limit=320 а также audit_log_start: 122 callbacks suppressed, Я предположил, что это из-за того, что syslog не работал должным образом, но еще не проверил это.

Я все еще исследую это и надеюсь, что найду что-нибудь, но более чем приветствую любые предложения и отзывы, которые люди готовы предоставить.

Большое спасибо!

-Omni