On Tue, Jul 09, 2024 at 12:13:38PM +0200, Lennart Poettering wrote: > On Mo, 08.07.24 15:57, Demi Marie Obenour (demi@xxxxxxxxxxxxxxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxxx) 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. Would talking to systemd-resolved from the host OS do any damage? I agree that it isn't elegant, but neither is having completely separate DNS configuration that can and will get out of sync. At a minimum, is it okay to listen for changes to systemd-resolved's configuration, so that the daemon's own resolver can stay in sync? I know that needing a call to systemd-resolved to e.g. resolve a page fault from systemd-resolved itself will deadlock. I'm assuming that the daemon is designed so that this never happens. And yes, it might be better to go through a proxy process from the root FS in this case. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
