>>> Lennart Poettering schrieb am 03.07.2019 um 13:30
in
Nachricht <20190703113048.GC12226@gardel-login>:
> 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=.
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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
