Bug 185433

That's a bad idea.  Running restorecon would only unnecessarily slow
nscd startup down in the 99.99% cases where files are properly labeled.
Audit messages if SELinux denies access to some file are IMHO quite informative.

I thought that restorecon runs quickly enough, and nscd is started rarely
enough, that a small delay would be acceptable in order to prevent certain
classes of errors.

I noticed that Red Hat takes a similar approach for other services now - ldap,
dhcp, and httpd all perform certain checks before starting or restarting in
order to cut down on configuration errors.  Since nscd is a core system
component, I thought it would be worth taking the same approach here.

I don't think that the system is as informative as it should be when trying to
diagnose these kinds of errors - nscd gives no error messages to the console or
syslog, name lookups comes back negative rather than failing with any sort of
error message, name resolution works when nscd isn't running but fails when it
is (I wouldn't expect a cache to alter behavior in this manner).  The audit
messages are informative, but I may not check the syslog immediately in case of
an error, and the audit messages are only logged at boot (which may be due to
some other bug on my system).

I'd like to see RHEL make it easier to diagnose or prevent this condition.  If
calling restorecon in /etc/init.d/nscd isn't the way to do it, then could I log
an RFE for what I perceive as some of the other problems that I listed above
(lack of messages from nscd, name lookups coming back negative instead of
failing, etc.)?

Thank you.