-
Notifications
You must be signed in to change notification settings - Fork 272
Description
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1606
https://bugzilla.redhat.com/show_bug.cgi?id=869466 (Red Hat Enterprise Linux 6)
Description of problem:
This behaviour was observed when sssd service failed to stop, due to a syntax
error in ldap_uri attribute. During every service restart, an additional sssd
process was produced. The syntax error was unintentional and upon correcting
it, sssd started working fine.
Version-Release number of selected component (if applicable):
sssd-1.9.2-3.el6.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Stop the sssd service, if running. Edit the domain section of sssd.conf file
and make a slight change in ldap_uri attribute. For example, take out the
forward-slash symbols from url:
ldap_uri = ldap:SERVER
2. Start sssd service. Strangely, service starts without any error.
# service sssd start
Starting sssd: [ OK ]
3. Check the status.
# service sssd status
sssd (pid 24952) is running...
4. Restart the sssd service. We will notice that sssd shows error while stoping
the service however, it starts without any error.
# service sssd restart
Stopping sssd: cat: /var/run/sssd.pid: No such file or directory
[FAILED]
Starting sssd: [ OK ]
5. Check the status again.
# service sssd status
sssd (pid 24994 24952) is running...
6. Restart and check the status again. SSSD starts a new process every time it
is restarted.
# service sssd status
sssd (pid 25039 24994 24952) is running...
7. Other backend processes does not exist, probably because of the syntax error
in sssd.conf file.
# ps -e | grep sss
24952 ? 00:00:00 sssd
24994 ? 00:00:00 sssd
25039 ? 00:00:00 sssd
Actual results:
During service restart, SSSD shows error on stopping the service, but it
successfully starts the process which i guess is not the expected behaviour.
Expected results:
Due to syntax error in ldap_uri, SSSD should not spawn multiple processes at
every restart.
Additional info:
Comments
Comment from dpal at 2012-10-25 15:20:10
Fields changed
blockedby: =>
blocking: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
milestone: NEEDS_TRIAGE => SSSD 1.9.3
testsupdated: => 0
Comment from okos at 2012-10-25 16:10:46
Fields changed
owner: somebody => okos
status: new => assigned
Comment from jhrozek at 2012-11-06 12:37:44
Ondra, can you check if it's still the case after today's pushes and close as worksforme if not?
Comment from okos at 2012-11-06 15:47:24
resolution: => worksforme
status: assigned => closed
Comment from jhrozek at 2017-02-24 14:55:17
Metadata Update from @jhrozek:
- Issue assigned to okos
- Issue set to the milestone: SSSD 1.9.3