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

[Demi Marie Obenour]

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240708/bb733548/attachment.sig>