The first isn't really a problem, just an oddity. You list
POSIX.1b as "formerly known as POSIX.4", but you don't do the
equivalent for POSIX.1c ("formerly known as POSIX.4a").
There are several problems with the XPG3 entry:
"first significant release" - although I suppose XPG3 could
be considered more significant than XPG2 because it was the
first one to incorporate POSIX.1, I don't think it's fair to
imply that XPG2 was not significant. (E.g. XPG2 was
significant in that it was the first release to include
I18N, and the first that had a conformance test suite.)
"produced by the X/Open Company, a multivendor consortium" -
this conflates two different things called X/Open. X/Open
Company Limited is the UK company that did the editing work,
organised meetings, etc. X/Open Group is the consortium
whose members developed the technical content.
"This multivolume guide was based on the POSIX standards" -
at the time there was only one POSIX standard, namely
POSIX.1-1988. The first release to incorporate POSIX.2 was
XPG4 (which you may consider worth noting in the XPG4
entry).
To fix these problems I would suggest changing the entry to:
XPG3 Released in 1989, this was the first release of the X/Open
Portability Guide to be based on a POSIX standard
(POSIX.1-1988). This multivolume guide was developed by the
X/Open Group, a multivendor consortium.
Under SUSv2 I would suggest changing:
Sometimes also referred to as XPG5.
to:
Sometimes also referred to (incorrectly) as XPG5.
Under POSIX.1-2001, SUSv3: "XSI conformance constitutes the Single
UNIX Specification version 3 (SUSv3)" is problematic. I think I
touched on this in the previous discussion. I would suggest
deleting that sentence and instead inserting, before "Two
Technical Corrigenda ...", the following:
The Single UNIX Specification version 3 (SUSv3) comprises the
Base Specifications containing XBD, XSH, XCU and XRAT as
above, plus X/Open Curses Issue 4 version 2 as an extra volume
that is not in POSIX.1-2001.
Something similar is needed in the POSIX.1-2008, SUSv4 entry where
it talks about "the same four parts". The extra volume this time
is X/Open Curses Issue 7.
]]
Cowritten-by: Geoff Clare <gwc@opengroup.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove ".br" if it is before a line that starts with a space
character, as such lines automatically cause a break.
###
The output is unchanged, except two empty lines are added at the
bottom (before the footer line) in the output of "nroff" for the files
"alloc_hugepages.2" and "userfaultfd.2".
###
Examples of warnings from "mandoc -Tlint":
mandoc: access.2:283:2: WARNING: skipping paragraph macro: PP after SH
These links were mostly created when pages were moved between
sections, in almost every case several years ago. The idea
was to allow people time to get used to the new section numbers
while still having commands of the form "man <sec> <page>"
work as before. Let's assume that people have now had time to
get used to the new section numbers, and remove these links.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Fri, 19 Jun 2020 18:50:47 +0000 (20:50 +0200)]
getdtablesize.2, sigqueue.2, clock_getres.3, clock_gettime.3, clock_settime.3, attr.5, numa_maps.5: Remove old links
These are all links that were created several years ago, mainly
when pages were migrated to different sections, in order to
allow the 'man' commands using the old section numbers to work.
However, the plan was always to eventually remove them, after
allowing people who cared to get used to the new section numbers.
Now, after 5+ years in each case, it's time to remove
these links.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I believe new users should be discouraged from using atoi() and
that its disadvantages should be explained.
I added the information that 0 is returned on error - although C
standard and POSIX say that "If the value of the result cannot be
represented, the behavior is undefined." there are some
interpretations that 0 has to be returned
https://stackoverflow.com/questions/38393162/what-can-i-assume-about-the-behaviour-of-atoi-on-error
and this is also what happens in practice with glibc, musl and
uClibc.
Signed-off-by: Arkadiusz Drabczyk <arkadiusz@drabczyk.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
proc.5: Inform that comm in /proc/pid/{stat,status} might also be truncated
pgrep for example searches for a process name in /proc/pid/status
and therefore cannot find processes whose names are longer than 15
characters unless -f is specified.
Signed-off-by: Arkadiusz Drabczyk <arkadiusz@drabczyk.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Mon, 15 Jun 2020 14:23:49 +0000 (16:23 +0200)]
setns.2: Document the use of PID file descriptors with setns()
Starting with Linux 5.8, setns() can take a PID file descriptor as
an argument, and move the caller into or more of the namespaces of
the thread referred to by that descriptor.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Mon, 15 Jun 2020 10:01:31 +0000 (12:01 +0200)]
setns.2: It is possible to setns() to the caller's current PID namespace
The page currently incorrectly says that 'fd' must refer to
a descendant PID namespace. However, 'fd' can also refer to
the caller's current PID namespace. Verified by experiment,
and also comments in kernel/pid_namespace.c (Linux 5.8-rc1).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Dave Martin [Tue, 9 Jun 2020 11:30:57 +0000 (13:30 +0200)]
prctl.2: Add PR_PAC_RESET_KEYS (arm64)
Add documentation for the PR_PAC_RESET_KEYS ioctl added in Linux
5.0 for arm64.
Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I've traced this to SELinux policy denying the connection. This is
on a Fedora 23 VM:
$ cat /etc/redhat-release
Fedora release 23 (Twenty Three)
$ uname -a
Linux mako-fedora-01 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9 14:51:40
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
The manpage says this can happen when connecting to a broadcast
address, or when a local firewall rule blocks the connection.
However, the address above is unicast, and using 'wget' from
another account to access the URL works fine.
The context is that we're building an OS image, and this involves
downloading RPMs through a proxy. The proxy (polipo) is labelled
by SELinux, and I guess there is some sort of policy that says
"proxy can only connect to HTTP ports". When trying to connect to
a server listening on a port that is not labeled as an HTTP server
port, I guess SELinux steps in. With 'setenforce 0', the build
works fine. In the kernel sources I see connect() calls
security_socket_connect() (see
https://elixir.bootlin.com/linux/latest/source/net/socket.c#L1855),
which calls whatever security hooks are registered. I see the
SELinux hook getting registered at
https://elixir.bootlin.com/linux/latest/source/security/selinux/hooks.c#L7047,
and setting a perf probe on the call proves that the
selinux_socket_connect function gets called (while
tcp_v4_connect() is not).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Tue, 9 Jun 2020 08:03:04 +0000 (10:03 +0200)]
user_namespaces.7: Clarify "system time"
From an email conversation with Léo Stefanesco:
> In the man7.org version of the man page for user_namespaces(7), it reads:
>
> there are many privileged operations that affect
> resources that are not associated with any namespace type,
> for example, changing the system time
> (governed by CAP_SYS_TIME)
>
> which is not consistent with time_namespaces(7).
In fact, strictly peaking the text still is correct, even after
the arrival of time namespaces.
Time namespaces virtualize only the boot-time and monotonic
clocks, not the "real time" (i.e., calendar time), which is the
time referred in the passage you quote.
That said, the text is perhaps now a little misleading, and
a little clarification would help. I changed the text to:
there are many privileged operations that affect
resources are not associated with any namespace type,
for example, changing the system **(i.e., calendar)** time
(governed by CAP_SYS_TIME)
Reported-by: Léo Stefanesco <leo.lveb@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Thu, 16 Apr 2020 06:28:05 +0000 (08:28 +0200)]
ioctl_list.2: Remove this page
This page was first added more than 20 years ago. Since
that time it has seen hardly any update, and is by now
very much out of date, as reported by Heinrich Schuchardt
and confirmed by Eugene Syromyatnikov.
As Heinrich says:
Man-pages like netdevices.7 or ioctl_fat.2 are what is
needed to help a user who does not want to read through the
kernel code.
If ioctl_list.2 has not been reasonably maintained since
Linux 1.3.27 and hence is not a reliable source of
information, shouldn't it be dropped?
My answer is, yes (but let's move a little info into ioctl(2)).
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reported-by: Eugene Syromyatnikov <evgsyr@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
John Marshall [Mon, 8 Jun 2020 11:04:16 +0000 (12:04 +0100)]
random.3: Change "RAND_MAX" tp "2^31-1"
RAND_MAX is for rand(3). POSIX fixes random()'s range at 2^31-1;
RAND_MAX may be smaller on some platforms (even though with glibc
or musl on Linux they are the same).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Amir Goldstein [Fri, 29 May 2020 09:25:30 +0000 (12:25 +0300)]
fanotify.7, fanotify_mark.2: Clarify FAN_ONDIR in output mask
FAN_ONDIR was an input only flag before introducing
FAN_REPORT_FID. Since the introduction of FAN_REPORT_FID, it can
also be in output mask.
Move the text describing its role in the output mask to fanotify.7
where the other output mask bits are documented.
[mtk: commit message tidy-up]
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Amir Goldstein [Fri, 29 May 2020 09:25:29 +0000 (12:25 +0300)]
fanotify_init.2: Move out of place entry FAN_REPORT_FID
It was inserted in the middle of the FAN_CLASS_ multi flags bit
and broke the multi flag documentation.
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
FAN_DIR_MODIFY was disabled for v5.7 release by kernel commit f17936993af0 ("fanotify: turn off support for FAN_DIR_MODIFY").
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
