At Senic, we have shifted to
systemd for managing many independent
application we have running on the Hub. Earlier we were using
supervisord and for bunch of reasons(limit dependency, system
supported solution etc).
systemd provides many strong features,
uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic
We have put together different service files that starts applications
as Hub boots. Some of these services have hard dependencies on others,
meaning if parent service is not running, child service won't
start/run. For example if we have an application which is making
network request, in some scenarios it will help if that service is
NetworkManager service which manages Network
interfaces(or other native service which handles network connections).
This dependency tree has both benefits and issues. For us, some of the
services(parent service), initializes DBus Objects. And child services
connects or subscribe to these Objects, that enables DBus
communication between separate applications. Now if Parent service
SIGTERM), child service can't continue and needs to stop. Here
systemd dependency tree takes care of this for us, it stops all
dependent services if parent stops.
But in situation where parent service restarts, I would say, my
systemd fails me.
systemd correctly stops all the
child services but it doesn't restart them once parent service starts
again. I am not sure which dependency construct to use that (
After etc) make sure that once parent service restarts, all child
process also restart.
All the services have a Restart clause to make sure that service
restarts. But restart only happens in some certain scenarios. If a
service is stopped using command
systemd won't start the service again. And I
think this is how child service gets stopped when parent service
restarts and hence they don't restart. Maybe.