Friday, December 8, 2023

[389-users] Re: 389-ds-base name log pipe problems


I see two possible reasons why 389ds could intermittently stop listening on 389 port:
  [1] nearly all connections are exhausted. 
  [2] the server is blocked (probably trying to write in the pipe)

[1] is possible if most of the connections did not get released when the external system was stopped. (It can happen if the ip connection gets silently broken (typically by rebooting a switch) ) 
  In that case it is the fact of restarting 389ds that solved the issue.
[2] Would mean that the application that read the pipe was not able to read the data fast enough. (Either too much data were logged or there was an issue on that application)


On Thu, Dec 7, 2023 at 11:25 AM Nyquist <> wrote:

1. Stop directory server and remove access log file.
2. Run Python create access.pipe (pipe)
3. Change directory server settings
nsslapd-accesslog-maxlogsperdir: 1
nsslapd-accesslog-logexpirationtime: -1
nsslapd-accesslog-logrotationtime: -1
nsslapd-accesslog: /var/log/dirsrv/slapd-localhost/access.pipe
nsslapd-accesslog-logbuffering: off
4. Run directory server
=> Check normal execution, and are operating normally.

The problem arises after this. This server has consumed all connections. A forced shutdown of the external system returned the connection, and we expected it to work normally. However, port 389 health check failed intermittently. Joining and removing from the L4 switch is repeated. Could this be caused by my logging settings to pipe?
Or should I think it's a problem with the Linux file system?
389-users mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:


389 Directory Server Development Team

No comments:

Post a Comment