There's no need really to boldface names of standards and
character sets.
Reported-by: Marko Myllynen <myllynen@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There's no need really to boldface names of standards and
character sets.
Reported-by: Marko Myllynen <myllynen@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* Move /proc/sys/kernel/printk from proc(5) to this page,
and correct various details in the discussion of that file.
* Rewrite and correct various other details on the page.
* Clean out some crufty text.
* Miscellaneous minor fixes.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It makes more sense to have the /proc/sys/kernel/printk with
the related material in syslog(2).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The kernel header file mentioned in the discussion of the KERN_*
constants has morphed and is no longer exported inside glibc.
And the definitions of the constants themselves changed subtly
with kernel commit 04d2c8c83d0e3ac5f78aeede51babb3236200112.
So, rewrite the description of the constants to be a bit more
abstract.
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Explain the circumstances in detail, indicating that the
bug may be very unlikely to occur in practice.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As well as inotify_rm_watch(), file deletion and unmounting a
filesystem can also cause a watch descriptor to be deleted.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Watch descriptor IDs are returned by inotify_add_watch().
When calling inotify_rm_watch() an IN_IGNORE is placed on the
inotify queue pointing to the ID of the removed watch.
inotify_add_watchi() should not return a watch descriptor ID for
which events are still on the queue but should return an
unused ID.
Unfortunately, the existing Kernel code does not provide such a
guarantee.
Actually, in rare cases watch descriptor IDs are returned by
inotify_add_watch() for which events are still on the inotify
queue.
See https://bugzilla.kernel.org/show_bug.cgi?id=77111
Cowritten-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
glibc refers in locale/programs/charmap.c to ISO C 99 section
7.17.(2) and ISO C 99 section 5.2.1.(3) that if a character map
is not ASCII compatible then the locale using it is not ISO C
compliant. This does not state anything about the character set
itself.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
While trying to reconcile the new features in glibc with the
documented entries in the linux kernel man pages I noticed that
glibc exports prlimit64 for use by 32-bit applications (as does
the linux kernel), but that prlimit64 was not defined in the
syscalls list or in the prlimit-related page.
This is not the complete fix for this, but I don't have the time
to explain why and when prlimit64 should be used (or how it should
be used safely). Therefore I'm just patching the syscalls.2 list
to show that prlimit64 exists and was added in 2.6.36 (verified
with git by checking out the tags before and after).
Unless you've purposely excluded prlimit64 to avoid telling users
about it because it's complicated, please apply.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk