Obrigado por dedicar um tempo para verificar meu problema.
Atualmente estou trabalhando em um problema que apareceu apenas uma vez antes. Em 3 de janeiro, quando este apareceu pela primeira vez, fomos capazes de reiniciar o servidor e tudo parecia bem, mas agora está de volta. Este é um sistema de banco de dados de produção, portanto, encontrar uma janela para reinicializar pode, às vezes, ser difícil. Espero ter uma idéia firme do que pode estar acontecendo desta vez antes de reiniciarmos em alguns dias para fornecer outra correção temporária para o problema. Aqui vamos nós ...
A autenticação do usuário para o sistema em questão é tratada com o LDAP por meio do Red Hat Directory Server 9. O problema descrito abaixo é visto apenas neste servidor e até mesmo a contraparte que compartilha o banco de dados não exibe os mesmos sintomas. A partir de agora, nenhuma conta LDAP é capaz de autenticar e efetuar login no servidor. A autenticação LDAP está sendo manipulada pelo SSSD, que atualmente não pode ser interrompido ou reiniciado. Ao tentar fazer o console SSH deixar de responder. (ctrl-c é incapaz de sair do comando emitido)
PS mostra que os processos comuns do sssd estão sendo executados, mas tentar kill -9 neles não parece parar com nenhum deles.
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
Usando strace getent -s sss passwd , vejo que algumas tentativas de conexão estão sendo recusadas, mas não tenho certeza do que fazer com elas.
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)
Verificar lsof | head -n1; lsof | grep /var/lib/sss/pipes/ mostra muito menos canais abertos entre o sistema bom e o mau. Os PIDs para esses pipes são os mesmos relatados em ps aux , então tentar kill -9 sobre eles também foi infrutífero.
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
bom 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
Além disso, o / var / log / secure contém várias entradas de
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
Além disso, uma das primeiras coisas que notei foi que o arquivo / var / log / messages não continha dados. Tanto ele como / var / log / sssd / logs parecem ter parado de ser coletados por volta das 9:03 desta manhã, / var / log / secure continuou acumulando dados sem problemas. O reinício do syslog corrigiu o problema para mesages, mas os logs do sssd ainda não estão funcionando.
A última coisa que notei é que o dmesg é preenchido com mensagens como audit: backlog limit exceeded audit: audit_backlog=322 > audit_backlog_limit=320 e audit_log_start: 122 callbacks suppressed . Eu presumi que eram de quando o syslog não estava funcionando corretamente, mas ainda não o verificaram.
Eu ainda estou pesquisando sobre isso e espero encontrar algo, mas mais do que receber sugestões e feedback que as pessoas estejam dispostas a fornecer.
Muito obrigado!
-Omni