Hi From my point of view, systemd always tries to keep services running, no matter how hard they fail, and to mask possible problems when starting a service, so the service maintainers don't have to fix their service, which is really unfortunate.
In case of those service state notifications with sd_notify, I think they are usually used to signal when a service is starting, but not ready yet. This may seam reasonable at the beginning, but I think it fixes the problem at the wrong place; When a service needs another service, but it's temporary unavailable, it should cause an error or warning to be returned and logged, but it should never be a fatal error which causes the service to stop. When a service needs to handle this situation on it's own, it will become more stable over time. If this task is taken away from it, it will become fragile, and relay on the service manager. I think this would be really dangerous, because it could lead to cascades of failing services once one service fails. At some point, a service manager couldn't possibly handle that anymore and there would just be waves of restarting and failing processes. Daniel Abrecht
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng