# Debian failed to stard System Security Services Daemon **URL:** \ **Category:** Support Debian\ **Created:** [Mars 12, 2024, 7:49 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687 "2024-03-12T07:49:25Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mavric](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mavric/32/5276_2.png) [@mavric](https://www.debian-fr.org/u/mavric)\ **Post date:** [Mars 12, 2024, 7:49 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687/1 "2024-03-12T07:49:25Z")
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 ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Mars 12, 2024, 8:14 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687/2 "2024-03-12T08:14:46Z")
Bonjour, Quelle était la dernière opération faite avant ces messages d’erreur? As-tu moyen d’aller voir les fichiers de logs? ---
**Author:** ![mavric](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mavric/32/5276_2.png) [@mavric](https://www.debian-fr.org/u/mavric)\ **Post date:** [Mars 12, 2024, 8:26 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687/3 "2024-03-12T08:26:11Z")
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? ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Mars 12, 2024, 8:55 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687/4 "2024-03-12T08:55:55Z")
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. ---
**Author:** ![mavric](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mavric/32/5276_2.png) [@mavric](https://www.debian-fr.org/u/mavric)\ **Post date:** [Mars 12, 2024, 9:20 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687/5 "2024-03-12T09:20:49Z")
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? ---
**Author:** ![Sputnik93](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@Sputnik93](https://www.debian-fr.org/u/Sputnik93)\ **Post date:** [Mars 12, 2024, 9:37 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687/6 "2024-03-12T09:37:14Z")
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` ---
**Author:** ![mavric](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mavric/32/5276_2.png) [@mavric](https://www.debian-fr.org/u/mavric)\ **Post date:** [Mars 12, 2024, 10:22 UTC](https://www.debian-fr.org/t/debian-failed-to-stard-system-security-services-daemon/89687/7 "2024-03-12T10:22:50Z")
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.