| Summary: | systemd-nspawn: Spawning a shell in a container does not work | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Mauro Santos <registo.mailling> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED NOTABUG | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Hmm, if you just start a shell, then it's stdin will be connected to /dev/null, which means it immediately gets an EOF on it. This means the shell will immediately exit. It's identical to invoking "/bin/sh < /dev/null" which will exit immediately too. Or in factthe same as invoking /bin/sh as a service directly by specifying ExecStart=/bin/sh. This is expected behaviour, hence. Also, what's the usecase for this? I mean, if you just invoke a shell there's little you can do with it anyway... I used to launch the container with a service file and then use nsenter to enter the container and run more programs without needing to keep any terminals open, something like this: - start container - enter container as user1 and/or user2, run vncserver for the accounts and leave it running without any terminal windows open - use vncviewer on the host to run graphical programs inside the container as each user. Before I had no need to actually boot the container, the one time I tried to boot the container (centos5) it failed. Besides it takes a lot longer to boot the container than to launch just a shell. The other advantage I used to have with this, is that if the host's Xorg crashed (or I needed to relogin for some reason) then everything inside the container would not be affected. But what does a shell give you in this case? I mean, you could simply invoke "/usr/bin/sleep 9999999h" instead, no? That idea works :) I also need to setup the ip address of the container but I can do that before calling sleep. For the record in case someone else stumbles upon this, one can use "/usr/bin/sleep infinity". Problem solved, thanks for the help. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
As the summary says, spawning a shell in a container does not work but works if running from a command line. I have a service file to launch a centos container and it was working with systemd 218. After the update to systemd 219 it stopped working. The .service file used the following ExecStart line: /usr/bin/systemd-nspawn --keep-unit --machine=centos --link-journal=no --bind=/home/centos:/home --tmpfs=/tmp:mode=1777 --network-bridge=brkvm --directory=/virt/containers/centos When trying to start the container I get the following in the journal: > journalctl -b -u centos -o cat Started CentOS Container. Starting CentOS Container... Spawning container centos on /virt/containers/centos. Press ^] three times within 1s to kill container. Stopping CentOS Container... Stopped CentOS Container. If I use the same invocation (except --keep-unit) on a command line I am able to get a shell inside the container.