So I recently successfully CRIU my palword server running in devuan container with 7.3.
Init,ssh,tmux,dhcp,palword ds
Here is how I done.
1.Make sure it is a privileged container, CRIU have permission problem accessing files during restore because it does not impersonate uid/gid, causing the euid become nobody(kernel default) with idmap on(thus CRIU patch is required for unprivileged mode).
2. Use the LXC source with the latest commit.This require building incus manually.And this is mandatory as it solves a cgroup issue required for CRIU.
3. Set the following config, otherwise CRIU won’t work because this config seems mismatch when restore(You can still use terminal instead of console for admin):
raw.lxc: |-
lxc.console.path = none
lxc.tty.max = 0
4. Enable stateful migration(duh)
-
If you use SLAAC, you must set following accordingly,otherwise it will conflict with CRIU restore procedure:
linux.sysctl.net.ipv6.conf.eth0.autoconf: ‘0’
6.Run the follwing in container, as a init script or before start server,Needed for CRIU to skip save the virtual mount as it is handled by incus/lxc:
mount --make-rprivate /dev
mount --make-rprivate -R /dev
mount --make-rprivate /sys
mount --make-rprivate -R /sys
mount --make-rprivate /proc
mount --make-rprivate -R /proc
#mount --make-rprivate /mnt
#mount --make-rprivate -R /mnt -
You should good to go now.
Why not debian/systemd(almost working with conf hacks(mostly security based),but 2 roadblockers):
1.Systemd tries to initial bpf,incus CRIU have no support of read bpf memory.
2.Systemd creates and holds virtual cgroup entry for itself, it is invisible to other process and even host, CRIU can’t dump this.
Give it a try if you dare.
For anyone don’t want to rebuild and probably for testing, you could try my fork fork
@stgraber How do you think? It is actually suprising me after finding out this… Though it is privileged.