[CRIU] CRIU with GNU Screen: dumping and restoring entire process trees under Screen

[Nikhil Nair]

Hi Pavel,

Thanks for getting back to me.  I hadn't realised that the WSL side of this
would be the major issue, but it makes complete sense in hindsight.  I did
a quick Google search, and found this:

https://github.com/Microsoft/WSL/issues/2833

In short, someone tried CRIU under WSL in Jan 2018, found it didn't work
(giving an error that /proc/<pid>/map_files wasn't found), and reported it
to Microsoft.  I've just checked, and my current version of WSL still
doesn't have /proc/.../map_files, so it looks like that hasn't changed
since then.  The fact that your test came up with different errors suggests
that there are multiple issues when trying to run CRIU under WSL, and that
this probably won't be fixed anytime soon.

A pity.  Oh well.  So, I suppose if I want persistence across reboots on
Windows, I'll just have to run a Linux VM, under Hyper-V/VMware/whatever.

Aside from the WSL question, though, I'm still interested in knowing how to
checkpoint/restore an interactive screen process tree: there have been a
number of times when I've wished I could preserve my working setup across
server reboots.  Do I take it that, given the existence of the (empty)
article about this, that it is completely doable?

If anyone could give me some pointers on this - or, better still, direct me
to some instructions on how to do it - I'd appreciate it.

Thanks, and best wishes,

Nikhil.


On Fri, 24 Apr 2020, Pavel Tikhomirov wrote:

> Hello Nikhil!
>
> I'm not sure anyone actually checked that criu works on wsl, some
> kernel interfaces may be not implemented.
>
> I've just tried criu on WSL and got some errors:
>
>
> :/home/snorch/devel/criu# criu check
> Warn  (criu/kerndat.c:659): Can't load /run/criu.kdat
> Error (criu/util.c:714): exited, status=3
> Error (criu/util.c:714): exited, status=3
> Error (criu/kerndat.c:47): Can't open 0/pagemap on procfs: No such
> file or directory
> Error (criu/sysctl.c:368): Can't open sysctl vm/mmap_min_addr: No such
> file or directory
> Warn  (criu/kerndat.c:137): Can't fetch vm/mmap_min_addr value, use
> default 0x10000
> :/home/snorch/devel/criu#
>
> Best Regards, Tikhomirov Pavel.
>
> ??, 17 ???. 2020 ?. ? 13:06, Nikhil Nair <nnair at pobox.com>:
>>
>> Hi,
>>
>> I'm completely new to CRIU, and it sounds very interesting.
>>
>> On the website, I found a page about using CRIU to dump and restore entire
>> process trees under screen, but it seems the page is empty, and has been so
>> for 3 years.
>>
>> I'm hopeful, though, that the existence of that page means this is very
>> doable indeed.  Is that right?  I've searched the archive of this list for
>> an answer to this, as well as Googling it, but couldn't find anything.
>>
>> Ideally, I'd like to be able to have a script running in the background
>> which will take a snapshot of my screen session (which typically has one
>> Emacs session running within it, plus a number of bash shells with
>> different CWDs and screen contents) every several minutes (and then delete
>> old snapshots so that it only keeps the last few at any time).  I presume
>> taking a snapshot will involve both a CRIU dump and taking a copy of my
>> relevant working directories.
>>
>> The reason I'm looking at this is that I'm shifting to develop on Windows
>> 10 using their Windows Subsystem for Linux (WSL), running Ubuntu.  It's
>> pretty much binary compatible with Ubuntu running on a normal AMD64
>> platform with a text console (I'm not using X).
>>
>> The issue is that, sometimes, the host Windows machine reboots, without
>> always asking my permission - or, at least, only waiting so long, so if I'm
>> away from the machine, I could come back to find the machine rebooted, and
>> my screen session lost.  There are things I can do to make reboots less
>> likely, but I don't trust Windows not to reboot if it considers it
>> important, without giving me a chance to save my work.
>>
>> But honestly, even if I did have a chance to save my work, taking a
>> snapshot would be much easier than setting up the screen session from
>> scratch, anyway.
>>
>> So... what's the situation?  Is this reasonably straightforward?
>>
>> If the above won't work, I could look into using lxc under WSL, and
>> snapshot the container; but that seems overkill, for what I'm after.
>> Docker would have been an option, but I gather (from the CRIU website) that
>> dumping an interactive container isn't yet enabled in Docker.
>>
>> Cheers,
>>
>> Nikhil.
>> _______________________________________________
>> CRIU mailing list
>> CRIU at openvz.org
>> https://lists.openvz.org/mailman/listinfo/criu
>