14 Jun
2024
14 Jun
'24
8:17 p.m.
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. . . .