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

[Ulrich Windl]

>>> Lennart Poettering <lennart at poettering.net> schrieb am 03.07.2019 um 13:30
in
Nachricht <20190703113048.GC12226 at gardel-login>:
> On Mi, 03.07.19 08:37, Ulrich Windl (Ulrich.Windl at 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=.

For me ANY filesystem in /etc/fstab that failed to mount caused a significant
delay with no message indicating what's going on and finally a emergency
shell.
More strangly there was some addity I still cannot explain with multiopathd, a
local HPSA (CCISS) RAID controller and pvscan claiming to be unable to find a
local disk.

In the past I even had the more interesting situation that a successful manual
mount of /boot was immediately unmounted by systemd. As it truned out, when
stopping multipathd /boot was mounted with some delay by systemd, and when
starting multipathd again, /boot was umounted by systemd again. If you
(=systemd) have /boot unmounted while doing a kernel update, you'll have great
"fun" at next boot (system won't bnoot, or will boot the old kernel).

> 
> 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.

In my view of things it's not that systemd GIVES me precise control, but
systemd TAKES AWAY control from me.

> 
>> 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.

Sometimes I see messages, sometimes I do not. Most of the time when things do
NOT work, I also see no massages (which is very bad). It may be my
distribution, but assuming the people who configured it are quite smart, it
seems systemd's smartness even beats theirs.

> 
>> 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?

SLES12 has support for another 3 years (plus maybe optional extended support
even).
If you want a system that reliably works, you are not after the latest
software, BTW.

> 
>> 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?

OK, put more simple:
Normaly "systemctl start something" does not print anything when it succeeded.
How could I see what's going on during boot (star tcommands' output is being
redirected to syslog by systemd)?

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin