Question about obtaining LUO session FD for non-systemd-managed service
Luca Boccassi
luca.boccassi at gmail.com
Mon Oct 26 16:22:13 PDT 2026
On Wed, 21 Oct 2026 at 11:36, Chenghao Duan <duanchenghao at kylinos.cn> wrote:
>
> 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.
That looks about right. If it's a user unit, also remember to enable
fd store preservation on the user session via a drop-in, ie the
user at .service system unit
More information about the kexec
mailing list