Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Container hostname from the snapshot #727
Hey there. Thanks a lot for your work on CRIU and especially on the container aspect of it.
I'm experimenting with making a checkpoint on one host and doing
I've noticed that CRIU / Docker ignores the hostname of the new container and forces it to use the hostname from the original (checkpointed) container:
Is this a bug or the intentional design?
I understand this might be not the CRIU bug by itself. Feel free to redirect me to the more appropriate project (moby/runc/containerd?).
The following is not verified but from how I expect CRIU to work.
When CRIU checkpoint and restores a container it usually handles all the related namespace. One of the namespace usually involved is the UTS namespace which handles the hostname.
Upon restore CRIU restores the UTS namespace just as it used to be, that is why you get the old hostname. An example where CRIU does not restore the namespace but where CRIU restores into an existing namespace is Podman and the network namespace. So it could be implemented that CRIU does not restore the same UTS namespace but restores into a, by the container engine, pre-created UTS namespace. No code exists in CRIU to do this, but as we already do it for the network namespace it should be doable.
The reason why I ignored it for Podman is that your application in the container might have already used
So you need to trigger the containered application to re-read the hostname anyway.
So it is not really bug, more a not yet implemented, because not sure how useful it is.
As Adrian already pointed out, the old hostname might be stored in memory and a copy of all memory pages are stored as part of the container checkpoint.
Another issue could be the
IMHO it would be easier/simpler to explicitly change the container's hostname after restore.
Thanks for the context!
Let me share the use case to illustrate the reason why I have asked about it. In orchestrated environments, it's typical to create N replicas of the same container over multiple hosts. If the UoW is called
What I'm looking for is to run a "donor" container, snapshot it and let those replicas be created from the snapshot of the donor. It would be a bit confusing from the application side if all of them shared the same name. Of course, the app would have to avoid persisting the hostname and be ready that it might change.
I think this would require
You could also use the
You can use the decode and encode command to decode, modify and encode the utsns image file.