Re: systemd bug closed - next steps?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 09/22/2014 at 05:39 AM, berenger.morel@neutralite.org wrote:
> Le 22.09.2014 01:51, John Hasler a écrit :
>
>> Martin Read writes:
>>
>>> consolekit is indeed the thing that systemd-logind replaces
>>> (and systemd-logind was the reason the maintainers of
>>> consolekit stopped maintaining it).
>>
>> So who is going to step forward and start maintaining it?
>
> Nobody needs to. systemd-login does *not* depends on the init
> system. At no levels. So why should someone have to maintain an
> alternative? (well, there are probably tons of reasons, indeed, but
> systemd-login being a part of systemd is not a correct one since
> login part does not depends on init part.)
So I was remembering wrong, and the consolekit angle is apparently a
false trail. The problem is not systemd-logind (except from the
perspective of people who just don't want any systemd-project code on
their systems in the first place), but the dependency from
libpam-systemd on systemd-sysv.
The fact that we went down that false trail is my fault. The question of
"what did these packages do before systemd was available?" was asked,
and I provided an incorrect answer, due to my faulty memory. I apologize
for that mistake, for the ensuing confusion, and for any associated FUD.
Revisiting that question now, it's not quite as simple as "before
systemd was available". There are actually three timeframes to consider:
1. Now, with libpam-systemd depending on systemd-sysv (and thus on
systemd being PID 1), as a source of cgroups management functionality.
2. The previous timeframe, with libpam-systemd not depending on
systemd-sysv, because it provided its own cgroups management.
3. The timeframe preceding that one, with libpam-systemd not available
at all.
In timeframe 2, the packages in question depended on libpam-systemd,
just as they now do. The only difference is that this dependency did not
result in an indirect dependency on a particular init system.
In timeframe 3, the packages in question did not depend on
libpam-systemd, because it was not available. This would have to be
confirmed by looking at the individual packages, but I strongly suspect
that they simply did not provide the functionality which libpam-systemd
now enables.
The transition between timeframe 3 and timeframe 2 came when
libpam-systemd became available, upstreams added support for the new
features it provided, and package dependencies were added appropriately.
There's nothing visibly wrong at this stage.
The transition between timeframe 2 and timeframe 1 apparently occurred
because of a decision by the Linux kernel's cgroups maintainer (or
someone with a good claim at authority in that area, anyway) that having
multiple programs maintaining multiple cgroups hierarchies - or having
multiple programs writing to a single cgroups hierarchy - was bad
design, and should no longer be supported at some point.
In response to that, the sytemd project removed cgroups management from
libpam-systemd, and made libpam-systemd rely on the cgroups management
available in systemd-sysv (the PID-1 systemd).
As a result, without having changed anything themselves, suddenly all of
the packages which had already depended on libpam-systemd now indirectly
depended on having systemd be PID 1.
What I maintain / argue is that even assuming the kernel's cgroups
maintainer's decision was correct (on which I have not yet established
any opinion), the correct thing to do in response to that decision would
not have been to move all systemd cgroups handling into PID 1 as the
most central place where it was already implemented, but to move it all
*out* of PID 1 into a separate, standalone daemon. (Or even library, if
suitable.)
This issue has already been worked around in Debian by the
implementation of cgroups support in systemd-shim, using cgmanager.
However, that's still a workaround, because the design flaw in having
this feature be (primarily) provided by systemd itself is still present.
It has been suggested (in filed bugs) that one of the primary
consequences of this flaw - the automatic transition to systemd-as-PID-1
when installing packages which depend on libpam-systemd, while not
already having systemd-shim installed - be minimized by expressing the
dependency on that cgroups management as preferring systemd-shim (the
"standalone" implementation) over systemd-sysv (the
init-system-dependent implementation).
The Debian systemd maintainers have rejected this suggestion, with
reasonable arguments (albeit ones which I think are insufficient). There
is presently TC discussion going on over whether or not to override that
rejection.
- --
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJUIBkVAAoJEASpNY00KDJr/OoP+gLnnLVjt5JPYTxZbmcq6LQX
yNvRhPvvpl240TRq9DigtguLTahdUc1NvGeX17cnO0G4cDLpjoLF3Fv6NdU1iv3d
cRjm+++tzgYz8zehNrpXwsMPD4LyUeoexAvUEI2BIUnIQeEAJ2QtNlnbf9Bm9J5l
Hp7jTZRjVW91mi0tD80xk2pw5gNcFBbuqKhiu6ve3z/Os64suhE847X46wId8e/b
jUY6EFdC4IE9QrFEpl1VXnx3FNXc5iej3dA86i+gbEM6qMn3SWswHKNTZAS1IkR/
MhjxzUcnXcIlWjqGc4ue8p0UbjMP3t+2lnYOuP6/ntTpUuCGmgnX94iWqkkhqNUI
6evzl65QLv2++3v7O9tg5b3mEzmzFzyGFM6rdYZrNfCFiQ+SGaaxJZ9UEaK1XwGG
TtGMhshRUy/WcwH1P1RuCN53PW5vsWeY6100i7k9rVbR2GGMTAqLyv6dDYzH7T4C
VAZ3+e3SReFvEcy1KpbjIxvJteTuv5BbMWS18Tu0bhMqNuKD/cYT7UI149OI5LrG
81gGXR3gTKecE47rdtJLn1gBol+gVwtqVP2mKCfTKgnPnvVwVkCqhah4MjIBJ6az
NntUvC9YDSI+IkOijayZyPnUgKNDUX1fGU3nhnn6YaZG/nk4HEgRr6JhS4TbdnBk
g6FXi2K0hmoAM8f+t1Wm
=8TuT
-----END PGP SIGNATURE-----
Reply to: