|
|
|
| Authored by: jesse on Saturday, July 28 2012 @ 02:29 PM EDT |
The problem with systemd is that it cannot succeed - It requires multiple
network analysis passes to start (and it gets it wrong because it doesn't do
enough).
It also cannot contain all the information in the SysVinit scripts. There are
implied dependencies that are overlooked (why mounts fail sometimes), random
scheduling of activities (also why networks fail sometimes), and the difficulty
of debugging a PERT network in general.
The startup used to be a simple list - with some parallel operation explicitly
identified (startup numbers identical).
Any systems administrator had the ability to create a startup script. This is no
longer possible with systemd.
Another problem is that systemd violates the "do one thing and do it
well". This is because systemd takes on the init process, inetd/xinetd, and
is reported to be taking over udev functions too.
All of this makes systemd a huge bloated pile of you-know-what, that can't be
debugged.
One problem that still exists is that systemd looses error messages. Yes, it has
gotten better... but it still looses them. This problem is caused by having
multiple sources of error messages. Instead of a single tty (that serializes
writes) it now uses multiple sockets (at least one for each service).
Unfortunately, with all the asynchronous handling done by systemd, the system
console gets some of the messages, systemd gets some of them, and others get
lost in the switching. Then there is the problem of the data sync for the logs -
that is still supposed to be rsyslog. Some of the missing logs could be caused
by packet overflows causing messages to be dropped (cant fix that one). This is
due to overloading the system with startup processes that each need to provide
some log/error entry - but the thundering herd scheduling done doesn't allow the
messages to be serialized properly.
But due to the obvious errors, they are trying to replace the simple rsyslog
process with a new logger that will just have more problems - you won't be able
to read the log file without a custom application. And that application may not
be available to the recovery process (sometimes a special boot system).
Fedora used to be easily audited - not anymore.
Fedora problems used to be investigated, and fixed by the average administrator
- again, not anymore.[ Reply to This | Parent | # ]
|
|
|
|
|
