svn commit: r365643 - head/bin/cp

[Stefan Esser]

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.

>     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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20200924/8ff8020b/attachment.sig>