[Pkg-sssd-devel] Bug#877164: sssd: login is impossible if directory '/var/log/sssd' is missing

[VANOSTA Vincent]

Package: sssd
Version: 1.11.7-3

Dear Maintainer,

   * What led up to the situation?
If, by mistake I delete the directory '/var/log/sssd' (for example doing 'rm -rf /var/log/' because the '/var/log/' (separate) partition is full on a Desktop PC, at the next boot of a Debian Jessie Gnome, login is no more possible, and it produce this error in /var/log/syslog :

sssd: Could not open file [/var/log/sssd/sssd.log]. Error: [2][No such file or directory]
systemd[1]: sssd.service: control process exited, code=exited status=7
systemd[1]: Unit sssd.service entered failed state.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
The fix is to login as root in console-mode (CTRL+ALT+F1) and just recreate the directory :
mkdir /var/log/sssd
and reboot
Then we can login again with gnome.

Our sssd config is to ask a ldap, and if the ldap is unavailable, use the cache. 

   * What was the outcome of this action?
   * What outcome did you expect instead?
I agree it's a mistake to delete /var/log/sssd , but I presume I'm not the only one to do this to clean a /var/log/ partition on a Desktop PC, and for the other packages producing logs, It's safe to do it.
It seems an easy fix for the sssd developper(s) to verify the directory presence at startup, and recreate it if it's missing, no ? (And by the way many thanks for this very usefull package !) 

We have observed this behavior on different computers in our organization, all running Debian Jessie with Gnome.
Last time we observed it, the PC had for kernel version : 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux, libc6 Version: 2.19-18+deb8u10 and sssd Version: 1.11.7-3
 

Sincerely yours,


Vincent