From owner-svn-src-head@freebsd.org Thu Sep 24 08:08:51 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E3FFE3F0718; Thu, 24 Sep 2020 08:08:51 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxnkC5kzFz455H; Thu, 24 Sep 2020 08:08:51 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f30c8003c8f9e409704137a.dip0.t-ipconnect.de [IPv6:2003:cd:5f30:c800:3c8f:9e40:9704:137a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 831042E9F1; Thu, 24 Sep 2020 08:08:50 +0000 (UTC) (envelope-from se@freebsd.org) To: Warner Losh Cc: "Rodney W. Grimes" , Kyle Evans , Alan Somers , Mateusz Guzik , src-committers , svn-src-all , svn-src-head References: <202009231656.08NGujEs042900@gndrsh.dnsmgr.net> From: Stefan Esser Subject: Re: svn commit: r365643 - head/bin/cp Message-ID: <545173d1-a6e1-333a-11c1-a791bbeadd76@freebsd.org> Date: Thu, 24 Sep 2020 10:08:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BsZ2IiQxZPtrxLFJWLaISIeVd90EgEaBf" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 08:08:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BsZ2IiQxZPtrxLFJWLaISIeVd90EgEaBf Content-Type: multipart/mixed; boundary="8gTPxExLgn8jrNl2Nh6PyVEjbC4ReCbTJ"; protected-headers="v1" From: Stefan Esser To: Warner Losh Cc: "Rodney W. Grimes" , Kyle Evans , Alan Somers , Mateusz Guzik , src-committers , svn-src-all , svn-src-head Message-ID: <545173d1-a6e1-333a-11c1-a791bbeadd76@freebsd.org> Subject: Re: svn commit: r365643 - head/bin/cp References: <202009231656.08NGujEs042900@gndrsh.dnsmgr.net> In-Reply-To: --8gTPxExLgn8jrNl2Nh6PyVEjbC4ReCbTJ Content-Type: multipart/mixed; boundary="------------F586FD52C2AD12104A5C5B53" Content-Language: en-US This is a multi-part message in MIME format. --------------F586FD52C2AD12104A5C5B53 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Am 24.09.20 um 08:54 schrieb Warner Losh: >=20 >=20 > On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser > wrote: >=20 > Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're= not > mounting devfs early enough.=C2=A0 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= =2E.. > > 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.= >=20 > 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. >=20 >=20 > So closing fd1 and fd2 doesn't cause them to be available for these=20 > programs to get as an fd on open, causing other issues? >=20 > 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-- =C2=A01 imp =C2=A0imp =C2=A05 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. >=20 > So those interactions should be disaled by rc variables...=C2=A0 Or we = should=20 > 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). >=20 >=20 > Yea, that's more minor, but if /dev/ isn't there, they likely should=20 > 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 --------------F586FD52C2AD12104A5C5B53-- --8gTPxExLgn8jrNl2Nh6PyVEjbC4ReCbTJ-- --BsZ2IiQxZPtrxLFJWLaISIeVd90EgEaBf Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAl9sVBAFAwAAAAAACgkQR+u171r99URn KQgAnxgH0BuFlfh3iXOnuWhFGLpAk8fwQ6rU3sxp1hzgeFsUvoOuHtQKZlNIYuwP8Gox3Zuhok7R bFDq2Qe7Dy1ZI9yvfnvi05DwBvHVeXL+kjcNkOF6eMuQ11UwVeswXFq5ioOfE3c9d0OclBbFhcex Dwl2AQGuj6AnAaBP666XsDUst5to5T9vjUr9kPBnEmQv5ltb/vEcL2/7nvNQI+PZc2QDevH2ywto rfnJoW0Tmg2d9+xTxGBCJt7LymtLvTj0VQyoT4nPVCLwQsRzdnzQc5j6Yf+DW7dt9FPQfO6IKkSE NY/5LyUCvffPYPdkAcXcEXzJMefEcwRB1DPuPkLFCQ== =emwY -----END PGP SIGNATURE----- --BsZ2IiQxZPtrxLFJWLaISIeVd90EgEaBf--