Along with a trivial change in 1/2 (which would otherwise textually conflict) this 2/2 notes that since Linux 4.18 the promise that the "comm" field in /proc/PID/stat will be no longer than 15 characters hasn't been true for the "kworker" processes. This caveat was noted in a discussion on HN https://news.ycombinator.com/item?id=34093845; I myself have code in git/git@2d3491b117c (tr2: log N parent process names on Linux, 2021-08-27) which won't do anything bad if this were to be combined with PID recycling (with a kernel thread usurping the PID of a process that used to belong to our parent), but it will behave unexpectedly. I wrote that code against the promises made in proc(5) at the time. As I'm about to send this I notice that [1] was sent yesterday, which textually conflicts with this submission[1]. I've added its authors to the CC (I'm not on the linux-man list). Personally I never read the note that the "comm" string would be contained in parentheses as a promise that the kernel was going to strip ")" from userspace names, or only allow balanced parentheses or whatever. I'd think most programmers would see a mention of a \0-delimited string and assume that it would contain anything but "\0" (as is the case here). Perhaps it's useful to some to include such a clarifying blurb, but I personally find it superfluous. Whereas the fix here is a fix for a promise we're currently making which hasn't been true since v4.18. 1. https://lore.kernel.org/linux-man/Y6SJDbKBk471KE4k@p183 Ævar Arnfjörð Bjarmason (2): proc.5: note that "cmdline" might be favored over "stat.comm" by ps(1) proc.5: the "comm" field can be longer than 16 bytes man5/proc.5 | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 2.39.0.1106.gf45ba805d1a
