Score:1

LDAP: Why does slapcat truncate my slapd.log file?

cn flag

I have an OpenLDAP 2.4 server running on Ubuntu 18.04 LTS. Everytime I run

# slapcat -l test.ldif

my slapd.log file gets truncated (i. e. previous log messages are deleted and new ones are written at the beginning of the file).

Actually, the first line of slapd.log shows slapcat's output:

# head /var/log/slapd.log
620ca0f1 The first database does not allow slapcat; using the first available one (2)
Feb 16 08:00:15 srv21449 slapd[2096]: conn=274238 op=552602 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Feb 16 08:00:15 srv21449 slapd[2096]: conn=274238 op=552602 SRCH attr=1.1

That leads me to think the truncation of the file happens even before slapcat generates any output.

As far as I understand slapcat doesn't have anything to do with logging (which is done by slapd daemon), so I believe I'm missing something... Any ideas out there?

Edit #1: I run slapcat command with slapd running. At the moment I am not able to stop the service to check if this would happen when the daemon is not running. I read before that this should be avoided, but from slapcat's man page:

For some backend types, your slapd(8) should not be running (at least, not in read-write mode) when you do this to ensure consistency of the database. It is always safe to run slapcat with the slapd-bdb(5), slapd-hdb(5), and slapd-null(5) backends.

Running slapcat over a running slapd with bdb backend (my case) should be safe

Edit #2 Investigating a bit further, I tried to use auditctl to monitor accesses to slapd.log by adding a new audit rule:

# auditctl -w /var/log/slapd.log -k slapd

After running slapcat again I see this:

type=PROCTITLE msg=audit(1645437260.398:5558713): proctitle=736C6170636174002D6C00746573742E6C646966
type=PATH msg=audit(1645437260.398:5558713): item=1 name="/var/log/slapd.log" inode=131414 dev=fd:04 mode=0100640 ouid=0 ogid=4 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1645437260.398:5558713): item=0 name="/var/log/" inode=131074 dev=fd:04 mode=040775 ouid=0 ogid=106 rdev=00:00 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1645437260.398:5558713): cwd="/root"
type=SYSCALL msg=audit(1645437260.398:5558713): arch=c000003e syscall=257 success=yes exit=4 a0=ffffff9c a1=55e525c35410 a2=241 a3=1b6 items=2 ppid=69682 pid=73954 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=903297 comm="slapcat" exe="/usr/sbin/slapcat" key="slapd"

Last line of the audit shows there was an access by /usr/sbin/slapcat, so it confirms that slapcat is actually doing something with slapd.log. I'm starting to ask myself is this is just expected behaviour from running slapcat "hot" (i.e. not stopping the slapd service), even that it does not make much sense to me...

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.