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?
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"
I'm hitting the same issue. # rpm -q systemd systemd-191-2.fc18.x86_64
My guess is that this is related to SELinux. If you turn off selinux (or set it to enforcing), does it work then?
I tried again in both Enforcing and Permissive modes and got the same results. Is there any other debugging information that might help?
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.
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.
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"
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 ~$
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
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
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.
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.
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.
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