Chris's Wiki :: blog/linux/ChronyDisableIPv6 Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/ChronyDisableIPv6?atomcommentsDWiki2018-03-06T13:06:31ZRecent comments in Chris's Wiki :: blog/linux/ChronyDisableIPv6.By Chris Siebenmann on /blog/linux/ChronyDisableIPv6tag:CSpace:blog/linux/ChronyDisableIPv6:cc18bc75d424a578c2d7f739f5731fc542f48b52Chris Siebenmann<div class="wikitext"><p>I'm mostly referring to the PIDs being so high, although I think this is
the first time I've seen them exceed 16 bits on machines I've looked at.
This machine has only been up a few days (it last rebooted Friday for a
kernel update), so hitting 4 million (and then rapidly rolling over since
then) is decidedly unusual. My logs suggest that it started happening
right at boot; within half an hour after boot it had churned over 300,000
PIDs, and some evidence suggests it's kernel threads.</p>
<p>(This appears to be the first time it's happened on this machine.
Certainly it didn't happen in recent boots, based on logs with PIDs
in them.)</p>
</div>2018-03-06T13:06:31ZFrom 78.58.206.110 on /blog/linux/ChronyDisableIPv6tag:CSpace:blog/linux/ChronyDisableIPv6:da7d1c6c79c97c769fa75b71b4927ef75bcf16c6From 78.58.206.110<div class="wikitext"><p>Are you referring to PIDs wider than 16-bit in general, or just to them being higher than you expect for your workstation's uptime?</p>
<p>Linux <code>kernel.pid_max</code> goes up to 2^22, and perhaps your distro decided to make use of it? (I've been setting it to maximum for a long time just to see what breaks. Nothing broke. After all, <code>pid_t</code> is an int.)</p>
</div>2018-03-06T05:05:27Z