Show HN: Pact, a simple utility that kills all procs given to it if one dies | Hacker News Reader

Show HN: Pact, a simple utility that kills all procs given to it if one dies

github.com

94 pointsnickodell75 comments

I did something similar some time ago, but in far simpler form. I called it "process race" - prace for short.

Basically you write simple shell script to start your processes and at the and you exec prace so it takes over children of shell:

  #!/bin/sh
  proc1 &
  proc2 &
  proc3 &
  exec prace

You could also do this as a part of shell script in this way:

  (proc1 & proc2 & proc3 & exec prace)

Then prace has simple job. It wait(2)s and then kills all children.

I have it somewhere if someone is interested, but I can access it in few hours. But everything is written in at most 2/3 terminal screens worth of C.

This is the service supervision approach, which is indeed the best, avoiding race conditions and nasty polling. If you really must monitor processes which you cannot parent, at least under Linux you can do this using ptrace to sort-of-reparent the processes (as long as you have CAP_SYS_PTRACE or your ptrace scope is set to 0 in Yama), with waitpid to monitor all of them.

I for one would like to have it at hand, if you could. Just paste it here if you don't mind publishing it, thanks in advance.

For the time being I can't access original implementation, but quick and dirty version looks like this: https://gist.github.com/hadrianw/8e6f9c1007953b37f768

Props for this. Just last week, I was searching for a similar solution and ended up coding this - https://github.com/code-mancers/invoker/blob/master/lib/invo...

It doesn't kill the shell, when one of the process dies but kills the processes if shell dies. There is some trick involved in the way trap gets called though when shell dies and without waiting on the processes twice - shell exits without killing child processes.

If you happen to target Windows platform (I know article does not), don't reinvent the wheel. There are NT Job Objects [1] for this. The 'target' process creates the job with `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` set and keeps the job handle open. 'dependend' processes (by default all children spawned by 'target', but you can add more) will all be killed when the 'target' process terminates, no matter how is terminated. Jobs can do more, like cap CPU/IO/Memory for the job.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

Does it make sense to optionally pass the signal you want to send as an argument?

    pact --signal SIGINT $PID1 $PID2
    pact -s SIGKILL $PID1 $PID2
    pact $PID1 $PID2 # uses SIGTERM by default

I wrote this to scratch an itch. Is this a feature that would make pact useful to you? If so, I can add it.

I debated about making it send SIGKILL shortly after sending SIGTERM, but I was having troubling thinking of an unsurprising way to implement it.

I can't think of a current itch, but think about sending SIGHUP (refresh config) instead of killing processes.

I wonder if you could create a system that gives a file-lock to the last surviving (child?) process... Call it Tontine.

Pact... heh heh... I like the name :)

Sometimes I wonder if people come up with the name first and write something to match.

I fucking love the name =)

I'm just sitting here - popcorn-in-the-microwave - waiting for those people to start a fuss about it.

I might be totally wrong, but isn't this a good way to get orphaned processes? Kill the parent arbitrarily with SIGTERM (I don't think this automatically cleans up the children/forked processes) and viola, you've got an orphaned process.

Using this would require whatever process you start to handle SIGTERM properly. Most processes spawning children do this, but it's no guarantee and one needs to be aware of this.

In my experience, processes doing IPC with parent gets notified of parental death by EOF on the socketpair/pipe it's using to communicate with the parent. This is easy to reason about and most people check return values from I/O functions. Parents spawning children and only caring about SIGCHLD are more prone to not have the correct signal handlers set up by its dev(s).

IMO, any process spawning children w/o proper signal handlers are not good citizens.

This is great, and if you can - you should probably submit it as a request to systemd and supervisor.

I can see how I would use it in supervisord within a group.

This is a neat hack, but pids are reused - there is a reason "proper" supervisors take care to be the parent of the supervised process.

(A process monitoring system will mostly trigger under odd conditions... such as fork bombs.)

You're right, but I think it's an acceptable risk.

pact wakes up every second to check that every process is still there. If the process is gone, it sets the procChanged field in the struct, and it won't kill it later.

Still, what you are doing is inherently racy. The very moment you pass the PIDs to your program, they can already be gone and reused. You can end up kill()ing a different PID. I don't think you can use this for anything serious. In what situation do you think it might be acceptable? EDIT: You are trying to implement process groups in user space.

I'd call this "atomic bomb".

If allusions to suicide pacts are fair game, so is mass killing; and atomic means "all or nothing" in CS.

Over at MongoDB, Inc. atomic means nothing at all.

MongoDB is quite decent these days. Their WiredTiger backbend is written by the Berkeley DB guys.

We can also call it hitler as it does a 'process genocide'. Or maybe we can use a proper name like 'killtogether' or 'killpg' for kill process group. The name should correlate to the function of the thing.

more like a "fuse" that cuts off power to X and Y when Z fails

Maybe this is a silly question, but what's a situation where you would want to use this?

I wonder what happens if you give it its own process ID.

I don't get it.. The name that is.

I assume it's Pact as in "death pact".

The combination of the ghoulish name and correspondingly succinct description brings to mind the style of a Magic: The Gathering card.

And such a card exists!

http://gatherer.wizards.com/Pages/Card/Details.aspx?multiver...

Because of this post and these comments I'm now wondering if M:tG is Turing complete. <heads off to google>

To save people a search, http://www.toothycat.net/~hologram/Turing/index.html

Spoiler: yes.

I wonder if there's anything in the rules to deal with the fact that a game might never complete.

Tournaments run with a time limit. After the time limit, the game ends in a set number of turns. There are also rules for "slow play" that generally keep a single turn from lasting too long—and inadvertently prevent certain weird combinations of cards from working.

Online play has what is effectively a chess clock. This doesn't work in person because the game involves "priority" passing between players after every single action, which would be difficult to do manually. Additionally, play in person relies on a whole bunch of "shortcuts" that skip steps if both players don't want to do anything, which would make timekeeping even more difficult.

But if you left out these tournament-specific rules and just played the game rules, you could have games going on arbitrarily long. Since you can create "tokens" you can have arbitrary amounts of state, so a game could even loop without ever hitting the same game state twice. (Think "puffer trains" from the John Conway's Game of Life.)

If there is a truly unstoppable loop (considering usage of the word "may" or such optional ability to continue or break a loop) then the game is considered a tie. There are tournament rules regarding players intentionally drawing out the game (it's against the rules), but I don't think there's any rule against a deck that simply runs long (or really long).

Some cards have been banned for causing tournament rounds to run too long, or for being central in decks that regularly do this (I believe Sensei's Divining Top and the "eggs" deck were the major offenders).

This is like the Erlang / OTP "One for All" strategy.

http://www.erlang.org/doc/design_principles/sup_princ.html

I was actually thinking of process linking. Any groups of processes can be linked. Processes that are linked together -- die together.

Reply on news.ycombinator.com