[systemd-devel] Question about the killing spree during the transition from the initrd to the root file system.

[Lennart Poettering]

On Do, 04.07.24 12:44, Demi Marie Obenour (demi at invisiblethingslab.com) wrote:

> > No, these belong to your process, systemd couldn't really reach into
> > your processes to close them, even if it wanted to.
> >
> > But do note that any files you keep open or mapped at the moment of transition
> > will remain pinned in memory, and cannot be released by the
> > kernel. this means that even though during the tmpfs→host transition
> > we generally destory the initrd's tmpfs' contents, the stuff you keep
> > pinned will stick around.
> >
> > Generally, only special purpose software should be left around that
> > way, if it is carefully written to handle this. For example it is not
> > allowed to dlopen() anything (and hence no NSS either! No
> > gethostbyname() or getpwnam() or so), because you'd otherwise end up
> > with a weird mix of match of shared libs from the initrd and the host.
>
> If one does need to e.g. do DNS lookups in such a process, what is the
> best way to do it?

Well, simply don't write programs like that, of course.

But if you really feel you must:

If you need DNS, then do the lookups via your own statically linked
DNS lib maybe?

You could talk to resolved's varlink or D-Bus interfaces too, but I
find this a bit icky, since you'll end up consuming services provided
by the OS on the root fs, while you should instead provide services to
that OS, but not consume them.

If you want user/group name resolution: these are generally a resource
manager by the host OS, hence you almos certainly are doing things
wrong if you want to resolve them from your initrd service. You could
talk to userdbd of course, via Varlink IPC, but the same applies as
above: it's a bit icky if you consume services provided by the OS, if
you are such a low-level daemon that must survive from initrd into
host.

In many ways: if you run like this you should consider yourself
conceptually closer to kernelspace than to userspace. And hence, the
same way as kernelspace generally doesn't resolve users or hostnames
you shouldn't really either.

Lennart

--
Lennart Poettering, Berlin