Explicit support for one dump - multiple restore?

[marto1]

Description

Would it be in the scope of CRIU to support "template" process dumps? My use case is a python environment that does a lot of library imports and the idea was to use criu to speedup spawning many of these environments. I made a hacky workflow that actually works. Running this:

import os
from time import sleep
# Import a lot of libraries here

# Dump process somewhere here
print("Sleeping for a while..")
for _ in range(10):
    sleep(1)

print("Old PID:", os.getpid())
pid = os.fork()
if pid > 0:
   exit(0)
os.setpgrp()
print("New PID:", os.getpid())

# Any code can go below..
while(True):
    print("RUNNING")
    sleep(5)

When restored I wait for the pid to change and can restore again ad infinitum. This is obviously pretty awkward and can probably be improved a lot with native support. I also saw some people doing custom namespaces instead, but don't know yet about the overhead and/or management of that option.

Steps to reproduce the issue:

1. criu dump --shell-job -D checkpoint -t
2. criu restore --shell-job -d -D checkpoint
3. criu restore --shell-job -d -D checkpoint

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

CRIU logs and information:

CRIU full dump/restore logs:

``` (paste your output here) ```

Output of `criu --version`:

``` (paste your output here) ```

Output of `criu check --all`:

``` (paste your output here) ```

Additional environment details:

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[avagin]

I also saw some people doing custom namespaces instead, but don't know yet about the overhead and/or management of that option.

The most straightforward way is to restore processes in new pid namespaces. The overhead is almost zero/unnoticeable in this case.

More hacky way is to change pid-s in the image files. I don't recommend to use it.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[marto1]

Sorry for the late reply and thanks! About the overhead, probably not an issue, but it's extra pollution for the kernel with namespaces going in and out. Hopefully same as deallocating a pid.