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

[Lennart Poettering]

On Mo, 08.07.24 15:57, Demi Marie Obenour (demi at invisiblethingslab.com) wrote:

> On Mon, Jul 08, 2024 at 01:16:56PM +0200, Lennart Poettering wrote:
> > 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.
>
> What is the most common use-case for such daemons?  I thought that it
> was for network-attached root filesystems.  Such a daemon might well
> need to do DNS lookups.

As I said above, if you really can't avoid DNS, then do DNS, but do it
yourself, i.e. add your own DNS client, and do not use OS services for
this. i.e. no NSS that involves dlopen() on modules from the rootfs or
talks to IPC services of the OS.

Lennart

--
Lennart Poettering, Berlin