Bug 1026648 - improve error message for RefuseManual*
Summary: improve error message for RefuseManual*
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: Radka Skvarilova
URL:
Whiteboard:
Depends On:
Blocks: 1298243 1393867 74systemd
TreeView+ depends on / blocked
 
Reported: 2013-11-05 07:08 UTC by Petr Sklenar ⛄
Modified: 2017-08-01 09:09 UTC (History)
16 users (show)

Fixed In Version: systemd-219-31.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:09:52 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2297 normal SHIPPED_LIVE systemd bug fix and enhancement update 2017-08-01 12:40:16 UTC

Description Petr Sklenar ⛄ 2013-11-05 07:08:43 UTC
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 12:37:20 UTC
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 14:38:08 UTC
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 15:01:05 UTC
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 15:38:53 UTC
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 11:14:30 UTC
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 22:18:38 UTC
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 14:21:59 UTC
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 22:31:31 UTC
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 08:40:48 UTC
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 09:42:31 UTC
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 09:08:41 UTC
https://github.com/systemd/systemd/pull/5132

Comment 25 Lukáš Nykrýn 2017-01-25 09:15:30 UTC
fix merged to upstream staging branch ->
https://github.com/lnykryn/systemd-rhel/commit/92ff0ade63ae85c6b6170af7b1209aaf37298ab1
-> post

Comment 31 Duncan Lock 2017-04-19 01:49:39 UTC
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-19 02:02:28 UTC
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 04:54:28 UTC
(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 11:58:40 UTC
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 18:33:28 UTC
> 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 09:09:52 UTC
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.