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?
Â
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.
