Questions on workflow draft: best practice for waiting, and ensure `exec` command runs on container not host

I started using LXD at the weekend and have figured out a workflow to manage containers for Firefox sessions (experimenting with whether this would make managing task-focused browsing sessions easier for me).

It seems broadly viable, but I have to type it all in manually which makes it significantly trickier than the “workflow” of clicking the browser icon once!

I noticed that you can’t just run the commands in immediate succession (as scripts usually do). If you immediately run exec on a container that just launched or logged in it doesn’t quite register the command and it fails.

I’m guessing this is familiar to other LXD users but let me know if you’d like a reproducible example.

I’m just wondering what solution people tend to go for to resolve this. The obvious option’d be to sleep for half a second but I don’t know if there’s a better way?

Secondly, I tried running exec and the Firefox that launches does not show “(on containername)” in its window title [i.e. it is a host process], whereas if I execute firefox -no-remote & from the ubuntu login shell as shown below I get an appropriately containerised Firefox instance.

(There’s also an error about dbus which I interpret as meaning the X socket is being shared by any/all containers so does not give process isolation, and I thought I resolved that by apt installing dbus-x11 but then the error returned.)

lxc kindle ffx-mysesh # 1: launch a new container from the template
lxc login ffx-mysesh # 2: drop into a login shell for the newly launched container
firefox -no-remote & # 3

# ...surfing the web until finished for this session

lxc snapshot ffx-mysesh paused # 4: snapshot the container state
lxc publish ffx-mysesh/paused --alias my_stored_sesh # 5: store the snapshot as a local image
lxc delete -f ffx-mysesh # stop and delete # 6: discard (stop and delete) the container instance

# ... some time passes until I want to revisit the session
lxc launch my_stored_sesh --profile default --profile x11 --profile pa ffx-mysesh # 7: relaunch
lxc login ffx-mysesh # 8: (repeat step 2) drop into a login shell for the restored container
firefox -no-remote & # 9

# then IF UNFINISHED: loop back to step 4
lxc snapshot ffx-mysesh paused2 # 10a: (4 rep) 
lxc publish ffx-mysesh/paused2 --alias my_stored_sesh2 # 10b: (5 rep) store snapshot as local image

# else IF FINISHED: (repeat step 6) discard (stop and delete) the container instance
lxc delete -f ffx-mysesh

# but either way delete the outdated image (which was relaunched in step 7)
lxc image delete my_stored_sesh # 11: delete the outdated image

Have a look at The container startup is an asynchronous affair, hence you would need to run a command in the container to verify that some bootup stage has completed. I think in the general case, LXD would not know whether a container has finished executing as there is no specific communication between LXD and container after bootup.

The specific way to run X11 applications in the container and have then appear on the host’s desktop, makes use of the host’s X11 Unix socket. I think Firefox has code that checks if another window is running on the same desktop, and if so, opens a new window for the currently running Firefox instance. Indeed, for the specific case of Firefox, you would need to append --no-remote on the command line to get separate browsers. You can install a different Firefox theme so that you can distinguish easily one instance from another,