systemd, complex?

[Stuart McGraw]

On 06/15/2011 03:53 AM, Rahul Sundaram wrote:
> On 06/15/2011 02:34 PM, Ed Greshko wrote:
>> 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.
> 
> https://fedoraproject.org/wiki/Systemd
> 
>> 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 is not a systemd developer

'bochecha' was not the person who wrote the blog
response that Ed Greshko quoted, he was the person 
to whom the text was addressed.  The quoted response
was written by Lennart if that changes your assessment
of its credibility.  See the first comment in:

  http://0pointer.de/blog/projects/systemd-for-admins-1.html

Also, why does the source's developer status matter? 
Is there something wrong about the information (which
I repeat below)?  If so, what?  I also am interested 
in answers to the questions Ed Greshko asked.

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