CentOS Stream 8 sssd.service failing part of sssd-common-2.8.1-1.el8.x86_64 baseos package
Hello everybody,
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.
What is the best way to report this issue and when can we expect an update from the sssd-common package for this regression bug?
I think sssd-common is part of the baseos repository and installed even when the configuration file is not installed.
If someone can also provide more details on this issue I would appreciate it.
Thank you all in advance,
Kind regards,
Jelle de Jong
# cat /var/log/dnf.log | grep sssd-common 2022-11-25T06:29:42+0100 DEBUG Upgraded: sssd-common-2.7.3-5.el8.x86_64 2022-11-25T06:29:42+0100 DDEBUG /var/cache/dnf/baseos-055ffcb2ec25a27f/packages/sssd-common-2.7.3-5.el8.x86_64.rpm removed 2022-11-26T06:08:38+0100 DEBUG Upgraded: sssd-common-2.7.3-5.0.1.el8.x86_64 2022-11-26T06:08:38+0100 DDEBUG /var/cache/dnf/baseos-055ffcb2ec25a27f/packages/sssd-common-2.7.3-5.0.1.el8.x86_64.rpm removed 2022-12-25T06:23:42+0100 DEBUG Upgraded: sssd-common-2.8.1-1.el8.x86_64 2022-12-25T06:23:43+0100 DDEBUG /var/cache/dnf/baseos-055ffcb2ec25a27f/packages/sssd-common-2.8.1-1.el8.x86_64.rpm removed
# cat /etc/os-release NAME="CentOS Stream" VERSION="8" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Stream 8" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://centos.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 8" REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"
# cat /var/log/sssd/sssd.log (2022-12-25 6:23:34): [sssd] [monitor_quit_signal] (0x3f7c0): Monitor received Terminated: terminating children (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Returned with: 0 (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Terminating [nss][302626] (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Child [nss] terminated with a signal (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Terminating [implicit_files][302625] (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Child [implicit_files] terminated with a signal [sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error! [sssd] [get_monitor_config] (0x0010): Failed to expand application domains [sssd] [confdb_get_domains] (0x0020): No domains configured, fatal error! [sssd] [get_monitor_config] (0x0010): No domains configured. [sssd] [main] (0x0010): SSSD couldn't load the configuration database [1432158246]: No domain is enabled
# cat /var/log/sssd/sssd.log (2022-12-25 6:23:34): [sssd] [monitor_quit_signal] (0x3f7c0): Monitor received Terminated: terminating children (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Returned with: 0 (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Terminating [nss][302626] (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Child [nss] terminated with a signal (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Terminating [implicit_files][302625] (2022-12-25 6:23:34): [sssd] [monitor_quit] (0x3f7c0): Child [implicit_files] terminated with a signal [sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error! [sssd] [get_monitor_config] (0x0010): Failed to expand application domains [sssd] [confdb_get_domains] (0x0020): No domains configured, fatal error! [sssd] [get_monitor_config] (0x0010): No domains configured. [sssd] [main] (0x0010): SSSD couldn't load the configuration database [1432158246]: No domain is enabled
# 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 Sun 2022-12-25 06:23:35 CET; 9h ago Main PID: 615303 (code=exited, status=4)
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?
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 -halt /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/sssd.conf ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
# journalctl -u sssd.service --lines 100000 -- Logs begin at Mon 2022-12-26 22:15:31 UTC, end at Fri 2022-12-30 11:05:26 UTC. -- -- No entries --
Kind regards,
Jelle de Jong
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.
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
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@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
[root@nginx01 ~]# rpm -ivh --force sssd-common-2.8.1-1.el8.x86_64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:sssd-common-2.8.1-1.el8 ################################# [100%]
[root@nginx01 ~]# ls -hal /etc/sssd/sssd.conf
Kind regards,
Jelle ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
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@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
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@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.
Jelle
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@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.
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.
Regards, Simon
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@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.
Kind regards,
Jelle de Jong
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@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
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 -halt /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/sssd.conf ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
# journalctl -u sssd.service --lines 100000 -- Logs begin at Mon 2022-12-26 22:15:31 UTC, end at Fri 2022-12-30 11:05:26 UTC. -- -- No entries --
Kind regards,
Jelle de Jong
I don't quite understand where this: Main PID: 3953157 (code=exited, status=4)
came from. As it seems like sssd was started at some point and failed. But that shouldn't have happened because:
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
It's telling you that because /etc/sssd/sssd.conf does not exist and /etc/sssd/sssd.conf.d is not empty, the service was not started because the conditions were not met. This is as expected in your case.
If you don't want it to even check, just disable the service:
systemctl disable sssd.service
I'm not sure which of these or both that your service monitoring is keying off of. And perhaps by disabling it your monitoring system will be quiet about it.
Am 13.01.23 um 05:34 schrieb Orion Poplawski:
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 -halt /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/sssd.conf ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
# journalctl -u sssd.service --lines 100000 -- Logs begin at Mon 2022-12-26 22:15:31 UTC, end at Fri 2022-12-30 11:05:26 UTC. -- -- No entries --
Kind regards,
Jelle de Jong
I don't quite understand where this: Main PID: 3953157 (code=exited, status=4)
came from. As it seems like sssd was started at some point and failed. But that shouldn't have happened because:
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
It's telling you that because /etc/sssd/sssd.conf does not exist and /etc/sssd/sssd.conf.d is not empty, the service was not started because the conditions were not met. This is as expected in your case.
If you don't want it to even check, just disable the service:
systemctl disable sssd.service
Before doing this; @OP: what's the output of:
# authselect current
On 1/13/23 11:52, Leon Fauster via CentOS wrote:
Am 13.01.23 um 05:34 schrieb Orion Poplawski:
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 -halt /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/conf.d/ total 8.0K drwx--x--x. 2 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 . drwx------. 4 sssd sssd system_u:object_r:sssd_conf_t:s0 4.0K Dec 8 13:08 .. # ls -halZ /etc/sssd/sssd.conf ls: cannot access '/etc/sssd/sssd.conf': No such file or directory
# journalctl -u sssd.service --lines 100000 -- Logs begin at Mon 2022-12-26 22:15:31 UTC, end at Fri 2022-12-30 11:05:26 UTC. -- -- No entries --
Kind regards,
Jelle de Jong
I don't quite understand where this: Main PID: 3953157 (code=exited, status=4)
came from. As it seems like sssd was started at some point and failed. But that shouldn't have happened because:
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
It's telling you that because /etc/sssd/sssd.conf does not exist and /etc/sssd/sssd.conf.d is not empty, the service was not started because the conditions were not met. This is as expected in your case.
If you don't want it to even check, just disable the service:
systemctl disable sssd.service
Before doing this; @OP: what's the output of:
# authselect current
]# authselect current Profile ID: sssd Enabled features: None
I wrote the following Ansible code to automate disabling the sssd service.... I still consider this a regression as it just started apearing on all the systems.
- name: get sssd service status ansible.builtin.systemd: name: sssd.service register: sssd
- name: disable sssd.service service status ansible.builtin.systemd: name: sssd.service enabled: false state: stopped when: - sssd.status.ActiveState is defined - sssd.status.ActiveState == "failed"
- name: systemctl reset-failed command: systemctl reset-failed args: warn: false when: - sssd.status.ActiveState is defined - sssd.status.ActiveState == "failed"
-
Gordon Messmer -
Jelle de Jong -
Leon Fauster -
Orion Poplawski -
Simon Matter