Bug 859655 - Systemd cannot disable services
Summary: Systemd cannot disable services
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-22 20:46 UTC by Matt Spaulding
Modified: 2012-10-07 22:36 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-07 22:36:32 UTC


Attachments (Terms of Use)

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


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