Comment 11 for bug 806761

Hi Clint,

I can see how first recommended change ("start on runlevel [2345]" and an if-up.d script) is an improvement: the if-up.d script makes sure we try to start nslcd *every* time an interface comes up, not just the *first* one.

However, I'm encountering another race condition with the if-up.d script in testing. Suppose we have two interfaces, a "good" interface that can connect us to the LDAP/Kerberos servers, and a "bad" interface that can't. If the "bad" interface comes up first, the nslcd job will start, and eventually terminate. However, it's possible the "good" interface will come up _while the nslcd job is in the process of failing_. If so, Upstart will see the nslcd job is running and refrain from launching a duplicate job, which means the nslcd service will never be launched without manual intervention.

Any ideas on how to resolve this? It seems like the if-up.d script needs to wait until the nslcd job was either in the "started" or "stopped" state--we can't assume the "starting" state is sufficient evidence that the job is completely run. This could be done with a loop similar to the one in the nslcd-kerberos post-start script, but hopefully you or someone else knows of a more elegant solution.

Also, in the point about the use of 'exit 1', you say, "Also a non-existant binary is not an error, so do not print anything or exit 1 for that." I can understand using 'stop; exit 0' instead of 'exit 1', but are you sure about the recommendation to not print anything? Many of my most frustrating troubleshooting sessions in Linux are related to services that fail to launch without providing any diagnostic output--I'm sure others have had the same experience. It seems like good practice to let the user/administrator know _why_ we can't start the service instead of failing silently.

Thanks for your time and attention to making this patch as robust and bullet-proof as possible. Every refinement gives me a warm fuzzy feeling. :D

-Caleb