Setup is as follows:

Slackware 13.0 DomU
* running Samba (acting as domain controller)
* running OpenLDAP as backend for Samba

When I first boot up the DomU the /etc/rc.d/rc.syslog script will start successfully. /dev/log exists, logging works, the whole nine yards.

Whenever the syslogd process is killed (i.e., during log rotation) the process fails to start back up. /dev/log is no where to be found and there are no log messages being written to disk.

I've discovered that stopping the slapd process (OpenLDAP server) and then trying to start the syslogd process works.

If I try to start the syslogd process whenever slapd process is running syslogd fails with "network logging disabled (syslog/udp service unknown)".

Enabling network logging doesn't fix the problem. I've also tried changing the log settings for the slapd process to no avail. I figured that stopping slapd, starting syslogd, and then starting slapd would yield some meaningful log messages about what the two are doing. I get nothing. The processes don't complain and will work happily if started in a specific order.

Has anyone else experienced this problem? It sounds like a race condition but I have no idea where to look to fix it. I could set up my log rotation with post and pre events whenever the logs are rotated but this doesn't seem right and smacks too much of being a band-aid fix.

I'm not sure if this will help, but here goes. The error message 'network logging disabled' is fatal to syslogd startup. It happens if it is unable to resolve the service 'syslog', protocol 'udp'. This is true whether or not you are doing network logging.

On most systems this lookup is done by reading /etc/services. Check your file, but I suspect you do have a "syslog/udp" entry in /etc/services.

Is it possible that slapd is changing how service names are looked up? (I have never used the server part of LDAP.) If it redirects the getservbyname() lookup library call to some other database (rather than /etc/services), and that doesn't have syslog/udp in it, that could explain what you are seeing. So now I'm thinking you should check /etc/nsswitch.conf to see how service names are resolved.

Thanks for the reply ljb643.

I should have mentioned that the /etc/services file did have the correct line:

syslog 514/udp

But the other file you mention /etc/nsswitch.conf. Thanks for bringing that to my attention. Now that you mention it I did have to make changes to this file in order to get LDAP authentication working for Slackware.

The following line was causing the grief in the /etc/nsswitch.conf file:

services: ldap [NOTFOUND=return] files

Changing it to:

services: ldap [NOTFOUND=continue] files

fixes the problem.

Looking at this file now the [NOTFOUND=return] action may not be entirely correct for a lot of the lines present. I'll look through the file and try to determine which of these I can either remove the ldap service or change the action for. I'm actually thinking that I should just switch the databases to look in the files first then try the LDAP directory.