[Haskell-cafe] Quick Angel User's Survey
michael at michaelxavier.net
Sat Sep 14 21:20:57 CEST 2013
I am the maintainer of Angel, the process monitoring daemon. Angel's job is
to start a configured set of processes and restart them when they go away.
I was responding to a ticket and realized that the correct functionality is
not obvious in one case, so I figured I'd ask the stakeholders: people who
use Angel. From what I know, most people who use Angel are Haskellers so
this seemed like the place.
When Angel is terminated, it tries to cleanly shut down any processes it is
monitoring. It also shuts down processes that it spawned when they are
removed from the config and the config is reloaded via the HUP signal. It
uses terminateProcess from System.Process which sends a SIGTERM to the
program on *nix systems.
The trouble is that SIGTERM can be intercepted and a process can still fail
to shut down. Currently Angel issues the SIGTERM and hopes for the best. It
also cleans pidfiles if there were any, which may send a misleading
message. There are a couple of routes I could take:
1. Leave it how it is. Leave it to the user to make sure stubborn processes
go away. I don't like this solution so much as it makes Angel harder to
reason about from a user's perspective.
2. Send a TERM signal then wait for a certain number of seconds, then send
an uninterruptable signal like SIGKILL.
There are some caveats with #2. I think I'd prefer the timeout to be
configurable per-process. I think I'd also prefer that if no timeout is
specified, we assume the user does not want us to use a SIGKILL. SIGKILL
can be very dangerous for some processes like databases. I want explicit
user permission to do something like this. If Angel generated a pidfile for
the process, if it should only be cleaned if Angel can confirm the process
is dead. Otherwise they should be left so the user can handle it.
So the real question: is the extra burden of an optional configuration flag
per process worth this feature? Are my assumptions about path #2 reasonable.
Thanks for your feedback!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe