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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
