Hide Forgot
Description of problem: For a long time, this situation went undetected: (Mon Jan 16 03:45:49 2017) [sssd[be[default]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' (Mon Jan 16 03:45:49 2017) [sssd[be[default]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) because nothing was logged to syslog about it. This is a failure situation and should be logged as such. Version-Release number of selected component (if applicable): sssd-1.14.0-43.el7_3.11.x86_64
You can do it even nowadays: * enable logging to journald @see /etc/systemd/system/sssd.service.d/journal.conf * set "debug_level = 1" in domain section of sssd.conf
I don't think this works because the syslog messages are marked as "debug" and don't go to /var/log/messages, but I'll test to make sure.
Confirmed, messages went to the journal, but with log level of "debug" and so didn't get logged to /var/log/messages.
(In reply to Orion Poplawski from comment #3) > Confirmed, messages went to the journal, but with log level of "debug" That's correct. I checked the source code and we always log with priority debug but we also set custom journald attribute SSSD_DEBUG_LEVEL. Maybe rsyslog can somehow consume additional attributes from journal
This appears to do the trick after enabling journal logging for sssd: # cat /etc/rsyslog.d/sssd.conf if ($!SSSD_DEBUG_LEVEL == "10" or $!SSSD_DEBUG_LEVEL == "20") then { action(type="omfile" file="/var/log/messages" template="RSYSLOG_TraditionalFileFormat") stop }
(In reply to Orion Poplawski from comment #5) > This appears to do the trick after enabling journal logging for sssd: > > # cat /etc/rsyslog.d/sssd.conf > if ($!SSSD_DEBUG_LEVEL == "10" or $!SSSD_DEBUG_LEVEL == "20") then { > action(type="omfile" file="/var/log/messages" > template="RSYSLOG_TraditionalFileFormat") > stop > } I don't think we should log debug messages to syslog, but only send very selectively chosen messages like we already do. I think what you described is an acceptable workaround and would prefer to close this bug. Do you agree?
The original intent of this bug was to request that sssd log to syslog that sssd has gone offline because it could not connect to any of the providers. It does not currently do so, and I think it should. If you disagree, I can continue to use my workaround.
Well, I'm not categorically against. We have other places in sssd where we log some action to syslog. I'm just wondering how to strike the balance for systems that go offline and online quite often (laptops) to avoid flooding the logs, but at the same time make the message usable in general. Do you think it would to log a LOG_NOTICE-level message?
Perhaps it could be paired with a configuration option like "sssd_warn_if_offline"?
Upstream ticket: https://fedorahosted.org/sssd/ticket/3307
QE: To reproduce, make SSSD go offline, e.g. by switching off the server SSSD is configured with. Check the syslog or journal for messages from SSSD, there should be one telling you that SSSD switched to offline mode. The details will be tbd, perhaps we'll implement two kind of notifications, one for disabling a particular domain and one for the global state (and mid-to-long term we'll be getting rid of the global state and only keep track of the online state per-domain)
master: * 1185cbce8d5dd04e539ca74d8f9564e5715a78aa * 60ec0db015c354349af445e0ec63f8b8421343fe
Verified with sssd-1.16.0-9.el7.x86_64 Verification Steps: 1. Configured ldap server. 2. Configure sssd client. 3. Make ldap server offline, by doing typo in ldap server url or stop running ldap server. 4. Check server status in domain log From domain logs, # cat /var/log/sssd/sssd_LDAP.log | grep 'offline' (Fri Dec 8 04:48:57 2017) [sssd[be[LDAP]]] [dp_get_options] (0x0400): Option ldap_offline_timeout has value 60 (Fri Dec 8 04:48:58 2017) [sssd[be[LDAP]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Fri Dec 8 04:48:58 2017) [sssd[be[LDAP]]] [be_mark_offline] (0x2000): Going offline! (Fri Dec 8 04:48:58 2017) [sssd[be[LDAP]]] [be_mark_offline] (0x2000): Initialize check_if_online_ptask. (Fri Dec 8 04:48:58 2017) [sssd[be[LDAP]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Fri Dec 8 04:48:58 2017) [sssd[be[LDAP]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Fri Dec 8 04:48:58 2017) [sssd[be[LDAP]]] [be_ptask_offline_cb] (0x0400): Back end is offline (Fri Dec 8 04:48:58 2017) [sssd[be[LDAP]]] [be_ptask_offline_cb] (0x0400): Back end is offline 5. Check the server status in syslogs From syslogs, # journalctl -xeu sssd Dec 08 04:49:59 ibm-x3650m4-01-vm-06.lab.eng.bos.redhat.com sssd[be[LDAP]][27985]: Backend is offline
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:0929