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