New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make managing multiprocess services easier and safer #16

Merged
merged 4 commits into from Mar 25, 2014

Conversation

Projects
None yet
2 participants
@acg
Contributor

acg commented Mar 24, 2014

These changes make managing multiprocess services with daemontools-encore easier and safer. An example of a multiprocess service is one with a long-running shell pipeline in its ./run file.

Multiprocess services were problematic for classic daemontools, and are still somewhat problematic for daemontools-encore. Prior to this change, signalling multiprocess services under the latter could result in orphaned processes, unclean system shutdown, and problems with ^Z and ^C when running in a foreground terminal. These issues are addressed by propagating certain signals to services, and by signalling the entire process group when a service uses setsid.

This change also introduces compatibility with classic daemontools, which did not use a new process group for each service. To avoid using a new process group for a service, create a file ./no-setsid in the service directory. To explicitly signal just the process leader of a setsid service, use svc -+. To explicitly signal the entire process group of a no-setsid service, use svc -=.

This change is a refactor and rebase of #3. (You may find some more information there.)

acg added some commits Mar 24, 2014

disable setsid per-service with a ./no-setsid file.
Before this change, each service always ran in a separate process group via setsid(2). For users that need the classic daemontools behavior instead, the existence of a file ./no-setsid in a service directory will disable this.
when using setsid, signal the entire process group.
Prior to this change, only the process leader of a service would be signalled by svc(8). For multiprocess services, this meant that sending SIGINT or SIGTERM would typically orphan processes. Better behavior: always signal the entire process group when a service is using setsid.
ensure clean service shutdown and clean ^C, ^Z behavior.
When supervise(8) itself receives certain signals, they should be propagated to the service.

When supervise(8) receives SIGTERM or SIGINT, propagate this to the supervised process by behaving as if `svc -dx` had been called. SIGTERM occurs during system shutdown. SIGINT can occur when svscan(8) is running in terminal foreground and gets ^C. In both cases, not propagating the signal to a setsid service will result in orphans that continue to run.

When supervise(8) receives SIGTSTOP, for example because svscan(8) is running in terminal foreground and gets ^Z, behave as if `svc -p` had been called. Similarly, when supervise(8) receives SIGCONT, behave as if `svc -c` had been called. This ensures that setsid services stop and resume when running in foreground.
disable process group signaling with `svc -=`.
To explicitly send signals only to the process group leader of a service, even if the service uses setsid, use `svc -=`.

To explicitly send signals to the entire process group, even if the service uses ./no-setsid, use `svc -+`.

Otherwise, process group signalling is used iff the service is setsid.

bruceg added a commit that referenced this pull request Mar 25, 2014

Merge pull request #16 from acg/multiprocess-services
make managing multiprocess services easier and safer

@bruceg bruceg merged commit 1c95026 into bruceg:master Mar 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment