Please find attach a consistency fix: there were only five
"zeroes" but twenty four "zeros" in those manual pages.
(Make all instances "zeros".)
Signed-off-by: David Prévot <taffit@debian.org>
Document the MADV_HUGEPAGE and MADV_NOHUGEPAGE flags added to
madvise() in Linux 2.6.38.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux 2.6.39, unprivileged processes under the
SCHED_IDLE policy can switch to another nonrealtime
policy if their nice value falls within the range
permitted by their RLIMIT_NICE limit.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These flags, designed for discovering holes in a file,
were added in Linux 3.1. Included comments from Eric
Blake and Sunil Mushran.
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Sunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Alan Curry:
According to man2/lseek.2,
This document's use of whence is incorrect English, but
maintained for historical reasons.
What is the grammatical objection?
From WordNet (r) 3.0 (2006) [wn]:
whence
adv 1: from what place, source, or cause
Wiktionary:
[edit] Adverb
whence (not comparable)
1. From where; from which place or source.
lseek's second parameter is a distance to be traveled, and
the third parameter chooses the starting point from which
that distance is measured. How is that not a "whence"?
Looking at some man page archives, I found that the accusation
of incorrect English goes back to before 4.4BSD. It survives
not just in the linux-man-pages but also in recent versions
of {Net,Open,Free}BSD. The name "whence" for this parameter
goes back at least to V7.
Of all the people who have read this page over the years,
am I the only one wondering... what's this about? Who decided
that "whence" was incorrect and put that note in the man page?
Was there ever anything wrong, or do we have someone's
20-year-old unresearched pet peeve lingering in the man pages?
Reported-by: Alan Curry <pacman@kosh.dhis.org>
Reported-by: Reuben Thomas <rrt@sc3d.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Now that the underlying system call rt_sigqueueinfo(2) is
properly documented, move sigqueue() to Section 3, since
it is really a library function.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This replaces the previous '.so' man page link file for
rt_sigqueueinfo.2, which linked to ths sigqueue() man page.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
We've recently discovered that GDB will fail to attach to any
process that sets itself non-dumpable. Tested on kernel 2.6.32,
with:
int main(int argc, char *argv[])
{
if (prctl(PR_SET_DUMPABLE, 0, 0, 0) != 0) {
perror("prctl");
}
printf("Run gdb %s %d\n", argv[0], getpid());
sleep(20);
abort();
}
./a.out
Run gdb ./a.out 30476
gdb -q ./a.out 30476
Reading symbols from /tmp/a.out...done.
Attaching to program: /tmp/a.out, process 30476
ptrace: Operation not permitted.
/tmp/30476: No such file or directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The current version of the page says (under ERRORS):
> EBUSY (not on Linux)
> The file pathname cannot be unlinked because it is being
> used by the system or another process and the
> implementation considers this an error.
But if you look in the kernel source file fs/namei.c
at routine may_delete() you'll see two occasions where
an EBUSY is generated. So the above "not on Linux" is wrong.
I suggest that this '(not on Linux)' be removed. It may
also improve the page if the commentary is reworded to give a
better description of the two situations. Something along
the lines of:
> The file pathname cannot be unlinked because it is being used
> by the system, e.g. if some (relative) rootdir is mounted upon it,
> or because the NFS client software created it to represent an
> active but otherwise nameless inode ("NFS silly renamed").
Just FYI: the NFS silly rename (you'll find this term mentioned
in the kernel source code) is described at:
http://nfs.sourceforge.net/#section_d
under section D2. The reason I found this manpage bug is because
I stumbled upon one of these silly renamed files, and an strace
of the rm-command revealed the EBUSY return errno.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk