On Mon, Jul 08, 2024 at 01:16:56PM +0200, Lennart Poettering wrote: > On Do, 04.07.24 12:44, Demi Marie Obenour (d...@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
signature.asc
Description: PGP signature
