Learn more about these different git repos.
Other Git URLs
Recently, due to misconfiguration, my sssd service failed to start when initiated via
# systemctl start sssd
In /var/log/messages, there was
Jun 23 10:14:33 host systemd: Starting System Security Services Daemon... Jun 23 10:14:33 host sssd: Starting up Jun 23 10:14:33 host sssd[be[example.test]]: Starting up Jun 23 10:14:33 host sssd[nss]: Starting up Jun 23 10:14:33 host sssd[sudo]: Starting up Jun 23 10:14:33 host sssd[pam]: Starting up Jun 23 10:14:33 host sssd[pac]: Starting up Jun 23 10:14:33 host sssd[ssh]: Starting up Jun 23 10:14:39 host sssd[pac]: Shutting down Jun 23 10:14:39 host sssd[ssh]: Shutting down Jun 23 10:14:39 host sssd[pam]: Shutting down Jun 23 10:14:39 host sssd[sudo]: Shutting down Jun 23 10:14:39 host sssd[nss]: Shutting down Jun 23 10:14:39 host sssd[be[example.test]]: Shutting down Jun 23 10:14:39 host systemd: sssd.service: control process exited, code=exited status=1 Jun 23 10:14:39 host systemd: Failed to start System Security Services Daemon. Jun 23 10:14:39 host systemd: Unit sssd.service entered failed state.
Only when I looked to /var/log/sssd/sssd.log did I see the reason:
(Tue Jun 23 10:14:33 2015) [sssd] [service_startup_handler] (0x0010): Could not exec /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --debug-to-files, reason: No such file or directory
It'd be nice if the error that caused the service to fail to start was also available in the syslog, to make debugging of the startup issues a bit easier to detect.
Please note I'm not asking for general redirection of logging to journal which can be done via /etc/systemd/system/sssd.service.d/journal.conf, or degraded start, just some more verbose error reporting of failed start.
This was with sssd-1.12.2-58.el7.x86_64.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.14 beta
rhbz: => todo
Even better, sssd should have a fallback config, which is planned for 1.15
milestone: SSSD 1.14 beta => SSSD 1.15 beta
Replying to [comment:3 jhrozek]:
I'm not sure about that. If the admin edited their config, they likely want those clever changes to be used. Not have SSSD attempt to be smart and use different config.
But maybe I miss what the fallback would do.
Metadata Update from @adelton: - Issue set to the milestone: SSSD Future releases (no date set yet)
sssd-1.15.2 presents this info in /var/log/messages <<<<Wrong config file>>>> May 23 06:02:42 rhel7u4-3 systemd: Starting System Security Services Daemon... May 23 06:02:42 rhel7u4-3 sssd: SSSD couldn't load the configuration database [2]: No such file or directory. May 23 06:02:42 rhel7u4-3 systemd: sssd.service: main process exited, code=exited, status=4/NOPERMISSION May 23 06:02:42 rhel7u4-3 systemd: Failed to start System Security Services Daemon. May 23 06:02:42 rhel7u4-3 systemd: Unit sssd.service entered failed state. May 23 06:02:42 rhel7u4-3 systemd: sssd.service failed.
<<<Correct sssd.conf>>> May 23 06:02:00 rhel7u4-3 systemd: Starting System Security Services Daemon... May 23 06:02:01 rhel7u4-3 sssd: Starting up May 23 06:02:01 rhel7u4-3 sssd[be[gsslab.pnq2.redhat.com]]: Starting up May 23 06:02:01 rhel7u4-3 sssd[pac]: Starting up May 23 06:02:01 rhel7u4-3 sssd[sudo]: Starting up May 23 06:02:01 rhel7u4-3 sssd[ssh]: Starting up May 23 06:02:01 rhel7u4-3 sssd[nss]: Starting up May 23 06:02:01 rhel7u4-3 sssd[pam]: Starting up May 23 06:02:01 rhel7u4-3 systemd: Started System Security Services Daemon.
<<Stopping sssd>> May 23 06:02:12 rhel7u4-3 systemd: Stopping System Security Services Daemon... May 23 06:02:12 rhel7u4-3 sssd[be[gsslab.pnq2.redhat.com]]: Shutting down May 23 06:02:12 rhel7u4-3 sssd[nss]: Shutting down May 23 06:02:12 rhel7u4-3 sssd[sudo]: Shutting down May 23 06:02:12 rhel7u4-3 sssd[pam]: Shutting down May 23 06:02:12 rhel7u4-3 sssd[ssh]: Shutting down May 23 06:02:12 rhel7u4-3 sssd[pac]: Shutting down May 23 06:02:12 rhel7u4-3 systemd: Stopped System Security Services Daemon
With the example from the description we currently have:
Mai 23 13:58:33 f25.fed.devel sssd[29441]: Exiting the SSSD. Could not restart critical service [ifp].
@adelton, do you think this is sufficient information in the system log to close the ticket?
Metadata Update from @sbose: - Custom field design_review reset (from 0) - Custom field mark reset (from 0) - Custom field patch reset (from 0) - Custom field review reset (from 0) - Custom field sensitive reset (from 0) - Custom field testsupdated reset (from 0) - Issue close_status updated to: None
If you were able to also have there root cause (No such file or directory for exec of /usr/libexec/sssd/sssd_ifp), it's be great, but the error message you show will work as well.
No such file or directory for exec of /usr/libexec/sssd/sssd_ifp
We have to verify if this issue is still relevant
Metadata Update from @thalman: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field patch reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false) - Issue tagged with: Next milestone
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3728
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @pbrezina: - Issue close_status updated to: cloned-to-github - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.