Documentation

[albertz]

GitHub links https://criu.org/ as the main homepage. On that page, the documentation seems very incomplete. E.g. I wanted to read about the options for criu dump and criu restore in very detail. However, the corresponding pages seem empty? I looked here: https://criu.org/CLI. Maybe that's the wrong place?

It would be nice if the documentation can be found more easily.

Very unexpectedly, it seems that the man page has some information (but with too little details). I would have expected to find a more in depth documentation somewhere on the homepage.

Some aspects I am not really sure I understand well:

Does criu dump requires sudo? Always? Sometimes? Can I avoid it? I get many errors when I run it without.

Does criu restore requires sudo? Always? Sometimes? Can I avoid it? I get many errors when I run it without. But I really want to avoid sudo here.

--restore-detached or --restore-sibling, which is the default? The restored process pid is not the same as the criu restore pid but a separate (sub/detached) process? In case of detached, what is the parent process?

What exactly does --exec-cmd do?

Many other links on the homepage also link to empty pages. I'm not exactly sure whether that is correct or something is wrong. For example:

https://criu.org/Slow-boot_services_speed_up

The FAQ link seems to be broken: https://criu.org/FAQ

[adrianreber]

Thanks for reaching out, but if nobody steps up and writes the documentation then it just does not exist. Not really sure how to help you with the overall complain that the documentation is incomplete.

Does criu dump requires sudo? Always? Sometimes? Can I avoid it? I get many errors when I run it without.

Does criu restore requires sudo? Always? Sometimes? Can I avoid it? I get many errors when I run it without. But I really want to avoid sudo here.

CRIU currently always requires root. That is pretty easy to answer. There is currently a PR open to add limited non-root support to CRIU (#1930), but it will be limited. Especially in the beginning.

--restore-detached or --restore-sibling, which is the default?

Neither. But that is easy to figure out by trying it out.

The restored process pid is not the same as the criu restore pid but a separate (sub/detached) process?

Not sure I understand that questions. The restored process PID is always the same as during checkpointing.

In case of detached, what is the parent process?

Probably the PID of your process calling CRIU, but that sounds also really easy to test.

Many other links on the homepage also link to empty pages. I'm not exactly sure whether that is correct or something is wrong. For example:

Somebody needs to step up and write the documentation. It is an open source project and any help is always welcome.

[rst0git]

Hi @albertz, to follow up on Adrian's comment above, CRIU is a community-driven open source project and contributions are always welcome!

It would be nice if the documentation can be found more easily.

I would recommend using the search tool in the top right corner at https://criu.org/.

Very unexpectedly, it seems that the man page has some information (but with too little details). I would have expected to find a more in depth documentation somewhere on the homepage.

Currently, CRIU's man page has the most complete documentation about all command-line options. In addition, there is useful information in the git history and mailing list.

What exactly does --exec-cmd do?

There is an example and documentation about --exec-cmd in https://criu.org/CLI/opt/--exec-cmd

I hope this helps. Please feel free to reach out in gitter if you have any questions :)

[albertz]

Thanks for reaching out, but if nobody steps up and writes the documentation then it just does not exist. Not really sure how to help you with the overall complain that the documentation is incomplete.

I was not really sure if it does not exist, or if the homepage somehow is broken.

Because I know it exists. There is some documentation in the man-page. But that is missing on the homepage? So I thought something must be broken. On the homepage, I would have expected that man-page documentation + maybe sth more.

So, at the very least, I would copy/paste the man-page documentation also on the homepage.

But that is easy to figure out by trying it out.

I'm still trying and so far it did not work at all, but maybe that is because I misunderstand sth, because of lacking documentation. I always get some errors.

The restored process pid is not the same as the criu restore pid but a separate (sub/detached) process?

Not sure I understand that questions. The restored process PID is always the same as during checkpointing.

When I call criu restore ..., that will be some process (with criu as the binary), and have some pid. I wondered whether the restored process becomes alive within that same process, or will be a separate process, i.e. have another pid. So whether criu restore behaves more like exec or more like posix_spawn.

It is an open source project and any help is always welcome.

I would help, but the problem is, I don't really know anything about criu, so I cannot really help. And I don't really know where I could even start learning about criu when there is no real documentation.

CRIU currently always requires root.

Ah, that's very unfortunate. Then I probably cannot really use it anyway in my environment.

Or when I use the service (I also have not really figured out how to use that, and what that really is), would only the service require root, but then the dump/restore can happen in userspace?

[albertz]

I hope this helps. Please feel free to reach out in gitter if you have any questions :)

Thanks. This issue here was mostly about documentation, but as you see, I have lots of more specific questions, and I guess that's a better place to ask them.

[adrianreber]

When I call criu restore ..., that will be some process (with criu as the binary), and have some pid. I wondered whether the restored process becomes alive within that same process, or will be a separate process, i.e. have another pid. So whether criu restore behaves more like exec or more like posix_spawn.

The restored process will have the exact same PID as during checkpointing. Independent of the CRIU main process. CRIU will use clone()/clone3() to create a new process with the same PID as during checkpointing. CRIU never restores a process with another PID to not break parent-child relations of the restored process tree.

CRIU currently always requires root.

Ah, that's very unfortunate. Then I probably cannot really use it anyway in my environment.

Or when I use the service (I also have not really figured out how to use that, and what that really is), would only the service require root, but then the dump/restore can happen in userspace?

The service is not widely used and opens up more or less the same problems as having root. You can think about giving CAP_SYS_ADMIN to the CRIU binary, but that is also very similar to having root.

You can always try the non-root CRIU support in the PR mentioned. We do not know what you want to do, but it could work.

[albertz]

For reference, what I try to accomplish, is this project: https://github.com/albertz/python-preloaded

Python startup time including importing big modules like TensorFlow or PyTorch can take a long time (in case of slow FS, it can take 10-20 seconds). I want to dump the state right after that is loaded, and store it on disk, and then later restore the state, but allow to run any custom Python script from that state on.

[adrianreber]

That is exactly what the non-root PR tries to achieve in combination with Java. Fast startup.

[albertz]

The restored process will have the exact same PID as during checkpointing. Independent of the CRIU main process. CRIU will use clone()/clone3() to create a new process with the same PID as during checkpointing. CRIU never restores a process with another PID to not break parent-child relations of the restored process tree.

I don't understand this. How can it have the same PID as during checkpointing? What if another process already has that PID?

I actually want to restore the process multiple times, running simultaneously. How can they have all the same PID?

I want that the restored processes all have their own PID.

[adrianreber]

The restored process will have the exact same PID as during checkpointing. Independent of the CRIU main process. CRIU will use clone()/clone3() to create a new process with the same PID as during checkpointing. CRIU never restores a process with another PID to not break parent-child relations of the restored process tree.

I don't understand this. How can it have the same PID as during checkpointing?

CRIU magic 😉 As mentioned above, we us clone()/clone3() to create processes with a certain PID.

What if another process already has that PID?

That is a problem and one of the limitation of CRIU. If a PID collisions happens, the restore will fail.

I actually want to restore the process multiple times, running simultaneously. How can they have all the same PID?

Does your process have child processes or threads? How should the restored process signal its child processes or threads if the PID changes. That is the reason we only restore with the same PID.

If you have a process without child processes or threads you can try to change the PID in the CRIU image files using crit, but if you have multiple processes the chances are that something will not work (signalling/waiting). Processes do not expect that PIDs are changing.

I want that the restored processes all have their own PID.

See above not possible. The easy solution, however, is to restore each copy of the process into a new PID namespace and the problem is solved.

[albertz]

Btw, in the documentation (https://criu.org/Comparison_to_other_CR_projects), it says:

Can be used as non-root user?

Yes, but user can only manipulate tasks belonging to him

So this is wrong? At least before PR #1930 is merged?

[adrianreber]

Btw, in the documentation (https://criu.org/Comparison_to_other_CR_projects), it says:

Can be used as non-root user?

Yes, but user can only manipulate tasks belonging to him

So this is wrong? At least before PR #1930 is merged?

Sounds like it is not correct. I do not know who created that table with what in mind. Maybe there is something I am not aware.

[rst0git]

So this is wrong?

Actually not, but it is out of date. A few years ago, CRIU used to support the so-called service mode that allows to run CRIU daemon as a systemd service and unprivileged users to connect and perform checkpoint/restore. However, this has been deprecated due to security concerns (https://criu.org/Security, a90d01a)

[github-actions]

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