#1606 SSSD starts multiple processes due to syntax error in ldap_uri
Closed: Invalid None Opened 10 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

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

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.