Bug 847720

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