Debian failed to stard System Security Services Daemon

Support Debian
#1

Bonjour,

Au démarrage d’un serveur sous debian 11 j’ai un message d’erreur me disant ceci:
Failed tu start system secutity services deamon
Dependency failed for SSSD PAC Service responder socket
Dependency failed for SSSD Sudo Service responder socket
Dependency failed for SSSD AutoFS Service responder socket
Dependency failed for SSSD NSS Service responder socket
Dependency failed for SSSD PAM Service responder socket
Dependency failed for SSSD PAM Service responder private socket
Dependency failed for SSSD SSH Service responder socket

Ce message tourne en boucle. J’ai tenté de faire un recovery mais hélas, le mot de passe root est impossible a taper (surtout en clavier anglais). J’ai booter sur un live CD pour voir si les disque étaient correct mais cela n’a rien changer

Une idée?

Merci de votre aide

#2

Bonjour,

Quelle était la dernière opération faite avant ces messages d’erreur?

As-tu moyen d’aller voir les fichiers de logs?

#3

Bonjour @Zargos,
Merci d’avoir répondu
La dernier opération était d’éteindre le serveur pour maintenance, il a été éteint correctement en faisant un poweroff.
En bootant avec un vlive CD je peu aller voir les fichiers logs mais lesquels?

#4

Il te suffit d’avoir un accès en lecture au disque de la machine, et pou rle fihchier de log /var/log/syslog déjà pour commencer.

#5

Voici les première ligne syslog

Mar 11 15:47:52 SRV1 logrotate[876]: cat: /var/run/sssd.pid: Aucun fichier ou dossier de ce type
Mar 11 15:47:52 SRV1 kernel: [    5.697896] kauditd_printk_skb: 1018 callbacks suppressed
Mar 11 15:47:52 SRV1 kernel: [    5.697899] audit: type=1400 audit(1710168472.381:1029): apparmor="ALLOWED" operation="exec" profile="/usr/sbin/sssd" name="/usr/libexec/sssd/sssd_be" pid=878 comm="sssd" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be"
Mar 11 15:47:52 SRV1 kernel: [    5.698568] audit: type=1400 audit(1710168472.381:1030): apparmor="ALLOWED" operation="file_mmap" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/libexec/sssd/sssd_be" pid=878 comm="sssd_be" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698586] audit: type=1400 audit(1710168472.381:1031): apparmor="ALLOWED" operation="file_mmap" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/lib/x86_64-linux-gnu/ld-2.31.so" pid=878 comm="sssd_be" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698689] audit: type=1400 audit(1710168472.381:1032): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/etc/ld.so.cache" pid=878 comm="sssd_be" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698703] audit: type=1400 audit(1710168472.381:1033): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/lib/x86_64-linux-gnu/libdl-2.31.so" pid=878 comm="sssd_be" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698708] audit: type=1400 audit(1710168472.381:1034): apparmor="ALLOWED" operation="file_mmap" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/lib/x86_64-linux-gnu/libdl-2.31.so" pid=878 comm="sssd_be" requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698737] audit: type=1400 audit(1710168472.381:1035): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/lib/x86_64-linux-gnu/libtevent.so.0.10.2" pid=878 comm="sssd_be" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698742] audit: type=1400 audit(1710168472.381:1036): apparmor="ALLOWED" operation="file_mmap" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/lib/x86_64-linux-gnu/libtevent.so.0.10.2" pid=878 comm="sssd_be" requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698765] audit: type=1400 audit(1710168472.381:1037): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/lib/x86_64-linux-gnu/libtalloc.so.2.3.1" pid=878 comm="sssd_be" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 kernel: [    5.698770] audit: type=1400 audit(1710168472.381:1038): apparmor="ALLOWED" operation="file_mmap" profile="/usr/sbin/sssd//null-/usr/libexec/sssd/sssd_be" name="/usr/lib/x86_64-linux-gnu/libtalloc.so.2.3.1" pid=878 comm="sssd_be" requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
Mar 11 15:47:52 SRV1 sssd_be[878]: Starting up
Mar 11 15:47:52 SRV1 sssd_be[878]: krb5_kt_start_seq_get failed: Key table file '/etc/krb5.keytab' not found
Mar 11 15:47:52 SRV1 sssd_be[878]: krb5_kt_start_seq_get failed: Key table file '/etc/krb5.keytab' not found
Mar 11 15:47:52 SRV1 sssd_be[878]: krb5_kt_start_seq_get failed: Key table file '/etc/krb5.keytab' not found
Mar 11 15:47:52 SRV1 sssd_be[878]: krb5_kt_start_seq_get failed: Key table file '/etc/krb5.keytab' not found
Mar 11 15:47:52 SRV1 sssd_be[878]: krb5_kt_start_seq_get failed: Key table file '/etc/krb5.keytab' not found
Mar 11 15:47:52 SRV1 sssd_be[878]: krb5_kt_start_seq_get failed: Key table file '/etc/krb5.keytab' not found
Mar 11 15:47:52 SRV1 sssd_be[878]: krb5_kt_start_seq_get failed: Key table file '/etc/krb5.keytab' not found
Mar 11 15:47:52 SRV1 sssd_be[878]: Failed to read keytab [FILE:/etc/krb5.keytab]: No suitable principal found in keytab
Mar 11 15:47:52 SRV1 logrotate[880]: cat: /var/run/sssd.pid: Aucun fichier ou dossier de ce type
Mar 11 15:47:52 SRV1 logrotate[883]: cat: /var/run/sssd.pid: Aucun fichier ou dossier de ce type
Mar 11 15:47:52 SRV1 logrotate[886]: cat: /var/run/sssd.pid: Aucun fichier ou dossier de ce type
Mar 11 15:47:52 SRV1 systemd[1]: logrotate.service: Succeeded.

Si je comprend bien le fichier /var/run/sssd.pid a disparu, comment le remettre en place?

#6

Salut,

c’est généralement un bête fichier texte dans lequel le programme enregistre son PID courant. Il est possible que sssd ait changé l’emplacement de son fichier de PID suite à une mise à jour.

Regarde dans le fichier de configuration de sssd (probablement quelque part sous /etc/) quel est le chemin du fichier dans lequel sssd veut écrire son PID, et au besoin crée le répertoire dans lequel ce fichier doit se trouver.

Typiquement, je mise sur le fait qu’il faut créer un répertoire /var/run/sssd ou /run/sssd

#7

Salut,
J’ai recréé les dossiers au bon endroit, puis j’ai vérifié que les droits étais correct mais au redémarrage sur serveur j’ai le même problème et vu qu’il était peu utiliser et que les softs d’installer dessus peuvent être réinjecter facilement, je préfère le recréer, je gagnerais du temps dessus.
En tout cas merci de votre aide @Zargos @Sputnik93.

1 J'aime