> > > On 1/9/23 17:45, Simon Matter wrote: >>> On 1/3/23 13:41, Simon Matter wrote: >>>>> On 1/3/23 05:17, Orion Poplawski wrote: >>>>>> On 12/30/22 04:06, Jelle de Jong wrote: >>>>>>> On 12/27/22 22:55, Gordon Messmer wrote: >>>>>>>> On 2022-12-25 07:44, Jelle de Jong wrote: >>>>>>>>> A recent update of the sssd-common-2.8.1-1.el8.x86_64 package is >>>>>>>>> causing sssd.service systemctl failures all over my CentosOS >>>>>>>>> machines. >>>>>>>> ... >>>>>>>>> [sssd] [confdb_expand_app_domains] (0x0010): No domains >>>>>>>>> configured, >>>>>>>>> fatal error! >>>>>>>> >>>>>>>> >>>>>>>> Were you previously using sssd? Or is the problem merely that it >>>>>>>> is >>>>>>>> now reporting an error starting a service that you don't use? >>>>>>>> >>>>>>>> Are there any files in /etc/sssd/conf.d, or does >>>>>>>> /etc/sssd/sssd.conf >>>>>>>> exist? If so, what are the contents of those files? >>>>>>>> >>>>>>>> What are the contents of /usr/lib/systemd/system/sssd.service? >>>>>>>> >>>>>>>> If you run "journalctl -u sssd.service", are there any log entries >>>>>>>> older than the package update? >>>>>>> >>>>>>> I got a monitoring system for failing services and I sudenly >>>>>>> started >>>>>>> getting dozens of notifications for all my CentOS systems that sssd >>>>>>> was failing. This is after the sssd package updates, causing this >>>>>>> regression. SSSD services where not really in use but some of the >>>>>>> common libraries are used. >>>>>>> >>>>>>> # systemctl status sssd >>>>>>> ● sssd.service - System Security Services Daemon >>>>>>> Loaded: loaded (/usr/lib/systemd/system/sssd.service; >>>>>>> enabled; >>>>>>> vendor preset: enabled) >>>>>>> Active: failed (Result: exit-code) since Sat 2022-12-24 >>>>>>> 06:14:10 >>>>>>> UTC; 6 days ago >>>>>>> Condition: start condition failed at Fri 2022-12-30 11:02:01 UTC; >>>>>>> 4s >>>>>>> ago >>>>>>> ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not >>>>>>> met >>>>>>> └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was >>>>>>> not >>>>>>> met >>>>>>> Main PID: 3953157 (code=exited, status=4) >>>>>>> >>>>>>> Warning: Journal has been rotated since unit was started. Log >>>>>>> output >>>>>>> is incomplete or unavailable. >>>>>> >>>>>> >>>>>>> # ls -halZ /etc/sssd/sssd.conf >>>>>>> ls: cannot access '/etc/sssd/sssd.conf': No such file or directory >>>>>> >>>>>> Looks like you need to figure out what happened to your >>>>>> /etc/sssd/sssd.conf file. FWIW - I've updated my one CS8 machine to >>>>>> 2.8.1-1 and it seems to be fine. >>>>> >>>>> I did not do anything specific to the configuration file. I tried to >>>>> reinstall the new sssd-common pacakge, but it will not install the >>>>> /etc/sssd/sssd.conf file. I can not remove the package because it >>>>> will >>>>> remove a lot of packages that I do need. I still think something is >>>>> wrong with the new sssd packages.. >>>>> >>>>> [root at nginx01 ~]# rpm -qplc sssd-common-2.8.1-1.el8.x86_64.rpm >>>>> /etc/logrotate.d/sssd >>>>> /etc/pam.d/sssd-shadowutils >>>>> /etc/rwtab.d/sssd >>>>> /etc/sssd/sssd.conf >>>> >>>> Most likely the file /etc/sssd/sssd.conf is a ghost file and therefore >>>> it's not installed but only recognized as being part of the package. >>>> >>>> Simon >>> >>> I do not get this. There has nog been an /etc/sssd/sssd.conf on my >>> system before as it only installed sssd-common due to dependencies for >>> other libaries. I do not use the sssd service. The package gets an >>> update and now my systemd status is failing on a lot of systems and I >>> am >>> being tolled I should get /etc/sssd/sssd.conf sorted? >>> >>> Can you fix the sssd package by either not enabling the sssd systemd >>> service or some other solution that does not make systemd status fail? >>> >>> This is a regression and it is going to cause me a lot of time now to >>> write ansible code for the disabling of the sssd service on all systems >>> that have it installed due to dependencies but do not use it. >>> >>> sssd.services failing regressions and dfn-automatic.serivces failing >>> regressions due to freeipa/sssd/samba conflicts for months now. >> >> Do you have a file /etc/sssd/sssd.conf? IIRC you said you don't have >> such >> a file, which is fine. > > no file is there. > >> Do you have any file in /etc/sssd/conf.d/? This directory should be >> empty >> but it's possible that another package puts something there. > > no files are there. Maybe you can check for a difference in sssd.service from the older package and the current one. It seems that there was a change which results in the behavior you see. Regards, Simon