Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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, and that I use chroot to troubleshot Unix systems which can't even launch a minimal shell.

share|improve this question
I also need to run services into a chroot, it always worked before openrc2, seems impossible now ;( – neofutur Aug 3 '14 at 1:05
You’re trying to solve the wrong problem. If you have OpenRC, you need to convert the systemd service into an OpenRC service. There’s really no way around that. – Daniel B Mar 10 '15 at 21:22
@DanielB : NO! Did you ever heard of systemrescuecd? – user2284570 Mar 11 '15 at 0:19
No. I also don't see how it relates to your question. – Daniel B Mar 11 '15 at 6:34

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 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).

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 '14 at 6:00
@TwoD That won't work. Running systemd-nspawn fails with "Not running on a systemd system." unless the host is using systemd as well. – hvd Jul 15 '15 at 11:59

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

You can run systemd inside chroot with systemd-nspawn tool. That tool can be run on a systemd system only though.

Since Linux 2.6.19 it is possible to run systemd on a non-systemd system by using PID namespace (kernel needs to be configured with CONFIG_PID_NS and CONFIG_NAMESPACES). Pid namespace creates a new hierarchy of processes starting with PID 1. In addition to this, systemd requires chrooted / to be mounted so you have to at least make a bind mount it otherwise some services will fail to run saying "Failed at step NAMESPACE spawning" due to "Invalid operation" as it tries to remount / with "private" option. To setup a chroot with new pid namespace you can use jchroot (git repo Make sure not to mount /proc inside new root before chrooting, otherwise systemd will detect chroot environment. You can mount it later once systemd is running.

Another more secure and more complex way is using LXC - that provides container environment with capability of limiting resources like CPU, memory, etc. Internally it also uses PID and other namespaces and cgroups.

share|improve this answer
Except I already wrote in my question I won't systemd whenever possible. So I will never run it as my host system. – user2284570 Mar 11 '15 at 0:24
Second section describes how to run systemd daemon and services in chroot on a system without systemd. Even if you don't need that it is relevant to your question and may help others. I was trying to find this solution for almost half a year. – k3a Mar 11 '15 at 8:46
LXC isn't part of systemrescuecd. I also told I'm not using chroot for security. If I would really need to do security in that way, I would use openrc or init scripts in both root directories. If my requirements doesn't fullfill yours, you should have have asked your own question and answered it yourself. – user2284570 Mar 11 '15 at 15:56

If you are launching an inetd-style service with socket activation, consider launching stunnel instead with a configuration file that specifies both a chroot and your binary as an inetd-style launch target.

Note that you may have SELINUX issues. On an Oracle Linux 7.1 system, I had to "chcon -v --type=stunnel_etc_t" on all files that stunnel needed to read.

You will need to use TLS encryption on the client side of the socket (i.e., another stunnel with "client=yes" in the config). Let me know if you want more details on this.

share|improve this answer
no it's about things like d-bus. I do it in order to diagnose problems on the target chroot. – user2284570 Sep 14 '15 at 17:15

systemd only ignores "services", so I just run the daemon commands manually. So instead of "service sshd start" I use "/usr/sbin/sshd -D &". Simple.

share|improve this answer
This doesn’t work for all services. Some require to be started as part of the system service starter like Xorg. – user2284570 Dec 6 '15 at 11:15

You can use nohup command to start services in chroot. To start httpdservice for example, I do it like this.

nohup httpd /dev/null &

to stop it pkill httpd

share|improve this answer
What about services like Dbus that can only be started by the installed binary systemd script ? – user2284570 Apr 11 at 10:01
You can start such services from its directory with start command. – ellooku Apr 21 at 18:18
Which is a symlink against systemctl. So it doesn’t work. – user2284570 Apr 21 at 18:25
I do this all the time on Fedora running on my Android. May be I don't know what your problem is. – ellooku Apr 21 at 18:32
The consequence is this message :Running in chroot, ignoring request.. I don’t think you do it all the time though chroot. Indeed, the startup script requires systemd. – user2284570 Apr 21 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .