[systemd-devel] Antw: systemd prerelease 243-rc2

[Lennart Poettering]

On Do, 22.08.19 15:38, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> >>> systemd tag bot <donotreply-systemd-tag at refi64.com> schrieb am 22.08.2019
> um
> 13:56 in Nachricht <20190822115637.1.05C510C92B339AF7 at 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...

Well, there's only one way to find out whether this is a real or just
a percieved problem...

> I still wonder why systemd has to mess with all these kernel variables BY
> DEFAULT.

Well, it fixes real problems, and it pushes the envelope a bit. If we
wouldn't do that, who would?

If there apps that assume pid_t is 16bit, then that's a problem in
that software, and should be fixed. Sticking to 16bit just means the
bug is never triggered, not that the bug isn't there, and the right
approach to get it fixed is exposing it.

Thing is: systemd upstream versions are generally not added unmodified
to stable enterprise distros, but go into the more bleeding edge
distros first, and only after a long stabilization phase enter the big
commercial distros. Hence, if we want to fix the pid_t issue the right
place is to spearhead it in systemd and see how it works. And if all
is good (and I think there's a good chance this will go down without
any major trouble) then we have improved things a bit, and before you
see the chance in the commercial distros will be a bit.

> I think systemd is too complex already, and it's getting more
> complex every release. I don't like those attempts to build another
> operating system in the init process, but your opinions may vary.

Ahum, this change is a single line added to a default sysct.d/ file we
ship. I mean, you may have your opinions, but this line is not applied
in PID 1 at all, it doesn't touch the "init process" at all...

Lennart

--
Lennart Poettering, Berlin