Bug#925552: release-notes: document problems with hidepid vs Buster systemd
Andrei POPESCU wrote:
> Justin B Rye wrote:
>> The "hidepid" mount-options for /proc (as recommended by various
>
> Why plural? Both the wiki and proc(5) are using singular.
You're right - I was thinking of "hidepid=0/1/2" as separate options,
but yes, the approved terminology is to call it one option with
multiple possible arguments. I suppose I could argue that it's
only the non-zero arguments that cause problems rather than the
hidepid option itself, but no, here's a patch making it singular.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 39d27b25..81ed5863 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -41,15 +41,15 @@ information mentioned in <xref linkend="morereading"/>.
<section id="hidepid-unsupported">
<!-- stretch to buster-->
- <title>Hidepid mount options for procfs unsupported</title>
+ <title>Hidepid mount option for procfs unsupported</title>
<para>
- The <literal>hidepid</literal> mount options for
- <filename>/proc</filename> are known to cause problems with current
- versions of systemd, and are considered by systemd upstream to be an
+ Using the <literal>hidepid</literal> mount option for
+ <filename>/proc</filename> is known to cause problems with current
+ versions of systemd, and is considered by systemd upstream to be an
unsupported configuration. Users who have modified
- <filename>/etc/fstab</filename> to enable these options are advised to
- disable them before the upgrade, to ensure login sessions work on
- &releasename;. (A possible route to re-enabling them is outlined on the
+ <filename>/etc/fstab</filename> to enable this option are advised to
+ disable it before the upgrade, to ensure login sessions work on
+ &releasename;. (A possible route to re-enabling it is outlined on the
wiki's <ulink
url="https://wiki.debian.org/Hardening#Mounting_.2Fproc_with_hidepid";>Hardening</ulink>
page.)
Reply to: