Bug 859655

Summary:	Systemd cannot disable services
Product:	[Fedora] Fedora	Reporter:	Matt Spaulding <mspaulding06>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	danielbelton, jlayton, johannbg, lnykryn, lpoetter, mail, metherid, msekleta, nikhiljohn1010, notting, plautrba, systemd-maint, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-07 22:36:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matt Spaulding 2012-09-22 20:46:31 UTC

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-23 03:30:03 UTC

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 12:58:12 UTC

I'm hitting the same issue.

# rpm -q systemd
systemd-191-2.fc18.x86_64

Comment 3 Lennart Poettering 2012-09-24 23:29:12 UTC

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-25 03:15:15 UTC

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 05:02:15 UTC

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 05:10:58 UTC

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 05:15:19 UTC

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 06:10:50 UTC

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 14:54:03 UTC

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-02 02:42:01 UTC

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 11:10:32 UTC

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 18:36:42 UTC

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 15:30:32 UTC

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 19:49:12 UTC

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