Eric Dumazet noted that EINVAL was not documented. Some further
digging shows that it's also not diagnosed consistently.
See https://bugzilla.kernel.org/show_bug.cgi?id=47111.
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The signal that causes the handler to be invoked is blocked,
but saying "by default" implies that this can be changed via
the API. It cannot. (One needs sigaction(2) for that.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This point is already noted when discussing search order for
libraries, but it's woth repeating under the specific discussion
of LD_LIBRARY_PATH further down the page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
Guillem Jover