> Am 24.09.20 um 08:54 schrieb Warner Losh:
> >
> >
> > On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser <se at freebsd.org
> > <mailto:se at 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.
Most of these can be "fixed" by fixing the programs that
fail to be old school friendly. Ie produce no output
when things are done as they are asked to be done, as
these "noisy" programs are not pipe friendly. #1 being
sysctl insisting to output what it did, simple fix, add
a -Q to it.
>
> > 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.
I would argue that a missing /dev is a fatal mutliuser boot
situation for security reasons, and the boot should be stopped
dead in its tracks at the earliest detection.
>
> > 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
[ Attachment, skipping... ]
--
Rod Grimes rgrimes at freebsd.org