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 at 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 at 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 at 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 at 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 at 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 at 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