Bug 859655 - Systemd cannot disable services
Systemd cannot disable services
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
18
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-22 16:46 EDT by Matt Spaulding
Modified: 2012-10-07 18:36 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-07 18:36:32 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 Matt Spaulding 2012-09-22 16:46:31 EDT
Description of problem:

Systemd is unable to disable any services (at least all the ones I tried).

Version-Release number of selected component (if applicable):

191-2

How reproducible:

Every time with every service I have tried.

Steps to Reproduce:
1. systemctl disable <servicename>.service

Ex: systemctl disable libvirtd.service

Actual results:

Fails to disable service and returns the following error:

Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"

Expected results:

Disable the service appropriately.

Additional info:

I'm running Fedora 18 Alpha with the updates-testing repository enabled. I downgraded back to the previous version of systemd (188-3) and everything worked again.

Maybe this is an incompatibility between systemd and dbus?
Comment 1 Daniel Belton 2012-09-22 23:30:03 EDT
I get the same thing here after the update to systemd 191-2. 

It's the same thing trying to enable or disable services. 

[root@tower20 etc]# systemctl enable chronyd.service
Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"
Comment 2 Fabian Affolter 2012-09-23 08:58:12 EDT
I'm hitting the same issue.

# rpm -q systemd
systemd-191-2.fc18.x86_64
Comment 3 Lennart Poettering 2012-09-24 19:29:12 EDT
My guess is that this is related to SELinux. If you turn off selinux (or set it to enforcing), does it work then?
Comment 4 Matt Spaulding 2012-09-24 23:15:15 EDT
I tried again in both Enforcing and Permissive modes and got the same results.

Is there any other debugging information that might help?
Comment 5 Daniel Belton 2012-09-25 01:02:15 EDT
Results with turning SELinux off:

root@tower20 ~]# systemctl enable chronyd.service
ln -s '/usr/lib/systemd/system/chronyd.service' '/etc/systemd/system/multi-user.target.wants/chronyd.service'

So it does indeed work if I turn off SELinux.

Let me test once more turning SELinux back on to see it that is it for sure.
Comment 6 Daniel Belton 2012-09-25 01:10:58 EDT
Ok, just tried it again after enabling SELinux

[root@tower20 ~]# systemctl enable chronyd.service
Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"
[root@tower20 ~]# 

So, with SELinux enabled, it fails, with SELinux disabled it works. 

Just FYI: the only difference is I used the enforcing=0 kernel parameter when it worked. 

I am not going to run with SELinux disabled, though.
Comment 7 Daniel Belton 2012-09-25 01:15:19 EDT
Ok, changing enforcing to permissive, I still get the error. 

[root@tower20 ~]# systemctl enable chronyd.service
Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"
[root@tower20 ~]# getenforce
Enforcing
[root@tower20 ~]# setenforce 0
[root@tower20 ~]# getenforce
Permissive
[root@tower20 ~]# systemctl enable chronyd.service
Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"
Comment 8 Matt Spaulding 2012-09-25 02:10:50 EDT
OK, last time I used "setenforce" to switch between Permissive and Enforcing and that did not work.

Tried again by setting kernel parameter "enforcing=0" and it works now.

mspaulding@artemis ~$ sudo systemctl enable libvirtd.service
[sudo] password for mspaulding: 
ln -s '/usr/lib/systemd/system/libvirtd.service' '/etc/systemd/system/multi-user.target.wants/libvirtd.service'
mspaulding@artemis ~$ sudo systemctl disable libvirtd.service
rm '/etc/systemd/system/multi-user.target.wants/libvirtd.service'
mspaulding@artemis ~$ rpm -q systemd
systemd-191-2.fc18.x86_64
mspaulding@artemis ~$
Comment 9 Matt Spaulding 2012-09-28 10:54:03 EDT
Still seeing this in the latest version.

mspaulding@artemis ~$ sudo systemctl disable sshd.service
Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"
mspaulding@artemis ~$ rpm -q systemd
systemd-192-1.fc18.x86_64
Comment 10 Daniel Belton 2012-10-01 22:42:01 EDT
Still seeing it in systemd 193-1 as well. 

[root@tower20 ~]# systemctl enable chronyd.service
Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"
[root@tower20 ~]# rpm -q systemd
systemd-193-1.fc18.x86_64
Comment 11 Nikhil John 2012-10-02 07:10:32 EDT
I got this error when i was trying to re-enable display manager by 
 "systemctl enable --force xyzdm.service"
after upgrading to fedora 18 alpha x86_64.


[root@localhost ~]# systemctl enable --force xyzdm.service
Failed to issue method call: Argument 0 is specified to be of type "string", but is actually of type "array"

[root@localhost ~]# systemctl status --force xyzdm.service
xyzdm.service - XYZ Display Manager
	  Loaded: loaded (/usr/lib/systemd/system/xyzdm.service; disabled)
	  Active: failed (Result: start-limit) since Tue, 02 Oct 2012 16:33:49 +0530; 7min ago
	    Docs: man:xyzdm(8)
	 Process: 30456 ExecStart=/usr/bin/xyzdm -nofork (code=exited, status=203/EXEC)
	  CGroup: name=systemd:/system/xyzdm.service

Oct 02 16:33:49 localhost.nuke systemd[1]: Failed to start XYZ Display Manager.
Oct 02 16:33:49 localhost.nuke systemd[1]: Stopping XYZ Display Manager...
Oct 02 16:33:49 localhost.nuke systemd[1]: Starting XYZ Display Manager...
Oct 02 16:33:49 localhost.nuke systemd[1]: Failed to start XYZ Display Manager.
Comment 12 Jeff Layton 2012-10-02 14:36:42 EDT
Confirmed -- I was hitting the same bug. When I reconfigured the machine to boot into permissive mode the problem went away. Also confirmed that simply doing a setenforce 0 wasn't enough to fix the issue. I assume this means that the breakage happens earlier when systemd is first starting.
Comment 13 Nikhil John 2012-10-03 11:30:32 EDT
After Upgrading to fedora 18, when i rebooted the system. Shows an error in systemd at booting. Then the system hangs. But when i loaded fedora 18 in previous kernel (i.e., Linux kernel 3.5), it booted the OS fine and not much bugs were found then.
Comment 14 Fedora Update System 2012-10-03 15:49:12 EDT
glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18

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