Re: Bug#950166: buster-pu: package systemd/241-7~deb10u3
Control: tags -1 + confirmed d-i
On Wed, 2020-01-29 at 19:24 +0100, Michael Biebl wrote:
> systemd (241-7~deb10u3) buster; urgency=medium
>
> * core: set fs.file-max sysctl to LONG_MAX rather than ULONG_MAX.
> Since kernel 5.2 (but also stable kernels like 4.19.53) the
> kernel thankfully returns proper errors when we write a value out of
> range to the sysctl. Which however breaks writing ULONG_MAX to
> request the maximum value. Hence let's write the new maximum value
> instead, LONG_MAX. (Closes: #945018)
>
> https://salsa.debian.org/systemd-team/systemd/commit/673e108907baf1a242c4842ace6e9e3a23b11d52
>
> Upstream cherry-pick, fixed in unstable/testing. Rather straight-
> forward fix. I wasn't planning doing a stable upload for this issue
> alone but only in combination with other fixes.
>
> * core: change ownership/mode of the execution directories also for
> static users. This ensures that execution directories like
> CacheDirectory and StateDirectory are properly chowned to the user
> specified in User= before launching the service. (Closes: #919231)
>
> https://salsa.debian.org/systemd-team/systemd/commit/e9c8637d06e373430b8986643cfb537a23b0b1fd
>
> This is an upstream cherry-pick from
> https://github.com/systemd/systemd/pull/12005
> I'm a bit undecided whether to cherry-pick all changes from this PR
> (which look like worthwile changes to have) or only commit
> 206e9864de460dd79d9edd7bedb47dee168765e1.
>
> I decided for the latter for now, as it keeps the changes minimal and
> seems to fix the issue at hand. That said, would welcome your
> feedback here. Would you prefer that we pull in the complete upstream
> PR #12005 or keep the changes minimal?
>
> PR #12005 is part of v242, i.e. fixed in unstable/testing.
I think I'd be OK with either, looking over the changes, so am happy to
leave the choice up to your judgement. If you decide to include all of
the changes, please could you update the diff attached here for
completeness.
> Those changes don't touch udev, but will need an ack from kibi (which
> I've CCed).
Likewise.
Regards,
Adam
Reply to: