I am running RHEL 7 Server so that I can also run Red Hat Satellite. I seem to be having resource contention problems and auditd is a part of the problem consuming up to 22.0% according to results of the *top* command.

I have: 1. executed a *systemctl disable auditd; systemctl stop auditd* (with an error about dependencies)

2. executed a *service auditd stop (*and the service stops but doesn't not remain stopped).

3. Rebooting the machine after the *systemctl disable auditd *also didn't have any effect.

I did set -e 1 in the audit.rules file so that I could stop the auditd on my demand, but the service restarts anyway. Thanks for your help in advance. -------------------------- Warron French

I am running RHEL 7 Server so that I can also run Red Hat Satellite. I seem to be having resource contention problems and auditd is a part of the problem consuming up to 22.0% according to results of the *top* command.

I have:     1. executed a *systemctl disable auditd; systemctl stop auditd*  (with     an error about dependencies)

    2. executed a *service auditd stop (*and the service stops but doesn't     not remain stopped).

    3. Rebooting the machine after the *systemctl disable auditd *also     didn't have any effect.

I did set -e 1 in the audit.rules file so that I could stop the auditd on my demand, but the service restarts anyway. Thanks for your help in advance. -------------------------- Warron French

On Friday, August 4, 2017 4:06:56 PM EDT warron.french wrote: > Hello Steve, I am not running Puppet on this system. Specifically because > it is to be built as my newer RH Satellite 6.2.10 server. > > The *flush* variable has been set to > *data.* I'd recommend INCREMENTAL_ASYNC if the audit package > 2.5. If not, change to INCREMENTAL and things should be a lot smoother. If you have INCREMENTAL_ASYNC, set freq to 100. If not then set it to 250 or 500. > I am using an image built by a coworker, but as I said we are not running > Puppet on this particular host - guaranteed. What other sort of systems > management tools can I check for? There's a lot. Maybe Satellite is doing it? I've never used Satellite so this is wild speculation. You can set a rule to audit access to /usr/lib/systemd/ system/auditd.service and perhaps you might find out who's doing it. Also, how do you know that auditd is restarted? Are you judging by syslog or audit logs? -Steve > On Fri, Aug 4, 2017 at 3:31 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > On Thursday, August 3, 2017 5:12:39 PM EDT warron.french wrote: > > > I am running RHEL 7 Server so that I can also run Red Hat Satellite. > > > > > > I seem to be having resource contention problems and auditd is a part of > > > the problem consuming up to 22.0% according to results of the *top* > > > > command. > > > > I'd be curious what the flush technique is in auditd.conf. > > > > > I have: > > > 1. executed a *systemctl disable auditd; systemctl stop auditd* > > > (with > > > an error about dependencies) > > > > "service auditd stop" is the correct way to stop auditd. > > > > > 2. executed a *service auditd stop (*and the service stops but > > > doesn't > > > not remain stopped). > > > > Do you have some systems management software that is sneaking in behind > > you > > and modifying settings and starting it? > > > > > 3. Rebooting the machine after the *systemctl disable auditd *also > > > didn't have any effect. > > > > It should. I don't know how else it could get re-enabled without some > > systems > > management software also configuring it when you're not looking. > > > > -Steve > > > > > I did set -e 1 in the audit.rules file so that I could stop the auditd > > > on > > > my demand, but the service restarts anyway. > > > > > > > > > Thanks for your help in advance. > > > -------------------------- > > > Warron French