6

I am attempting to start a LXC container and then run a command inside it. The problem is that even if the container is in RUNNING state, it has not completed all its boot. This produces trouble with /tmp (and, I guess, wit other initializations).

This can be illustrated with this call sequence that creates a container, starts it, waits for its RUNNING state and executes some commands; the commands create a file /tmp/hello, show a dir, wait a bit and show again the dir:

lxc-clone -B overlayfs -s -o vm -n c1 ; lxc-start -n c1 ; lxc-wait -n c1 -s RUNNING ; lxc-attach -n c1 -- su -c "touch /tmp/hello; ls -la /tmp; sleep 5; ls -la /tmp" slave ; lxc-stop -n c1 ; lxc-destroy -n c1

whose output is

Created container c1 as snapshot of vm total 16 drwxrwxrwt 1 root root 4096 May 24 09:37 . drwxr-xr-x 1 root nogroup 4096 May 24 09:37 .. drwxrwxrwt 2 root root 4096 May 22 21:19 .ICE-unix drwxrwxrwt 2 root root 4096 May 22 21:19 .X11-unix -rw-rw-r-- 1 slave slave 0 May 24 09:37 hello total 16 drwxrwxrwt 1 root root 4096 May 24 09:37 . drwxr-xr-x 1 root nogroup 4096 May 24 09:37 .. drwxrwxrwt 2 root root 4096 May 24 09:37 .ICE-unix drwxrwxrwt 2 root root 4096 May 24 09:37 .X11-unix

and shows that the file /tmp/hello is deleted by some initialization script.

How to wait inside the container until the system is fully booted? Also, how to do it from outside the container?

anumi
  • 161

2 Answers2

4

For a container that runs on systemd, it seems this works well:

lxc-attach -n [CONTAINER NAME] -- systemctl isolate multi-user.target

You could probably apply the same logic for a sysvinit or upstart based container (run a command that blocks until a runlevel is reached), but I couldn't tell you what commands can do this off the top of my head.

Jarrad
  • 151
0

In my case, I consider an LXC container to be "ready" when it has network connectivity (e.g. so that commands such as apt update will work within an LXC container setup script).

On Debian 11 bullseye as a lxc host, with a Debian 11 bullseye lxc container, I had sucess in leveraging the following pattern:

lxc-unpriv-start -n "$LXC_CONTAINER"

lxc-wait -n "$LXC_CONTAINER" -s RUNNING


the lxc-wait RUNNING state is not that useful;


a container is already considered RUNNING even though the network is not yet up


the following command blocks until the container's network is up


lxc-unpriv-attach -n "$LXC_CONTAINER" -- systemctl start systemd-networkd-wait-online.service


when the script reaches this part, the lxc container's network probably is completely up and running


lxc-unpriv-attach -n "$LXC_CONTAINER" -- apt update


...

The systemctl start systemd-networkd-wait-online.service is relevant part: systemd-networkd-wait-online.service is a systemd service provided out-of the-box which just requires the network-online.target (or so I understand at least).

Therefore executing systemctl start systemd-networkd-wait-online.service blocks until the network is up.

Abdull
  • 2,432