Процесс 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 на них тоже было бесплодно.

плохой 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

хороший sssd

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 не содержит данных. И он, и / var / log / sssd / logs, похоже, прекратили сбор сегодня около 9:03, / var / log / secure продолжал накапливать данные без проблем. Перезапуск системного журнала устранил проблему для сообщений, но журналы sssd по-прежнему не работают.

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

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

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

-Омни