Re: systemd-fsck?
Am Samstag, 10. Mai 2014, 15:36:26 schrieben Sie:
> Martin Steigerwald wrote:
> > Am Freitag, 9. Mai 2014, 20:30:22 schrieb Michael Biebl:
> > > Am 09.05.2014 19:56, schrieb Steve Langasek:
> > > > I don't think systemd integration is in a state today that this
> > > > is ready to
> > > > become the default.
> > >
> > > What are you missing?
> >
> > Suitable explaination and reaction to bug reports like:
> >
> > polkit-kde-1: requires root password for hibernate, wrongly reports
> > other users are logged on
> > http://bugs.debian.org/727645
> >
> >
> > This last time I tested still breaks hibernation for any users of a
> > full KDE installation including dirmngr. *Months* after it was
> > reported.
> >
> > I saw a work-around / partly fix posted which I missed before, by
> > changing
> >
> > output=$(su -c ". /lib/lsb/init-functions && umask 027 &&
> > start_daemon -p $PIDFILE $DAEMON --daemon --sh" dirmngr) || return 1
> >
> > in /etc/init.d/dirmngr to start-stop-daemon[1]. I will try this and
> > report back to the bug report.
> >
> >
> > Still on reporting this bug as well [2] like this I got the
> > impression of being told: "Go away, the bug is elsewhere, I don´t
> > care." Basically you just told me that policy-kit just does what it
> > is setup to do[3]. Yet with installing systemd it hibernation in full
> > KDE setups breaks and with a user hat on – I contributed a few Debian
> > packages – I just don´t care where this is to be fixed. I was baffled
> > at being told that this behaviour is supposed to be there by design
> > and got the impression that I was expected to put up with it.
> >
> > While such a bug is still unfixed in packages I think its not
> > suitable to make systemd a default as I expressed here[4]. Unless you
> > want users of unstable and testing to be annoyed with systemd.
> >
> > I accept that the fix may lay elsewhere, but I found your responses
> > to not be helpful at all.
> >
> > Maybe that is my biggest concern with the systemd stuff. The
> > defensive reaction to feedback and bug reports I perceived with
> > upstream and debian developers which I partly understand given the
> > bashing the systemd side received. I may have used an unsuitable tone
> > at times as well, and I am sorry for that, but being told "Go away"
> > just doesn´t match the responsibility for dealing with issues with
> > something that is a default for all users who don´t change it.
> > systemd as a default needs a different reaction to bug reports than
> > this.
>
> The root cause of this bug is in the initscript of dirmngr that us using
> su instead of start-stop-daemon.
>
> su is starting a PAM session which then call pam_systemd. This
> should not happen for daemons.
>
> Again here systemd is only doing what he's instructed to do; not
> allowing a user to create a DOS for other logged in users. So please
> get dirmngr fixed instead of blaming systemd/logind. I've reopened the
> initial bug opened against dirmngr about the fact that the initscript
> is calling su (#668890)
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.
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.
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.
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.
Again, I am not ranting about any technicalities here. I am ranting about
attitude. Thats it.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: