On Tue, 24 Dec 2024 10:32:13 -0500 "Brian J. Murrell via FreeIPA-users" <[email protected]> wrote:
> On Fri, 2024-12-20 at 12:26 -0500, Brian J. Murrell via FreeIPA-users > wrote: > > In fact, checking on it again just now it seems to be even worse: > > > > … > > > > As you can see, it's a massive sustained write and tps rate and now > > maxing out the disk mostly constantly. This cannot be normal in any > > circumstance, never mind a tiny little installation such as I have, > > can > > it? > > Since this issue seems to be eluding folks here, any suggestions on > where else I should take this issue that people might have more insight > or be able to suggest how to debug more deeply? I really need this > disk hammering to stop. I cannot dedicate an entire disk to this > process just because it wants to hammer away at a disk and since nobody > else seems to be reporting the same I have to believe that my system is > anomalous in this regard. > > Cheers, > b. > I'm just a user so I might not be able to help you much, I left it to the more experienced devs which know more about it, but what I would do: From the 389-ds access log you sent, you can see the IP of the client that's generating the requests (10.75.22.247) What's weird to me is that I looked at my own server and I couldn't find the same SRCH bases as you have in my access logs for the past 10 days, and I have about 20 hosts enrolled and alive. The particular SRCH strings I looked for are: 'replication agreement' 'replication changelog' 'pbac' couldn't find them in my logs. My hunch is it's as if something is continuously scanning your directory. Maybe something malicious trying to download all accessible data. I'd first confirm that the IP connecting is one of your own. Then connect to that IP and tcpdump for connections to port 389 or 686 of your IPA server (389-ds ports). I think only sssd should be initiating connections to LDAP. Maybe also certmonger. Try shutting down sssd (and/or certmonger) on that client and see if load goes down. If still no, look at the IPs of clients connecting in 389-ds access log again, and shut that client down, repeat until you bring the load down to normal, which is almost 0 at least on my system. Then you know which client(s) are causing the issue. Then increase debug_level in sssd.conf (read sssd.conf man page) gradually and look at the client's sssd logs. Maybe you can track down what is causing the excessive requests on the client. What exactly to look for I don't know but maybe you will have some clues there. If the IP is of a IPA server or replica, that's a whole different can of worms I don't know much about. There are lots of things on a IPA server that connect to LDAP, you can try shutting down each service one by one (httpd, pki-tomcat, named, ...)
pgpfN4wfkiiQx.pgp
Description: OpenPGP digital signature
-- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
