[LAU] [OT] another systemd thread
murks at tuxfamily.org
Thu Jan 8 00:00:19 UTC 2015
On Wed, 7 Jan 2015 12:49:12 +0100
Raffaele Morelli <raffaele.morelli at gmail.com> wrote:
> QED you among the others are claiming about nothing concrete, I ran
> debian on my servers and desktops, switching to systemd did not
> caused a single issue. I've read tons of posts like your, nothing
> concrete about systemd, just repeating over and over again the same
> four silly things about phantom sys admin being stucked by ... what?
> Furthermore, those who are stucked by filesystem check at startup are
> either noobs or completely ignorants which can't use tune2fs
As far as I know Debian switched only very recently. Ralf is using
Arch, and so do I. I did not look it up, but I think Arch switched to
systemd about two years ago, so we have a lot more experience and were
involuntary early adopters.
In many respects, in everyday operations, systemd just works, but so
did sysvinit. It is just that everything works differently now, and if
you run into problems it can be a pain to figure out what is wrong.
There is a lot less documentation on the net, and by that I mean stuff
that helps with troubleshooting common problems, not the systemd
documentation itself. In addition, systemd is a moving target, so what
might have worked half a year ago may no longer apply. On top of that,
many Arch people seem to have adopted a potterian attitude over the
last few years. You can be sure to be scorned at, you may get a
solution, but you won't get a proper explanation of the cause of the
problem or its solution.
I did have some concrete problems. The journal seems to be quite a
mess. The only reliable thing about it is that it does not work when you
need it the most. Years ago I had some issue with system freezes or
crashes and the logs contained nothing. I reported the bug and they
changed something so that the log gets written more often. Recently I
had another system freeze, and guess what I found in the logs? The full
half hour leading up to the freeze was completely empty. Nothing. Nada.
Not a single line. How are you supposed to debug something if the logs
It is not that much better with small problems. There was one thing I
did using a systemd service file, of course according to the information
from the Arch wiki, because without that I would be completely lost. I
am rather (but not completely) sure it worked properly, for months.
Recently I noticed that it did not work as expected, the program that
was started through the service file crashed reliably when it
absolutely should not. The only thing in the logs was that the service
failed because it was killed by systemd. End of information. Completely
useless. Someone in the Arch forums did help me (without explanation),
a small modification in the service file solved the issue, but I still
don't know whether the program changed, systemd's behavior changed or it
never worked correctly in the first place. All I know is that systemd
killed the program. Guess how much fun it is to figure out why the heck
it did that.
How about another grieve? Have you ever tried to figure out the
configuration of some service? Now with systemd you no longer have just
configuration files, no, you have configuration directories. Not just
one. For every single service you may have multiple files in multiple
directories with some sort of precedence system that you may be able
to figure out if you find the correct man page. Have fun figuring out
the configuration. Arch used to be simple, you could configure most
system level stuff using two files.
And of course there is the more general stuff, like stupid binary logs
and that they put everything plus the kitchensink into systemd. I just
now found out that systemd in the meanwhile contains a somewhat
cron-like thing called timers that is not quite a cron replacement but
is probably, directly or indirectly, involved to the system freeze I
described above. I know far less about my system than ever before. But
at least the gnome users are happy, I guess. I do not see any noteworthy
More information about the Linux-audio-user