#1606 SSSD starts multiple processes due to syntax error in ldap_uri
Closed: Invalid None Opened 7 years ago by jhrozek.

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):

How reproducible:

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
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:

Fields changed

blockedby: =>
blocking: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
milestone: NEEDS_TRIAGE => SSSD 1.9.3
testsupdated: => 0

Fields changed

owner: somebody => okos
status: new => assigned

Ondra, can you check if it's still the case after today's pushes and close as worksforme if not?

fixed by 715e09e and e02ec73

resolution: => worksforme
status: assigned => closed

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

2 years ago

Login to comment on this ticket.