Hey Cafe, 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! -- Michael Xavier http://www.michaelxavier.net