systemd, complex?

[Ed Greshko]

I must admit that I've not spent much time to digest what advantages
there are to moving to systemd.  However, it does seem to be quite a
complex system with, as of yet, hard to locate documentation.  I've also
not had to debug any start up failures...but wanted to learn more about
systemctl.

While it is only a blog entry between developers of systemd I did run
into this gem which, at first blush, makes me apprehensive. 

 

bochecha: well, there are many reasons why a service might show up as
failed to load in the systemctl output: for example, it was referenced
as required dependency of another service, but we couldn't find neither
a native service definition file nor a SysV init script for it. Or,
there was a parsing failure while reading it. Or, because the file was
incomplete. And that might even happen while a service is active, for
example, because the user requested a configuration file reload from
systemd after changing a service file, and a service that is already 
running suddenly has an invalid configuration file. That effectively
means that the LOAD and the ACTIVE state are mostly orthogonal: you may
have a running service where configuration loaded fine, you may have a
stopped service where it loaded fine, but you may also have a running
service where configuration failed to load.

And yes, ACTIVE and SUB show you the same information, though ACTIVE in
a more generalized form. While SUB has states that are specific to each
unit type (e.g. "running", "exited", "dead" for services; "plugged" and
"dead" for devices; or "mounted" and "dead" for mount points), ACTIVE
exposes the same high-level states for all units.

We only distinguish 6 ACTIVE states (to list them: active, reloading,
inactive, maintenance, activating, deactivating), which are mapped from
the lower-level states, which might be many more. For example services
have 15 low-level states: dead, start-pre, start, start-post, running,
exited, reload, stop, stop-sigterm, stop-sigkill, stop-post,
final-sigterm, final-sigkill, maintenance, auto-restart.



FWIW, it seems there are more than 15 low-level states since I also see
"plugged" in the output of systemctl.  The concept of the MS Windows
registry confuses the heck out of me.  In some respects I wonder if this
will also lead to confusion.  Will all of this be hidden behind some GUI
that performs correctly 98% of the time?

Yes, I suppose I need to give it more time...and dedicate some effort to
really understanding it....