On 6/13/24 15:03, Dan Cross wrote:
> I may be in a bit of a grumpy mood, so forgive me if this is snarkier 
> than I intend, but statements like this bother me.

;-)

> Second, there are many reasons beyond just "lol it crashed" that 
> you may want to restart dependent services; for example, perhaps you 
> are upgrading a system and part of the upgrade process is restarting 
> your dependents. Having a system that does things like that for you 
> is useful.

It's my understanding that systemd as a service lifecycle manager is 
starting to take on some aspects of what cluster service managers used 
to do.  E.g.

  - Are all the other dependencies this service needs up and running -> 
is it okay to start this service on this system?

  - Is the service running and responding like it should be?  -> 
periodically check to make sure the system is returning expected 
results; is DNS answering queries / can I send a test email

  - Stop the service when it's operating outside acceptable parameters 
(read: failing).

  - Notify other related services that this service has been stopped.

I'm anti-systemd *cough*Master Control Program*cough* and it's 
associated suite of utilities for many reasons.  But I've come to accept 
that systemd is not just an init system.  It's role of a service life 
cycle manager is a superset of what an init system does.  It's a 
relatively new world (at least comparatively).

I also have seriouis doubts about systemd's stability as a services life 
cycle manager.  I've seen too many times when systems get into a wedged 
state that require a power fail / reset (or sys request if enabled) to 
recover.

I've seen too many times when a systemd based system won't shut down 
because of some circular configuration it's gotten itself into.  Without 
the complication of NFS servers being unreachable after taking down the 
network.



--
Grant. . . .