Description of problem: Running systemctl in chroot shows some strange behavior. start/stop/is-active, etc. return "Running in chroot, ignoring request." and exit code 0, which is obviously the sensible thing to do and completely understandable. But running is-enabled/enable/disable always return exit code 1, even if the task was successfully completed. Also, is-enabled does not return the usual feedback (static/enabled/disabled/etc), while enable and disable do (ln -s .../ rm ...) Being able to run systemctl for those basic tasks in chroot is crucial for at least two use cases: - Post install instructions (%post in anaconda) - Setting up a NFS rootfs Also, puppet does (in this order) is-active, is-enabled, enable if a service is set to enable => true. Again, running puppet in chroot can be useful with a NFS rootfs, as long as ensure => running is not set. Version-Release number of selected component (if applicable): systemd-44-17.fc17.x86_64 Example taken in chroot environment: [root@tiphares /]# systemctl is-active nslcd.service Running in chroot, ignoring request. [root@tiphares /]# echo $? 0 [root@tiphares /]# systemctl is-enabled nslcd.service [root@tiphares /]# echo $? 1 [root@tiphares /]# systemctl enable nslcd.service [root@tiphares /]# echo $? 1 [root@tiphares /]# systemctl disable nslcd.service rm '/etc/systemd/system/multi-user.target.wants/nslcd.service' [root@tiphares /]# echo $? 1 [root@tiphares /]# systemctl is-enabled nslcd.service [root@tiphares /]# echo $? 1 [root@tiphares /]# systemctl enable nslcd.service ln -s '/etc/systemd/system/nslcd.service' '/etc/systemd/system/multi-user.target.wants/nslcd.service' [root@tiphares /]# echo $? 1
Created attachment 621306 [details] Change in src/systemctl/systemctl.c to change non-negative return codes for chrooted file system commands to 0. Comments in other parts of the code indicate that the numeric value of the number of symlinks that should be processed is useful. Perhaps this number could be recorded in a message or in debugging output.
Fixed in git. Soon F18.
systemd-195-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-195-1.fc18
Package systemd-195-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-195-1.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-1.fc18 then log in and leave karma (feedback).
Package systemd-195-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-195-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-2.fc18 then log in and leave karma (feedback).
systemd-195-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.