On 8/26/19 9:43 AM, Ulrich Windl wrote:
Mantas Mikulenas schrieb am 23.08.2019 um 05:55 in
> Nachricht
> :
>> On Thu, Aug 22, 2019, 16:38 Ulrich Windl
>
>> wrote:
>>
>> systemd tag bot schrieb am
>>> 22.08.2019
>>> um
>>> 13:56 in Nachricht <20190822115637.1.05c510c92b339...@refi64.com>:
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download
>>> the
tarball here:
>>>
>>>
* On 64 bit systems, the "kernel.pid_max" sysctl is now bumped
> to
4194304 by default, i.e. the full 22bit range the kernel
>>> allows,
up
from the old 16bit range. This should improve security and
robustness, as PID collisions are made less likely (though
>>>
>>> I doubt it's increasing robustness for any existing application as
>>> pid_traditionally was 16 bit. I don't know if some applications try to
>>> sprintf() a pid into a char[6], but if they do, it might cause an
>>> application
>>> failure...
>>>
>>
>>
>> I've been using this value for at least 5 years, and did expect many issues
>> at first, but so far haven't encountered any at all.
>>
>> (I do kind of suspect that if there are any programs affected by this and
>> without source code available, they would be so old that they wouldn't
>> really run on a bleeding-edge distro anyway...)
>
> Having read some C questions in stackoverflow yesterday, I'm afraid there are
> quite a lot of programmers out there writing code you couldn't even imagine in
> your most terrible nightmares ;-)
> So distribution code may be safe, but some in-house stuff or even "commercial"
> stuff may be horrible:
> (Not to long ago I had a problem that some commercial application only started
> up if the text terminal was wider than 80 characters. Why? The C program
> called
> "ps" internally, and that in turn truncated output lines depending on the
> value
> of COLUMNS environment...)
>
> I think you really don't know what the most terrible imaginable programmer can
> write... ;-)
>
> Or maybe the infamous Ariane V failure: They reused software they had tested
> before, but the hardware was different ;-)
Frankly, if such software exists and is used somewhere, it should definitely get
fixed or obsoleted. Following your mindset of keeping backward compatibility
even with broken or not future-proof software, we should also revert all changes
regarding the unix timestamp and year 2038 (in general), because changing
the datatype size from 32bit to 64bit _might_ break someone's code.
By the time this change gets to your enterprise distro, it should be pretty well
tested by various distributions close to the upstream. And even if that's not
enough,
you an simply override the value back when you package systemd for downstream.
From
what I can tell from various reports from our customers in RHEL, bumping
kernel.pid_max to the full 22bit range will be more than a welcome change.
--
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
