Bug 1026648 - improve error message for RefuseManual*
improve error message for RefuseManual*
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
7.2
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: systemd-maint
Radka Skvarilova
: Patch, Reopened
Depends On:
Blocks: 1298243 74systemd 1393867
  Show dependency treegraph
 
Reported: 2013-11-05 02:08 EST by Petr Sklenar
Modified: 2017-08-01 05:09 EDT (History)
16 users (show)

See Also:
Fixed In Version: systemd-219-31.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 05:09:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Sklenar 2013-11-05 02:08:43 EST
Description of problem:
systemd refuses to restart auditd

Version-Release number of selected component (if applicable):
systemd-207-4.el7.x86_64
audit-2.3.2-3.el7.x86_64

How reproducible:
always
it was possible to restart auditd by systemctl in the past

Steps to Reproduce:
1. systemctl restart auditd.service


Actual results:
systemctl restart auditd.service
Failed to issue method call: Operation refused, unit auditd.service may be requested by dependency only.

Expected results:
I can restart auditd and any other service

Additional info:
I can restart via 'service' so it looks very inconsistent
# service auditd restart
Stopping logging:                                          [  OK  ]
Redirecting start to /bin/systemctl start auditd.service

# systemctl restart auditd.service
Failed to issue method call: Operation refused, unit auditd.service may be requested by dependency only.
Comment 3 Michal Schmidt 2013-11-05 07:37:20 EST
auditd.service requests this by setting RefuseManualStop=yes.

"service auditd restart" works only because the audit package ships a script to tell "service" about a special way to do it (/usr/libexec/initscripts/legacy-actions/auditd/restart).

The reason for this weird handling of restart requests is that auditd is treated specially by the kernel: the credentials of a process that sends a killing signal to auditd are saved to the audit log. The audit developers do not want to see the credentials of PID 1 logged there. They want to see the loginuid of the user who initiated the action.

This is not an optimal solution, but a better one would require a kernel feature that does not currently exist.
Comment 4 Petr Sklenar 2013-11-05 09:38:08 EST
Hmm interesting feature.

Is there is docs about such a differences between service and systemctl 
or
could it be created somewhere?
or
is it BUG/RFE to kernel (then change the component)?
Comment 5 Steve Grubb 2013-11-05 10:01:05 EST
Actually, the message coming out of systemd is not entirely helpful. Since its parsed the service file and seen the RefuseManualStop=yes, it could output something like: Unable to stop auditd.service, it's configured to refuse manual stops. This would at least point the user to the service rather than suspect something is wrong with systemd. It might prevent some bugs being filed under systemd.

That said, I suppose I could add something in the auditd man page that states it should be managed by the service command.
Comment 6 Michal Schmidt 2013-11-05 10:38:53 EST
Petr, if you're curious, see bug 881057 for a previous discussion about the special stopping requirements of auditd.
Comment 10 vikas027 2015-10-10 07:14:30 EDT
Not only restart, I can't even stop auditd service.

root@vikas027:~# systemctl stop auditd
Failed to issue method call: Operation refused, unit auditd.service may be requested by dependency only.
root@vikas027:~#
Comment 11 Steve Grubb 2015-10-11 18:18:38 EDT
In response to comment #10, this the correct behavior. When auditd gets a term signal, it has to query to see who sent the termination. You cannot get that over dbus, so we require it to be in the users context. Running the service command should do everything you need.

Systemctl start and status are about the only things you can safely use with auditd.
Comment 13 Steve Grubb 2016-10-13 10:21:59 EDT
Nothing can be done without kernel dbus. As far as I know, work has stopped on that. I can defer this to RHEL Next if you want to keep it open. But audit is not the component where the work needs to be done. Its the kernel.
Comment 15 Steve Grubb 2016-10-20 18:31:31 EDT
Just a reminder, there is nothing that can be done for this in the audit package. If any message cleanup is wanted, they come from systemctl and this bz needs to be reassigned or a new bz opened on systemd. If you want this to work correctly from systemctl, then it needs kdbus which is kernel work. Again not the audit package.
Comment 17 Lukáš Nykrýn 2016-11-01 04:40:48 EDT
There is nothing we can do in systemd, we only have the dbus daemon available, which is not trusted by the audit, so we can't send some additional information about user that started systemctl through it. And since the kdbus is not happening there is no way we can fix it in rhel7.
Comment 18 Steve Grubb 2016-11-01 05:42:31 EDT
I thikn what they are asking for is a more user friendly message than operation denied. What can't it say something like, "<service name> is configured to not allow systemctl to stop it. You might try stopping it with the service command or reviewing documentation associated with <service name>."
Comment 23 Jan Synacek 2017-01-23 04:08:41 EST
https://github.com/systemd/systemd/pull/5132
Comment 25 Lukáš Nykrýn 2017-01-25 04:15:30 EST
fix merged to upstream staging branch ->
https://github.com/lnykryn/systemd-rhel/commit/92ff0ade63ae85c6b6170af7b1209aaf37298ab1
-> post
Comment 31 Duncan Lock 2017-04-18 21:49:39 EDT
Trying this on my RHEL 7.3 VM, `service auditd stop` just redirects to `systemctl stop auditd.service`, which fails because `RefuseManualStop=yes` - so I can't stop/start the auditd service at all now?

$ cat /etc/os-release


NAME="Red Hat Enterprise Linux Server"
VERSION="7.3 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.3"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.3:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.3
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.3"


$ service auditd stop

Redirecting to /bin/systemctl stop  auditd.service

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or units.
Authenticating as: Vagrant (vagrant)
Password: 
==== AUTHENTICATION COMPLETE ===

Failed to stop auditd.service: Operation refused, unit auditd.service may be requested by dependency only.
See system logs and 'systemctl status auditd.service' for details.
Comment 32 Steve Grubb 2017-04-18 22:02:28 EDT
Something seems wrong with your setup. Maybe you're missing the legacy files?
/usr/libexec/initscripts/legacy-actions/auditd/stop
Comment 33 Duncan Lock 2017-04-19 00:54:28 EDT
(In reply to Steve Grubb from comment #32)
> Something seems wrong with your setup. Maybe you're missing the legacy files?
> /usr/libexec/initscripts/legacy-actions/auditd/stop

I'm completely willing to believe it's a problem with my setup - but it's not that problem ;) I have the legacy scripts and they work fine if I call them directly on the command line.


The context is that I have an Ansible task to restart auditd - and I'd like to work on RHEL7 systems in general - and ideally do things the 'correct' way - so I'm reluctant to call the legacy scripts directly from my ansible task. I'm currently using Ansible's `service` module (which then uses systemctl on RHEL7).

Maybe the correct thing to do *is* to use the legacy scripts directly on a RHEL7 system, as that's actually what would end up happening if `service auditd restart` was working properly, instead of redirecting to systemctl?
Comment 34 Steve Grubb 2017-04-19 07:58:40 EDT
OK. I was under the impression that the only source for the service command came from the initscripts package. If that is not the case, then the new service command needs to support the legacy scripts or things will not work. You probably should open a new bz against whatever provides your service command to align it with how things _have_ to work. Its supposed to look for a match in the legacy scripts section and run it. If no match _then_ redirect to systemctl.
Comment 35 Duncan Lock 2017-04-19 14:33:28 EDT
> I was under the impression that the only source for the service command came from the initscripts package.

Ansible has a module, that happens to be called `service`, that is used for restarting services in a cross-platform way. I just looked at it's [source code](https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/system/service.py), and for linux, if it can find systemd, then it'll use `systemctl` for everything; it doesn't check for the existence of any legacy scripts, and doesn't do anything RHEL specific. If it detects that a system is using systemd for init, then it'll use `systemctl` for service start/stop/etc... actions.

Now that I understand what's going on, I found that there's an open bug with Ansible for this: https://github.com/ansible/ansible/issues/22171

I'll add to it and reference this thread.

Thanks!
Comment 36 errata-xmlrpc 2017-08-01 05:09:52 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2297

Note You need to log in before you can comment on or make changes to this bug.