Am 24.09.20 um 08:54 schrieb Warner Losh:
On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser <s...@freebsd.org <mailto:s...@freebsd.org>> wrote:Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're not mounting devfs early enough. We should > fix that. Removing /dev/null from the boot process likely is never going > to happen because we use it all over the place to discard output... > There's ~200 instances of it in the boot rc scripts, so getting rid of > it there would also be quite the effort, with the same question. Removal of /dev/null from rc.d scripts should be quite simple, since most cases could just use ">-" (close file descriptor) instead. Other usage could be substituted with ":>" followed by chown.So closing fd1 and fd2 doesn't cause them to be available for these programs to get as an fd on open, causing other issues?But >- isn't documented in sh(1) as doing the close thing. On a whim I did the following:$ echo fred >- $ ls -last ./- 4 -rw-r--r-- 1 imp imp 5 Sep 24 00:50 ./- $ cat ./- fred $ which suggests maybe you now have a lot of files named - instead...
Yes, sorry, please ignore what I wrote - I was thinking of ">&-" of course, but that is not gracefully accepted by many commands (they are aborted when trying to write to the closed file descriptor). I had thought about piping into a command that ignores STDIN, first, e.g. "| :", but that generates a SIGPIPE when trying to flush the FILE buffer (i.e. after 4 KB, which might be sufficient for most cases, but it is not a general solution). A program that reads from STDIN and generates no output could be used, though, e.g. "| sed d". But this would cause lots of extra forked processes and increase the start-up time and is not acceptable.
but e.g. rc.d/syscons
uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.
So those interactions should be disaled by rc variables... Or we should
be failing the operation...
Going multi-user should not be stopped by any of the rc scripts failing due to lack of /dev. But since most developers will only test with /dev available, there is a risk that changes to rc files will not gracefully handle a missing /dev.
But those further references to /dev nodes will in general be
NOPs if /dev is not available (some test for existence of the
node they rely on, other just fail trying to access them, but
without negative effect on going multi-user).
Yea, that's more minor, but if /dev/ isn't there, they likely should
fail, or shouldn't proceed... But in a way that allows the rest of the
rc scripts to continue...
Since the issue of no devfs mounted it not typical, tests will be required to prevent regressions. If a failure in such a case stops the multi-user start-up, then it will most likely be in situations where there is no good way to provide diagnostics (e.g. no console that works for user land programs, no known writable file system locations, ...). Regards, STefan
OpenPGP_signature
Description: OpenPGP digital signature
