0) commit ea0d9634 ("Update scriptlets to reload auditd service") made the %post and %postun scriptlets for setroubleshoot-server call /sbin/service. 1) commit 2c88c3ce ("Require initscripts-service - /sbin/service") added a dependency on /sbin/service in setroubleshoot.spec. 2) However, _if_ my reading of /sbin/service is correct, calling /sbin/service auditd reload is currently equivalent to calling /bin/systemctl reload auditd.service This suggests that the scriptlets could call systemctl directly and that the dependency on /sbin/service could be dropped. 3) I'm happy to open a pull-request for the trivial change to accomplish this. But I don't have setroubleshoot-server installed and have no clue how to test this change. So that pull request will be of little value.
Does bugzilla provide a way to make the initscripts maintainers aware of this report?
(In reply to Paul Bolle from comment #0) > 2) However, _if_ my reading of /sbin/service is correct, calling > /sbin/service auditd reload > > is currently equivalent to calling > /bin/systemctl reload auditd.service > # /bin/systemctl reload auditd.service Failed to reload auditd.service: Job type reload is not applicable for unit auditd.service.
(In reply to Paul Bolle from comment #1) > Does bugzilla provide a way to make the initscripts maintainers aware of > this report? According to https://src.fedoraproject.org/rpms/initscripts the main admin is lnykryn - I've added him to CC
https://src.fedoraproject.org/rpms/setroubleshoot/c/ea0d9634a3de5d296842a3dd22bad87994e77c2b """ When setroubleshoot sedispatch is installed, or updated, auditd needs to be reloaded so that it runs the new installed plugin. Since auditd needs to know who reloaded him, `systemctl` can't be used. We need to use `service` script. """ You need to solve this with auditd first
# /sbin/service auditd reload Redirecting to /bin/systemctl reload auditd.service Failed to reload auditd.service: Job type reload is not applicable for unit auditd.service. So it appears my reading of /sbin/service was correct. Dropping the dependency on /sbin/service and calling systemctl still seems warranted. Perhaps you could solve the underlying issue with auditd. But that is not what this report is about.
Please note that ">/dev/null 2>&1 || :" carries quite a bit of load in these scriptlets.
@sgrubb what is the current and correct way to reload auditd service ?
root@notas:~# service auditd reload Reconfiguring auditd: Auditd is not running root@notas:~# Audit daemon carries custom actions in /usr/libexec/initscripts/legacy-actions/auditd that can be executed via service command. I have no idea why it was redirected to systemctl in the comment #5
^^ This was on my f42 To be sure, I tried fresh rawhide, and there the reload via service also works: [root@vm-10-0-184-37 ~]# grep PRETTY /etc/os-release PRETTY_NAME="Fedora Linux 43 (Rawhide Prerelease)" [root@vm-10-0-184-37 ~]# /sbin/service auditd reload Reconfiguring auditd: [root@vm-10-0-184-37 ~]# BTW, we have those scripts because of logging. Audit wants to record what specific user did those actions like reload,stop.... And that can't be done through systemd because there the action is done by the systemd daemon, hence it would always be root.
Bother. comment #5 was misguided, sorry about that. When I run the commands properly I now get: # /sbin/service auditd reload Reconfiguring auditd: # systemctl reload auditd.service Failed to reload auditd.service: Job type reload is not applicable for unit auditd.service. (Which is what everyone else is seeing too.)
Auditctl supports sending signals to auditd. The legacy service scripts have all be reworked to use auditctl. /usr/sbin/auditctl --signal reload or service stop && service start
> /usr/sbin/auditctl --signal reload Which is basically all [...]/legacy-actions/auditd/reload does! So "/sbin/service auditd reload >/dev/null 2>&1 || :" in the specfile could be replaced with "/usr/sbin/auditctl --signal reload >/dev/null 2>&1 || :", right?
Yes. This way avoids a dependency on initscripts-service.
Thanks, just what I hoped to hear! Shall I open a pull request along those lines? (Trivial, but untested so it won't really lessen the workload of the setroubleshoot maintainers...)
(In reply to Paul Bolle from comment #14) > Shall I open a pull request along those lines? (Trivial, but untested so it > won't really lessen the workload of the setroubleshoot maintainers...) It's not necessary. I'll handle it. Thanks,
FEDORA-2025-725742cbcc (setroubleshoot-3.3.35-5.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-725742cbcc
FEDORA-2025-725742cbcc (setroubleshoot-3.3.35-5.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.