Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

With init scripts (or with openrc) I alway could run services from a different installation root.
but when I run chroot /somepath/to_root /usr/bin/systemctl start someservice I got:

Running in chroot, ignoring request.

Is there a way to force systemd run the service?

I forgot to say my host system run init scripts or openrc, but never systemd.

share|improve this question
I also need to run services into a chroot, it always worked before openrc2, seems impossible now ;( –  neofutur Aug 3 at 1:05

2 Answers 2

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?

1) 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 systemd-nspawn.

2) If instead you really want a chroot environment, this beautiful and clrystal clear Web page will rpovide you with two working solutions (the second one a modified version of the one offer at point1).

share|improve this answer
I've looked for systemd-nspawn but I can't run it. And No this is not for a container since the service need to be used by both the host and the target architecture. –  user2284570 Dec 15 '13 at 17:57
@user2284570 What do you mean exactly by I can't run it? –  MariusMatutiae Dec 15 '13 at 19:48
That I never use systemd in my host system root. In my case I can't mix systemd with openrc. –  user2284570 Dec 16 '13 at 18:05
It should be located right next to systemctl and the other systemd binaries (from your host: /somepath/to_root/usr/bin/systemd-nspawn) –  TwoD Jun 13 at 6:00

No. Services are executed by systemd (pid 1), not by systemctl directly (which only sends a start request), and since systemd runs outside the chroot, so will the service.

Although technically it could be possible to implement this (by making systemctl somehow pass its root to systemd), it is somewhat unlikely to happen since there already is a tool for creating full containers (systemd-nspawn /somepath/to_root). You could always contact the mailing list though.

share|improve this answer
Nice, But I need to use systemctl since My host system use oepnrc. I want full independent solution –  user2284570 Dec 15 '13 at 17:55
I'll muddy the waters yet further by saying: Psst! Mention RootDirectory= as well since you are so dangerously short of upvotes. (-: –  JdeBP Dec 16 '13 at 19:56
@JdeBP : What is the difference (in term of results) beetween the variable RootDirectoryand the chrootcommand? –  user2284570 Dec 17 '13 at 21:35
@grawity : So What append if the pid 1 is init? –  user2284570 Dec 21 '13 at 9:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.