Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)
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)
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)
>>> 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)
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)
>>> 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