#1708 sssd components seem to mishandle sighup
Closed: Fixed None Opened 9 years ago by jhrozek.

https://bugzilla.redhat.com/show_bug.cgi?id=886038 (Red Hat Enterprise Linux 6)

Description of problem:

(customer provided, very nice i think):

sssd_nss and sssd_be fail to correctly reopen the file handle to
/var/log/sssd/sssd.log upon receiving a HUP signal.

I'm raising this against 6.3, but we see the same on RHEL 5 with sssd 1.5.1 and
need the fix there as well.

[root@sldn6016nap]/var/log/sssd# lsof -p `pgrep sssd_nss`|grep log
sssd_nss 1341 root    3w   REG              253,1      109    543
sssd_nss 1341 root   18w   REG              253,1      626    547
[root@sldn6016nap]/var/log/sssd# logrotate -f /etc/logrotate.d/sssd
[root@sldn6016nap]/var/log/sssd# lsof -p `pgrep sssd_nss`|grep log
sssd_nss 1341 root    3w   REG              253,1      109    543
/var/log/sssd/sssd.log.1 (deleted)
sssd_nss 1341 root   18w   REG              253,1        0    641
[root@sldn6016nap]/var/log/sssd# lsof -p `pgrep -x sssd`|grep log
sssd    1272 root    3w   REG              253,1        0    639
[root@sldn6016nap]/var/log/sssd# lsof -p `pgrep -x sssd_be`|grep log
sssd_be 1300 root  mem    REG              253,0    18808 664000
sssd_be 1300 root    3w   REG              253,1      109    543
/var/log/sssd/sssd.log.1 (deleted)
sssd_be 1300 root   18w   REG              253,1        0    545
sssd_be 1300 root   28w   REG              253,1        0    546
[root@sldn6016nap]/var/log/sssd# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
[root@sldn6016nap]/var/log/sssd# rpm -qi sssd
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.8.0                             Vendor: Red Hat, Inc.
Release     : 32.el6                        Build Date: Tue May 29 17:03:49
Install Date: Tue Nov 27 06:17:50 2012         Build Host:
Group       : Applications/System           Source RPM:
Size        : 7888642                          License: GPLv3+
Signature   : RSA/8, Wed May 30 03:05:21 2012, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon
Description :
Provides a set of daemons to manage access to remote directories and
authentication mechanisms. It provides an NSS and PAM interface toward
the system and a pluggable backend system to connect to multiple different
account sources. It is also the basis to provide client auditing and policy
services for projects like FreeIPA.
Version-Release number of selected component (if applicable):

How reproducible:

can be rperoduced every time, i am able to reproduce by simplifying (replacing
logrotate with the essential steps: mv, sighup)

Steps to Reproduce:
1. start sssd with nss support
2. rename the logfile it is currently wiriting to (mv)
3. send sighup to sssd_nss
4. check files open with lsof

Actual results:

the process is still keeping the old logfile (inode) open, in my tests it also
created the new file (old filename, new inode)

Expected results:

the proces should release the old file, and start logging to the new one (newly

Additional info: for any further info, please just ask me (irc: #gss:ssorin)

Fields changed

blockedby: =>
blocking: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
milestone: NEEDS_TRIAGE => SSSD 1.9.4
priority: major => minor
testsupdated: => 0

Fields changed

owner: somebody => jhrozek
patch: 0 => 1
status: new => assigned

resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.9.4

5 years ago

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/2750

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.