#1708 sssd components seem to mishandle sighup
Closed: Fixed None Opened 6 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
/var/log/sssd/sssd.log
sssd_nss 1341 root   18w   REG              253,1      626    547
/var/log/sssd/sssd_nss.log
[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
/var/log/sssd/sssd_nss.log
[root@sldn6016nap]/var/log/sssd# lsof -p `pgrep -x sssd`|grep log
sssd    1272 root    3w   REG              253,1        0    639
/var/log/sssd/sssd.log
[root@sldn6016nap]/var/log/sssd# lsof -p `pgrep -x sssd_be`|grep log
sssd_be 1300 root  mem    REG              253,0    18808 664000
/usr/lib64/sasl2/liblogin.so.2.0.23
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
/var/log/sssd/sssd_UNIXUBSNETKRB5.log
sssd_be 1300 root   28w   REG              253,1        0    546
/var/log/sssd/ldap_child.log
[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
2012
Install Date: Tue Nov 27 06:17:50 2012         Build Host:
x86-009.build.bos.redhat.com
Group       : Applications/System           Source RPM:
sssd-1.8.0-32.el6.src.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
created)

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

2 years ago

Login to comment on this ticket.

Metadata