[Toybox] xvdaemon

[Rob Landley]

On 1/24/24 11:27, enh via Toybox wrote:
> none of the three existing callers to this function does the chdir() mentioned
> here...
> ```
> // daemonize via vfork(). Does not chdir("/"), caller should do that first
> // note: restarts process from command_main()
> void xvdaemon(void)
> ```
> was there even a reason why you wanted that in the caller?

Yeah, design loose end there.

The idea was servers like httpd may want to stay in the current directory when
told to serve "." or similar. Daemonizing without doing a cd / will pin the
directory it was launched in and thus block umount.

Of _course_ I hit this back in 2001:

  https://lkml.iu.edu/hypermail/linux/kernel/0110.1/0638.html

I have a toybox todo item to figure out how to generically handle daemonizing
servers that currently only implement inetd logic, there's some missing
infrastructure (and shared CLI plumbing). Although maybe "run it under an
inetd-alike" is the answer? Currently I use netcat server mode to run them, but
there should probably _be_ an inetd or similar. Denys loved some nonstandard
toolset that had tcpserv and udpserv as two different commands, and added a
bunch of that stuff to busybox way back when which I still haven't looked at all
these years later...

In theory xvdaemon() could do the cd / in the vforked child (that's
process-local state that doesn't affect the parent when it resumes) and the
server's responsibility would be to grab a filehandle it can openat() via before
that point. (Converting to absolute path is more expensive and not _entirely_
reliable, because the path down to cwd may have a chmod -rx parent dir you're
underneath, or you could be in an overmounted directory, or...)

Rob