After switching several servers over from APF to CSF, my colleagues and I noticed that there are times during the day that LFD just chews away CPU, even while the process claims it’s “sleeping”:

root 15785 35.6 0.1 194496

93104 ? Ss 00:00 474:54 lfd – sleeping

35.6% CPU? What is it possibly doing?

In one of their FAQs, one of the developers from ConfigServers recommended disabling the following features in the csf.conf file, one by one to help narrow it down:

LF_DIRWATCH = “0”
CT_LIMIT = “0”
LF_HTACCESS = “0”
LF_MODSEC = “0”
LF_DIRWATCH_FILE = “0”
PT_LIMIT = “0”

Now, we already had these disabled – our use of LFD is limited to the downloading of global allow/deny lists only, as we don’t wish to use CSF for login failure detection at this time. So it was a bit puzzling at why, even with the main functionality of LFD disabled, it was using so much CPU.

An strace against LFD’s PID gave us the answer – it showed that LFD was continually parsing the various log files on the server, seemingly in a never-ending loop. This appeared to correlate with the “LD_PARSE” value of 5 seconds. When your servers are as large and busy as ours, your log files tend to be huge – and there’s no way that CSF is parsing those logs in 5 seconds or less.

To resolve this, we set the LF_PARSE value a bit higher to allow it to rest a bit. Since we aren’t using LFD for login failure tracking, we essentially do not have a need for it to frequently scan the server’s logs. We haven’t had a problem with LFD since.