Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sssd_be sent sigterm, no response, sssd dies #3538

Closed
sssd-bot opened this issue May 2, 2020 · 0 comments
Closed

sssd_be sent sigterm, no response, sssd dies #3538

sssd-bot opened this issue May 2, 2020 · 0 comments

Comments

@sssd-bot
Copy link

sssd-bot commented May 2, 2020

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2496


Logs from the error: http://fpaste.org/151535/

This appears to only occur on CentOS 5, I haven't had the issue on CentOS 6. We just recently updated to CentOS 5.11, this symptom was not resolved (it was a preexisting issue).

There is no known cause for this. After the failure (at the end of the logs, the repeated ping fail message), sssd will no longer respond to anything, so ssh ceases to function.

Comments


Comment from lslebodn at 2014-11-18 14:03:07

Replying to [ticket:2496 acidrainfall]:

Logs from the error: http://fpaste.org/151535/

The contents of this paste have been hidden

cc: => lslebodn@redhat.com


Comment from acidrainfall at 2014-11-18 18:56:10

Sorry, I haven't used fpaste before. Try this URL.
http://fpaste.org/151535/41625444/


Comment from acidrainfall at 2014-11-18 20:21:52

sssd_ssh.log:
http://fpaste.org/151913/

sssd_pam.log:
http://fpaste.org/151917/

sssd_nss.log:
http://fpaste.org/151915/

sssd_default.log:
http://fpaste.org/151918/


Comment from acidrainfall at 2014-11-18 20:40:46

sssd_ssh.log before the failure:
http://fpaste.org/151923/

sssd_pam.log before the failure:
http://fpaste.org/151922/

These are the only two entries that exist prior to the explosion in the 17:00 hour.

I've spread out some more debug_level = 8 settings on a bunch of centos5 systems, I'm hoping one fails soon and we can put this to bed.


Comment from lslebodn at 2014-11-20 15:34:23

Fields changed

owner: somebody => lslebodn


Comment from lslebodn at 2014-12-11 08:07:15

I apologise for late response. Unfortunately, it is not possible to say where exactly is the problem.

Do you have a log files with higher debug level. I would be interested in domain log file (sssd_default.log) and monitor log file(sssd.log)

Which version of sssd do you use?


Comment from acidrainfall at 2015-01-09 18:06:56

Apologies - I thought I had updated this previously.

I run sssd-1.9.6-0.el5

Since ~7 weeks ago I've had a dragnet set up to try to catch the error and none of the systems have failed. We also recently upgraded to CentOS 5.11, which actually may have fixed it. I don't know if it will happen again, but go ahead and close this ticket.


Comment from jhrozek at 2015-01-09 19:26:07

OK, I'm going to close the ticket.

Thank you very much for reporting the issue nonetheless. If you run across the problem again, don't hesitate to open a new ticket or reopen this one.

resolution: => worksforme
status: new => closed


Comment from acidrainfall at 2017-02-24 14:29:13

Metadata Update from @acidrainfall:

  • Issue assigned to lslebodn
  • Issue set to the milestone: NEEDS_TRIAGE
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant