Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Reindl Harald


Am 03.07.19 um 11:53 schrieb Ulrich Windl:
> I agree that the major problem with systemd was that distributions switched 3
> or 5 years too early to it.

guess where you would be now without them solving most fo the problems
over the past years for people coming like you late to the party

guess where you could be if your distribution would use a recent vesion
instead pacth it like theere would be no tomorrow
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Reindl Harald


Am 03.07.19 um 08:37 schrieb Ulrich Windl:
> The really annoying thing with systemd is that if SOMETHING fails during boot,
> the complete boot is aborted and you are put into an emergency shell.

this is not true

there are very rare cases where you end in the emergency shell

> with the fact that the user sees nothing while systemd waits for something
> (like 3 minutes) the user does not know (because he does not see anything on
> the console) gives the impression that the system "hangs". This is true at
> least for SLES 12.

this is also not true for many years

as like for many of our problems blame SUSE

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Lennart Poettering
On Mi, 03.07.19 08:37, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> I agree here. While we do have `support-url` which distros can
> >> override, Apparently not all of them do.
> >> We could probably change our build system, that `support-url` needs to
> >> be set explicitly and if unset, no Support URL is printed in the
> >> journal output.
> >
> > This, or since the URL leads to [0], it would be also useful to extend
> > the "About systemd-devel" section to provide some kind of warning that
> > this ML is mainly/only for upstream systemd, not for systemd shipped by
> > distributions.
> >
> > [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
> The really annoying thing with systemd is that if SOMETHING fails during boot,
> the complete boot is aborted and you are put into an emergency
> shell.

This is not really the case. Only stuff that has a Requires=
dependency from basic.targe/sysinit.target/local-fs.target will cause
the boot to fail. Most services except the most essential are not
marked with Requires=, but use Wants=.

systemd gives you precise control what is required and what just shall
be started through this. If your distro or your admin use that
incorrectly, pleas work with them to fix that.

> Combined
> with the fact that the user sees nothing while systemd waits for something
> (like 3 minutes) the user does not know (because he does not see
> anything on

That's not true. You see the "eye of ceylon" animation on the console
with info what is being waited for. Maybe you use a bootsplash that
turns that off? Talk to you distro. And the eye of ceylong animation
has been in place since a long long time.

> the console) gives the impression that the system "hangs". This is true at
> least for SLES 12.

Hm, isn't SLES 12 like 5 years old by now? Maybe upgrade to something
less archaic?

> To make systemd better, you really have to listen to the users' problems and
> actually MAKE IT BETTER.

Maybe it is already a lot better, but we can't change your five year
old distro as upstream project?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Ulrich Windl
>>> František Šumšal  schrieb am 03.07.2019 um 11:01 in
Nachricht :

[...]
> Honestly, I'm kind of impressed you stamp the "bad bad systemd" phrase all 
> over
> the place several times in your emails, yet you still expect people to be 
> able
> to (willingly) help you.

I may have an opinion, just as you are allowed to have one. That's the good
thing.

> 
>> To make systemd better, you really have to listen to the users' problems
and
>> actually MAKE IT BETTER.
> 
> I know this might surprise you, but that's how systemd got where it is now.

> We
> just need to filter out problems which have been already fixed, so we can 
> focus
> on solving the outstanding ones (instead of going through hundreds of bug 
> reports).

I agree that the major problem with systemd was that distributions switched 3
or 5 years too early to it.

Regards,
Ulrich

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread František Šumšal
On 7/3/19 8:37 AM, Ulrich Windl wrote:
 František Šumšal  schrieb am 02.07.2019 um 18:51 in
> Nachricht :
> 
>>
>> On 7/2/19 4:36 PM, Michael Biebl wrote:
>>> Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
>>> :
 Reading the output above, I can see, why the people contact this mailing
 list.
>>>
>>> I agree here. While we do have `support-url` which distros can
>>> override, Apparently not all of them do.
>>> We could probably change our build system, that `support-url` needs to
>>> be set explicitly and if unset, no Support URL is printed in the
>>> journal output.
>>
>> This, or since the URL leads to [0], it would be also useful to extend
>> the "About systemd-devel" section to provide some kind of warning that
>> this ML is mainly/only for upstream systemd, not for systemd shipped by
>> distributions.
>>
>> [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel 
> 
> The really annoying thing with systemd is that if SOMETHING fails during boot,
> the complete boot is aborted and you are put into an emergency shell.

I, too, like my systems to be booted up only a half way with half of the 
services
being in an unknown/inconsistent state.

> Combined
> with the fact that the user sees nothing while systemd waits for something
> (like 3 minutes) the user does not know (because he does not see anything on
> the console) gives the impression that the system "hangs". This is true at
> least for SLES 12.

Well, you see the service it's waiting for. Then there are several things
which should help you when things go south:

1) If the service fails and it's crucial to the boot process, you'll end up
   in the (apparently pretty despised by you) emergency shell, where you can
   go through all necessary logs to see what went wrong
2) By adding a simple "debug" to the kernel command line, or making use of
   systemd.log_level and systemd.log_target kernel cmdline options you can
   dump the entire boot process logic to the console. You can't do this by
   default, as it unnecessarily over-saturates the console line, which leads
   to a significant slow down of the entire boot process. Also, as everything
   is logged (as would any sane person expect), it would, again - unnecessarily,
   bloat the system journal

You can't simply blame systemd that it refuses to boot when there's a service,
marked as the system administrator as crucial, yet which is apparently broken
in some way.

> While the individual cause of such failures may not be systemd, the overall
> effect of user frustration is very much due to systemd, giving it its bad
> reputation.
> So don't worry if people come to complain about many things here.

The main issue is not about people complaining (that's actually something we
want/need to), but in the version many of these users use. The systemd has
come a long way for the past few years, and there's been thousands of changes
to make things smooth and painless. But, of course, not all distributions
use the bleeding-edge version of systemd, which then introduces certain 
problems:

1) An user complains about something which has been already fixed, yet not
   backported to their distro
2) Some distributions (like RHEL) base their systemd package on a certain 
version
   (like 219 in RHEL 7) and then backport only some patches from the upstream. 
Thus,
   upstream developers shouldn't/can't be expected to know what mixture of 
patches the
   user uses.

In both cases, the downstream bug tracker is way to go. The downstream 
maintainers
know their systemd package much better and can tell you, if it's an 
downstream-only
issue, and a backport is necessary, or if it's indeed an upstream issue and they
can guide you here (or they'd do that on your behalf).

> Removing or changing the support URL might help to reduce the traffic here,
> but it definitely wouldn't help against the bad reputation of systemd.

Honestly, I'm kind of impressed you stamp the "bad bad systemd" phrase all over
the place several times in your emails, yet you still expect people to be able
to (willingly) help you.

> To make systemd better, you really have to listen to the users' problems and
> actually MAKE IT BETTER.

I know this might surprise you, but that's how systemd got where it is now. We
just need to filter out problems which have been already fixed, so we can focus
on solving the outstanding ones (instead of going through hundreds of bug 
reports).

>>
>>> Just an idea...
>>>
>>>
>>> Michael
>>>
>>
>> -- 
>> PGP Key ID: 0xFB738CE27B634E4B
> 
> 
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Ulrich Windl
>>> František Šumšal  schrieb am 02.07.2019 um 18:51 in
Nachricht :

> 
> On 7/2/19 4:36 PM, Michael Biebl wrote:
>> Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
>> :
>>> Reading the output above, I can see, why the people contact this mailing
>>> list.
>> 
>> I agree here. While we do have `support-url` which distros can
>> override, Apparently not all of them do.
>> We could probably change our build system, that `support-url` needs to
>> be set explicitly and if unset, no Support URL is printed in the
>> journal output.
> 
> This, or since the URL leads to [0], it would be also useful to extend
> the "About systemd-devel" section to provide some kind of warning that
> this ML is mainly/only for upstream systemd, not for systemd shipped by
> distributions.
> 
> [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel 

The really annoying thing with systemd is that if SOMETHING fails during boot,
the complete boot is aborted and you are put into an emergency shell. Combined
with the fact that the user sees nothing while systemd waits for something
(like 3 minutes) the user does not know (because he does not see anything on
the console) gives the impression that the system "hangs". This is true at
least for SLES 12.

While the individual cause of such failures may not be systemd, the overall
effect of user frustration is very much due to systemd, giving it its bad
reputation.
So don't worry if people come to complain about many things here.

Removing or changing the support URL might help to reduce the traffic here,
but it definitely wouldn't help against the bad reputation of systemd.

To make systemd better, you really have to listen to the users' problems and
actually MAKE IT BETTER.

> 
>> Just an idea...
>> 
>> 
>> Michael
>> 
> 
> -- 
> PGP Key ID: 0xFB738CE27B634E4B



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel