Re: systemd-fsck?
Le Sat, 10 May 2014 16:00:39 +0200,
Martin Steigerwald <Martin@lichtvoll.de> a écrit :
[...]
>
> Thats exactly the kind of reaction I meant:
>
> Frankly, I just *don´t* care where it is fixed. If its in dirmngr,
> fine.
>
> Yet: I do think its about high time systemd developers and packagers
> adopt an attitude of "never break userspace" like the kernel
> developers do.
Sure that the attitude "I don't care where the root cause of a problem
lies", opening 3 different bugs against 3 different packages for the
same issue and then complain publicly that the bug is not fixed is good
and productive...
May I remind you that everybody in Debian is working as a volunteer and
that we have limited time and motivation and that this kind of
continuous ranting is not helping.
>
> The plain fact:
>
> Using systemd breaks something that worked for probably a decade or
> longer before however long that su is in that init script. So on what
> account do you call calling "su" in an init script a bug? It may not
> be the most elegant solution to do things, granted, but a bug? Come
> on. Calling it a bug just cause systemd / policykit treat calling su
> in an initscript as they do is quite arrogant in my eyes.
IMVHO opening a PAM session in an initscript is a bad idea from day
one, as you don't know which modules are being called, as it can create
bogus audit trails or cause other subtile issues.
Here it's just a symptom being revealed.
>
> Telling "Go away, the bug is elsewhere" is just not an approbiate
> reaction for developers of a low level system component. Approbiate
> in my eyes would be caring and helping along with the issue to be
> fixed no matter where the fix will land in. I.e. provide help and a
> patch for dirmngr, or even a systemd service file, instead of getting
> systemd installed via some apt-get dist-upgrade and look at what
> breaks if its clear before hand that hibernation for any user of a
> full KDE installation is included in the list of breakages.
>
> Thats it.
I personally think that systemd team (of which I'm NOT part) is already
doing a really good work to fix integration issues, they are already
providing patches or .services for main packages but they cannot fix
everything.
> Additional to that: su does not by itself create another seat. Its
> still the same laptop. One keyboard, one display, *one* seat. Even if
> I run a ten different desktop sessions with ten different users on
> it, its just *one* seat. Which means that when I tell to hibernate,
> there is just no other user around who can be asked whether they are
> fine with it.
>
> It would be different with an application server where many people
> log in, it may be different with SSH sessions opened, but this is
> *just* a laptop. Well but this is all in the bug reports I mentioned.
Just using su will not cause logind to register a new session if you
are already registered and if the loginuid attribute is properly set on
your system by pam_loginuid, a new session is registered only if you are
logging in from an entry point application like login or a DM.
Even if you have one seat, that doesn't mean that other logged in users
dont have long running process (compilations, download,...) that can be
interrupted like that at any time.
I personally find this behavior sensible and conservative, but even if
after the dirmngr bug is fixed, you still don't like this behavior, it
can be configured by changing the policykit configuration, I think that
Michael already pointed you to some documentation.
> Again, I am not ranting about any technicalities here. I am ranting
> about attitude. Thats it.
Reply to: