Writing "another thread" in these pages implies that these
functions can't be used to send a signal to the calling thread
itself, which is of course untrue.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The unit of measurement changed from jiffies to clock ticks in
Linux 2.6.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675891
Reported-by: Frédéric Brière <fbriere@fbriere.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
LOG_AUTH is in POSIX, and widely available. There
seems to be no basis to the claim it is deprecated.
Quoting Simon:
I cannot find any other source that claim LOG_AUTH is
deprecated in any way. LOG_AUTH is distinct from
LOG_AUTHPRIV. The GNU C Library manual only documents
LOG_AUTH. The header files contains both without any
comment. Common systems like Debian appear to refer to
both auth and authpriv facilities in syslog configurations.
Popular daemons appear to use both facilities.
Both facilities are discussed in several RFCs.
See https://bugzilla.kernel.org/show_bug.cgi?id=46091
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Executive summary: a sane application can't rely on any
particular behavior if another thread closes a file descriptor
being monitored by select().
See https://bugzilla.kernel.org/show_bug.cgi?id=40852
Reported-by: Stephane Fillod <fillods@users.sf.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Fredrik (and as far as I can tell the problem
went back to 2.6.0):
The timeout argument has an upper limit. Any values above that
limit are treated the same as -1, i.e. to wait indefinitely.
The limit is given by:
#define EP_MAX_MSTIMEO min(1000ULL * MAX_SCHEDULE_TIMEOUT / HZ, \
(LONG_MAX - 999ULL) / HZ)
That is, the limit depends on the size of a long and the timer
frequency. Assuming the a long is never smaller than 32 bits
and HZ never larger than 1000, the worst case is 35 minutes.
I think this should be mentioned under "BUGS".
Although this is likely to be fixed in the future
(http://lkml.org/lkml/2010/8/8/144), the problem exists in
at least 2.6.14 - 2.6.35. I don't know if select(2) and poll(2)
are affected.
https://bugzilla.kernel.org/show_bug.cgi?id=20762
Reported-by: Fredrik Arnerup <arnerup@kth.se>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
<groff: iso_8859-2.7>:89: warning: can't find special character `shc'
This is the only "iso_8859-*.7" file that has this (now)
undefined character. The code in column four in "iso_8859-1.7" is
"0x2D" ("HYPHEN, MINUS SIGN" or "HYPHEN-MINUS") instead of "0xAD".
See Debian bug 156154 (or package "manpages").
There should be an explanation for this graphic character and the
code should be 0xAD in iso_8859-1.7 (as in all others), even
though "[gn]roff" does not display a "HYPHEN" in that position of
the table.
The line with "SOFT HYPHEN" gets a footnote and a short
explanation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Rasmus:
Both my system's man-pages (3.22) and the latest online
(3.41) show:
int mprotect(const void *addr, size_t len, int prot);
as the prototype for mprotect(2). However, POSIX [1] and the
actual sys/mman.h (on all the systems I checked) do not have
the const qualifier on the first argument.
Reported-by: Rasmus Villemoes <Rasmus.Villemoes@decode.is>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The syntax .UR http://example.com paired with .UE will create
links which one can interact, if the pager allows that. One
way to see the effect is ask the man(1) command to use browser
display, e.g.:
man -H man7/uri.7
("\:" is optional groff syntax to permit hyphenless line breaks.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
uri(7) documents that "Older documents suggested inserting the
prefix 'URL:' just before the URI, but this form has never
caught on." and advise to "enclosed in angle brackets" (and a
few other alternatives).
This patch removes an instance of 'URL:' from the page.
Reported-By: Denis Barbier <bouzim@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I didn't like ithe "SIGKILL operates similarly, with exceptions"
phrase (if it's different, then it's not "similar", right?),
and now I got around to changing it. Now it says simply:
"SIGKILL does not generate signal-delivery-stop and therefore
the tracer can't suppress it."
Replaced "why WNOHANG is not reliable" example with a more
realistic one (the one which actually inspired to add this
information to man page in the first place): we got
ESRCH - process is gone! - but waitpid(WNOHANG) can still
confusingly return 0 "no processes to wait for".
Replaced "This means that unneeded trailing arguments may
be omitted" part with a much better recommendation
to never do that and to supply zero arguments instead.
(The part about "undocumentedness" of gcc behavior was bogus,
btw - deleted).
Expanded BUGS section with the explanation and an example
of visible strace behavior on the buggy syscalls which
exit with EINTR on ptrace attach. I hope this will lead
to people submitting better bug reports to lkml about
such syscalls.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
For IOPRIO_WHO_PROCESS, who==0 means operate on the caller.
For IOPRIO_WHO_PGRP, who==0 means operate on the caller's
process group.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652443
Reported-by: Марк Коренберг <socketpair@gmail.com>
Reported-by: Kalle Olavi Niemitalo <kon@iki.fi>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>