A well-known problem in systemd distros (Arch Linux, OpenSUSE, Fedora).
Systemd replaces sysvinit, and provides one great advantage over this. In sysvinit, when you ask a service to start, it inherits the execution context of the person invoking the script, which includes environment variables, ulimits, and so on. Systemd improves on this at the contrary by notifying a daemon, which will start the service in a well-defined, healthy, constant environment, where of course the performances of the services are much easier to predict, since the environment is always the same.
This implies that, when I call systemctl from within the chroot, it is irrelevant that I am inside chroot, the environment that will be inherited is still that of PID 1, not my current one. But it gets worse than this: since communication sockets are placed inside /run/systemd, a process in a chroot will not even be able to talk to the init system!
So how do you go about chroot'ing in systemd distros?
If all you want to do is have a Linux container, this Arch Wiki page will tell you how to set up a Linux container in less than 30 seconds, thanks to
If instead you really want a chroot environment, this beautiful and crystal clear Web page will provide you with two working solutions (the second one is a modified version of the one offered at point #1).