Audit has always required that shutdown requests are in the user context. We absolutely have to log who is trying to alter the audit trail. This has been the case since 2004 and due to regulatory compliance that many people have to follow, we cannot change. There has been some discussion on bug 1727058 (which I am likely to close this as a duplicate of) about maybe a solution. But I doubt systemd will change. In the meanwhile, at least we don't have a dependency on chkconfig any more. :-)

seriously make it at least a soft dependency which would be pulled anyways in default setups

it's enough that this package is pulled to begin with on setups with "audit=0" and no intention to run the daemon at all but don't pull additional stuff

* two years ago usleep (/usr/bin/usleep is part of the pckage) started to fire deprecated messages
* one year ago /etc/init.d/network got deprecated
* it's for years on the fedora trail to get rid of init scripts
* /usr/sbin/service is deprecated long ago

and now months ofter we got rid of it on every single machine you are coming with "But I doubt systemd will change" and pull that old crap back again
ok, another "provides" hack in my metapackages, i become sick and tired facing any sysvinit crap in 2019

initscripts               /etc/rc.d/rc.local
seriously?

initscripts               /etc/sysconfig/console
initscripts               /etc/sysconfig/modules
seriously?

initscripts               /usr/lib/udev/rename_device
initscripts               /usr/lib/udev/rules.d/60-net.rules
seriously?

initscripts               /etc/rc.d/init.d/functions
seriously?

initscripts               /etc/rc.d/rc0.d
initscripts               /etc/rc.d/rc1.d
initscripts               /etc/rc.d/rc2.d
initscripts               /etc/rc.d/rc3.d
initscripts               /etc/rc.d/rc4.d
initscripts               /etc/rc.d/rc5.d
initscripts               /etc/rc.d/rc6.d
initscripts               /etc/rc0.d
initscripts               /etc/rc1.d
initscripts               /etc/rc2.d
initscripts               /etc/rc3.d
initscripts               /etc/rc4.d
initscripts               /etc/rc5.d
initscripts               /etc/rc6.d
seriously?

audit is not a mandatory package. Just remove it. As best I can tell, setroubleshoot-server is what requires it and nothing more. But this release fixed a dependency that was always there. Previously it was mistakenly placed on chkconfig.

[root@testserver:~]$ rpm -e audit
error: Failed dependencies:
        audit is needed by (installed) lynis-2.7.5-4.fc30.noarch

Any chance that the specification could be changed? The current state really does not make much sense. You can't directly tell systemd to stop audit, but you can do that indirectly. Just try: systemd-run -p "Conflicts=auditd.service" /bin/true

What do you mean, it doesn't make sense? :-)  The requirement is that we have to record who tampers with the audit trail. This is required by common criteria, pci-dss, DISA STIG, and virtually all security standards.

Wrt to the suggestion in comment #6, this is what results in the logs:

type=DAEMON_END msg=audit(01/28/2020 09:51:03.863:5558) : op=terminate auid=root pid=1 subj=system_u:system_r:init_t:s0 res=success

Using service command, we get this:

type=DAEMON_END msg=audit(01/28/2020 09:50:50.786:6323) : op=terminate auid=sgrubb pid=13675 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=success

Both the auid and subj are correct when using service command.

If there was a way for systemctl to directly send a signal to a pid when the service says to do so, that would solve the problem. But also, what would we do about the other service commands (all signal driven): rotate, resume, state-report, and reload? Auditd has very specific rules around log rotation and resuming logging. We have to know who issues those commands. The state report is a useful diagnostic tool to understand what auditd sees in its world. This one does not need to capture who run it as it does not alter the audit trail or configuration. But reloading the audit daemon's config does.

Note that on bug 1727058 comment #22 and later, it seemed like a solution was being considered. As I said in the other bug, I am not insisting that the solution must be initscripts. I'm will to change that. But I need something that meets requirements.

nice discussion but completly irrelevant outside of audit and so the *perfect* showcase for *weak* dependencies given that all of my setups have "install_weak_deps=0" for many years and are started with audit=0 in the kernel line, just don't pull any initscript stuff as hard requirement when it's not one and it's not

I am sorry, but these requirements are just weird: systemctl/service is just *one* command for changing state of auditd here, among many. Any client can do this via the bus API, and there are plenty which do, for example Cockpit, which we ship as part of RHEL. This means generation of the audit msg must be the service manager, not the client that generates these records, because there are so many different clients. But this means the audit msgs are generated by PID 1, i.e. as root. Which is what you are currently seeing.

A long time ago there were discussions about extending audit to allow a "on-behalf-of" field or something, so that PID 1 can fill in the client's identity there. But this never materialized, audit is kinda stalled in the upstream kernel?

Anyway, we can make PID 1 generate augmented records, but this requires preparation from the audit system for these fields which never happened. We cannot move generation to the client side, and doing that in the /usr/sbin/service command is just entirely bogus, because noone uses that anymore except of legacy sysv stuff.

So, it boils down to: do you actually care the record is properly generated always and unconditionally, i.e. reagrdless how exactly audit is started, which client is used, or do you just care about theatre, that when the legacy sysv command is started the msg is generated properly, but not when any more modern command is used nothing happens?

Anyway, it sucks that audit is in the base OS even though it's kinda stuck like this.

> If there was a way for systemctl to directly send a signal to a pid when the service says to do so, that would solve the problem. 

Just to make this very clear: this is not going to happen. systemctl is one client to systemd among many. Adding any such killing to the client side is not going to happen, and makes no sense at all. systemd is a client/server system, where the server maintains the services, and operates on the client's requests. And there are a variety of clients, systemctl and Cockpit are two prominent ones. Keeping a dependency on initscripts makes *no* sense already, simply because the /usr/bin/service tool is *not* *called* *by* *anyone* anymore, except for maybe some legacy sysv scripts. It is not called at boot for starting audit, and not called at shutdown when stopping audit. It's called by essentially noone. So why keep this dependency in? You just annoy everyone, without doing anything good. The ship on /usr/sbin/service has sailed.

> But also, what would we do about the other service commands (all signal driven): rotate, resume, state-report, and reload? Auditd has very specific rules around log rotation and resuming logging. We have to know who issues those commands. The state report is a useful diagnostic tool to understand what auditd sees in its world. This one does not need to capture who run it as it does not alter the audit trail or configuration. But reloading the audit daemon's config does.

Add your own tool for this, this has nothing to do with generic service management. Add a tool "auditcmd" or so that exposes these verbs if you need that. apache is doing something similar: the service file just starts/stops/restarts/reloads apache, i.e. the generic commands, for anything apache specific there's apachectl.