Re: Question about obtaining LUO session FD for non-systemd-managed service

Re: Question about obtaining LUO session FD for non-systemd-managed service

[Luca Boccassi]

On Sat, 10 Oct 2026 at 04:11, Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>
> Hi Luca,
>
> I watched your excellent presentation from the LPC conference in Prague.
>
> I have a question I’d like to consult with you.
>
> I am currently working on the `memfd_luo` feature in CRIU. My goal is to
> leverage the LUO capability to store checkpoint images inside memfds.
> After a kexec reboot, the image data will be retrieved directly from
> memory instead of from disk.
>
> Here is my pull request on the CRIU GitHub repository:
> https://github.com/checkpoint-restore/criu/pull/3152
>
> In the PR discussion, avagin suggested using systemd as the CRIU daemon
> to centrally manage LUO sessions and access to `/dev/liveupdate`. I have
> watched your talk and read parts of the systemd source code.
>
> From my understanding, systemd currently provides a unit‑based solution
> where child processes can inherit LUO session file descriptors. However,
> this approach requires the target service to run as a child of a systemd
> unit. As far as I know, CRIU does not run as a systemd‑managed service.
>
> So my question is: for services such as CRIU that are **not systemd‑managed
> child services**, how can they obtain LUO‑session‑related file descriptors
> managed by systemd?
>
> Thank you very much for reading this email. My knowledge of systemd is still
> limited, so please feel free to correct me if I have misunderstood anything.
>
> Thanks & best regards,
> Chenghao Duan <duanchenghao@kylinos.cn>

Hi,

At some point up in the stack, everything runs as a systemd unit, so
it's only a question of figuring out in your setup how to pass the
FD(s) up and down the stack.

Re: Question about obtaining LUO session FD for non-systemd-managed service

[Chenghao Duan]

On Sat, Oct 10, 2026 at 03:05:40PM +0200, Luca Boccassi wrote:
> On Sat, 10 Oct 2026 at 04:11, Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> >
> > Hi Luca,
> >
> > I watched your excellent presentation from the LPC conference in Prague.
> >
> > I have a question I’d like to consult with you.
> >
> > I am currently working on the `memfd_luo` feature in CRIU. My goal is to
> > leverage the LUO capability to store checkpoint images inside memfds.
> > After a kexec reboot, the image data will be retrieved directly from
> > memory instead of from disk.
> >
> > Here is my pull request on the CRIU GitHub repository:
> > https://github.com/checkpoint-restore/criu/pull/3152
> >
> > In the PR discussion, avagin suggested using systemd as the CRIU daemon
> > to centrally manage LUO sessions and access to `/dev/liveupdate`. I have
> > watched your talk and read parts of the systemd source code.
> >
> > From my understanding, systemd currently provides a unit‑based solution
> > where child processes can inherit LUO session file descriptors. However,
> > this approach requires the target service to run as a child of a systemd
> > unit. As far as I know, CRIU does not run as a systemd‑managed service.
> >
> > So my question is: for services such as CRIU that are **not systemd‑managed
> > child services**, how can they obtain LUO‑session‑related file descriptors
> > managed by systemd?
> >
> > Thank you very much for reading this email. My knowledge of systemd is still
> > limited, so please feel free to correct me if I have misunderstood anything.
> >
> > Thanks & best regards,
> > Chenghao Duan <duanchenghao@kylinos.cn>
> 
> Hi,
> 
> At some point up in the stack, everything runs as a systemd unit, so
> it's only a question of figuring out in your setup how to pass the
> FD(s) up and down the stack.

Hi Luca,

Thanks for your reply.

The `LUOSession=` configuration only takes effect for services managed
by the system manager. If I run the CRIU command from an SSH login shell
as I am doing now, the environment belongs to a transient unit under the
user manager. In this case, we cannot use `LUOSession=` to obtain the
LUO session fd via systemd. Does this mean the process needs to open
`/dev/liveupdate` by itself to create the session fd?

Below is the attached service of the process found via `systemctl status`.

[root@localhost criu]# ps -ef |grep criu
root       57589    7729  0 18:25 pts/2    00:00:00 ./criu/criu dump -D ../test -t 52922 -j --memfd-images -v4
root       57784    7571  0 18:27 pts/0    00:00:00 grep --color=auto criu
[root@localhost criu]# systemctl status 57589
● session-5.scope - Session 5 of User root
     Loaded: loaded (/run/systemd/transient/session-5.scope; transient)
  Transient: yes
     Active: active (running) since Tue 2026-10-13 10:03:55 CST; 8h ago
      Tasks: 4
     Memory: 148.9M (peak: 1.3G)
        CPU: 47.000s
     CGroup: /user.slice/user-0.slice/session-5.scope
             ├─ 7712 "sshd: root [priv]"
             ├─ 7724 "sshd: root@pts/2"
             ├─ 7729 -bash
             └─57589 ./criu/criu dump -D ../test -t 52922 -j --memfd-images -v4

I'm not sure whether my understanding is correct. Could you please
provide your feedback?


BRs
Chenghao

Re: Question about obtaining LUO session FD for non-systemd-managed service

[Luca Boccassi]

On Tue, 13 Oct 2026 at 12:02, Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>
> On Sat, Oct 10, 2026 at 03:05:40PM +0200, Luca Boccassi wrote:
> > On Sat, 10 Oct 2026 at 04:11, Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> > >
> > > Hi Luca,
> > >
> > > I watched your excellent presentation from the LPC conference in Prague.
> > >
> > > I have a question I’d like to consult with you.
> > >
> > > I am currently working on the `memfd_luo` feature in CRIU. My goal is to
> > > leverage the LUO capability to store checkpoint images inside memfds.
> > > After a kexec reboot, the image data will be retrieved directly from
> > > memory instead of from disk.
> > >
> > > Here is my pull request on the CRIU GitHub repository:
> > > https://github.com/checkpoint-restore/criu/pull/3152
> > >
> > > In the PR discussion, avagin suggested using systemd as the CRIU daemon
> > > to centrally manage LUO sessions and access to `/dev/liveupdate`. I have
> > > watched your talk and read parts of the systemd source code.
> > >
> > > From my understanding, systemd currently provides a unit‑based solution
> > > where child processes can inherit LUO session file descriptors. However,
> > > this approach requires the target service to run as a child of a systemd
> > > unit. As far as I know, CRIU does not run as a systemd‑managed service.
> > >
> > > So my question is: for services such as CRIU that are **not systemd‑managed
> > > child services**, how can they obtain LUO‑session‑related file descriptors
> > > managed by systemd?
> > >
> > > Thank you very much for reading this email. My knowledge of systemd is still
> > > limited, so please feel free to correct me if I have misunderstood anything.
> > >
> > > Thanks & best regards,
> > > Chenghao Duan <duanchenghao@kylinos.cn>
> >
> > Hi,
> >
> > At some point up in the stack, everything runs as a systemd unit, so
> > it's only a question of figuring out in your setup how to pass the
> > FD(s) up and down the stack.
>
> Hi Luca,
>
> Thanks for your reply.
>
> The `LUOSession=` configuration only takes effect for services managed
> by the system manager. If I run the CRIU command from an SSH login shell
> as I am doing now, the environment belongs to a transient unit under the
> user manager. In this case, we cannot use `LUOSession=` to obtain the
> LUO session fd via systemd. Does this mean the process needs to open
> `/dev/liveupdate` by itself to create the session fd?
>
> Below is the attached service of the process found via `systemctl status`.
>
> [root@localhost criu]# ps -ef |grep criu
> root       57589    7729  0 18:25 pts/2    00:00:00 ./criu/criu dump -D ../test -t 52922 -j --memfd-images -v4
> root       57784    7571  0 18:27 pts/0    00:00:00 grep --color=auto criu
> [root@localhost criu]# systemctl status 57589
> ● session-5.scope - Session 5 of User root
>      Loaded: loaded (/run/systemd/transient/session-5.scope; transient)
>   Transient: yes
>      Active: active (running) since Tue 2026-10-13 10:03:55 CST; 8h ago
>       Tasks: 4
>      Memory: 148.9M (peak: 1.3G)
>         CPU: 47.000s
>      CGroup: /user.slice/user-0.slice/session-5.scope
>              ├─ 7712 "sshd: root [priv]"
>              ├─ 7724 "sshd: root@pts/2"
>              ├─ 7729 -bash
>              └─57589 ./criu/criu dump -D ../test -t 52922 -j --memfd-images -v4
>
> I'm not sure whether my understanding is correct. Could you please
> provide your feedback?

That's a user unit, and as per the documentation LUOSession= is only
supported for system units. So yes you have to provide your program
with privileged access to the character device and create the session
yourself, and then stash it in the FD Store as normal.

Re: Question about obtaining LUO session FD for non-systemd-managed service

[Chenghao Duan]

On Mon, Oct 19, 2026 at 01:13:28PM +0100, Luca Boccassi wrote:
> On Tue, 13 Oct 2026 at 12:02, Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> >
> > On Sat, Oct 10, 2026 at 03:05:40PM +0200, Luca Boccassi wrote:
> > > On Sat, 10 Oct 2026 at 04:11, Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> > > >
> > > > Hi Luca,
> > > >
> > > > I watched your excellent presentation from the LPC conference in Prague.
> > > >
> > > > I have a question I’d like to consult with you.
> > > >
> > > > I am currently working on the `memfd_luo` feature in CRIU. My goal is to
> > > > leverage the LUO capability to store checkpoint images inside memfds.
> > > > After a kexec reboot, the image data will be retrieved directly from
> > > > memory instead of from disk.
> > > >
> > > > Here is my pull request on the CRIU GitHub repository:
> > > > https://github.com/checkpoint-restore/criu/pull/3152
> > > >
> > > > In the PR discussion, avagin suggested using systemd as the CRIU daemon
> > > > to centrally manage LUO sessions and access to `/dev/liveupdate`. I have
> > > > watched your talk and read parts of the systemd source code.
> > > >
> > > > From my understanding, systemd currently provides a unit‑based solution
> > > > where child processes can inherit LUO session file descriptors. However,
> > > > this approach requires the target service to run as a child of a systemd
> > > > unit. As far as I know, CRIU does not run as a systemd‑managed service.
> > > >
> > > > So my question is: for services such as CRIU that are **not systemd‑managed
> > > > child services**, how can they obtain LUO‑session‑related file descriptors
> > > > managed by systemd?
> > > >
> > > > Thank you very much for reading this email. My knowledge of systemd is still
> > > > limited, so please feel free to correct me if I have misunderstood anything.
> > > >
> > > > Thanks & best regards,
> > > > Chenghao Duan <duanchenghao@kylinos.cn>
> > >
> > > Hi,
> > >
> > > At some point up in the stack, everything runs as a systemd unit, so
> > > it's only a question of figuring out in your setup how to pass the
> > > FD(s) up and down the stack.
> >
> > Hi Luca,
> >
> > Thanks for your reply.
> >
> > The `LUOSession=` configuration only takes effect for services managed
> > by the system manager. If I run the CRIU command from an SSH login shell
> > as I am doing now, the environment belongs to a transient unit under the
> > user manager. In this case, we cannot use `LUOSession=` to obtain the
> > LUO session fd via systemd. Does this mean the process needs to open
> > `/dev/liveupdate` by itself to create the session fd?
> >
> > Below is the attached service of the process found via `systemctl status`.
> >
> > [root@localhost criu]# ps -ef |grep criu
> > root       57589    7729  0 18:25 pts/2    00:00:00 ./criu/criu dump -D ../test -t 52922 -j --memfd-images -v4
> > root       57784    7571  0 18:27 pts/0    00:00:00 grep --color=auto criu
> > [root@localhost criu]# systemctl status 57589
> > ● session-5.scope - Session 5 of User root
> >      Loaded: loaded (/run/systemd/transient/session-5.scope; transient)
> >   Transient: yes
> >      Active: active (running) since Tue 2026-10-13 10:03:55 CST; 8h ago
> >       Tasks: 4
> >      Memory: 148.9M (peak: 1.3G)
> >         CPU: 47.000s
> >      CGroup: /user.slice/user-0.slice/session-5.scope
> >              ├─ 7712 "sshd: root [priv]"
> >              ├─ 7724 "sshd: root@pts/2"
> >              ├─ 7729 -bash
> >              └─57589 ./criu/criu dump -D ../test -t 52922 -j --memfd-images -v4
> >
> > I'm not sure whether my understanding is correct. Could you please
> > provide your feedback?
> 
> That's a user unit, and as per the documentation LUOSession= is only
> supported for system units. So yes you have to provide your program
> with privileged access to the character device and create the session
> yourself, and then stash it in the FD Store as normal.
Hi Luca,

Thanks for your clarification.
I now have a rough idea for the implementation: CRIU will leverage the
FD Store facility to deposit the memfd into systemd’s file descriptor
store. As FD Store is tied to a service unit, a criu.service is
required. The unit file I intend to use is shown below:

[Service]
Type=oneshot
RemainAfterExit=yes
FileDescriptorStoreMax=10
FileDescriptorStorePreserve=yes
ExecStart=criu command

Does this setup conform to the original design intent of systemd FD
Store and LUO? Please feel free to point out any mistakes.

BRs,
Chenghao

Question about obtaining LUO session FD for non-systemd-managed service

[Chenghao Duan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

Hi Luca,

I watched your excellent presentation from the LPC conference in Prague.

I have a question I’d like to consult with you.

I am currently working on the `memfd_luo` feature in CRIU. My goal is to
leverage the LUO capability to store checkpoint images inside memfds.
After a kexec reboot, the image data will be retrieved directly from
memory instead of from disk.

Here is my pull request on the CRIU GitHub repository:
https://github.com/checkpoint-restore/criu/pull/3152

In the PR discussion, avagin suggested using systemd as the CRIU daemon
to centrally manage LUO sessions and access to `/dev/liveupdate`. I have
watched your talk and read parts of the systemd source code.

From my understanding, systemd currently provides a unit‑based solution
where child processes can inherit LUO session file descriptors. However,
this approach requires the target service to run as a child of a systemd
unit. As far as I know, CRIU does not run as a systemd‑managed service.

So my question is: for services such as CRIU that are **not systemd‑managed
child services**, how can they obtain LUO‑session‑related file descriptors
managed by systemd?

Thank you very much for reading this email. My knowledge of systemd is still
limited, so please feel free to correct me if I have misunderstood anything.

Thanks & best regards,
Chenghao Duan <duanchenghao@kylinos.cn>