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.
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.
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.
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.
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.
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).
Insensitive to survivors. I don't find it disgustingly insensitive, rather potentially troublesome.
Also, yes, master / slave is outdated. If you are developing a new product, do not use master / slave terminology. It is not appropriate for professional work product.
Daemon is troublesome in many households for young hackers, which I don't advocate changing; this just makes me a little sad.
Killing, I have no problem with, but I'm an American. If I were, say Austrian, I might prefer terminating processes.
---
The whole point of PC (political correctness) is to take power away from racists, sexists and other -ists by demonizing words and concepts. I think this has obviously gone too far in many areas. For instance, people should be able to discuss slavery, racism, violence, etc in a grown-up environment without fear of undue reprisal. If someone is still an actual racist shithead then they deserve the consequences of their free speech.
Speech and names should be respectful, especially in the professional arena. Being witty is fun, but causing real pain is not. Some people are killjoys who pounce on every troublesome or ambiguous potential "trigger" word. Some people are assholes who don't believe words can cause real pain - or worse - enjoy negging, controlling, and demeaning.
Personally, I tell horrible jokes and say mean things about people pretty often, but only verbally, and only to small audiences who take them in the manner intended. I'm sure I say hurtful things in amongst the jokes sometimes, but I also try to show respect in most of my dealings as well.
True, but do you think that is the point OP was making? "Members of a particular country should have a preference for a word that is associated with an individual from that country" seems like a rather strange linguistic argument to make :-)
Your first comment reads like if it was serious though, sorry. I suggest use '/s' for this situations, even though it's a bit lame to have to denote sarcasm. Also, the head of the thread is flagged out, so people who took yours seriously probably thought that you made that comment.
You take away what your bring to the party, I guess. I read it as "we all succeed or fail together", and it wasn't until I read hackernews outrage it occurred to me someone would deliver another interpretation.
I'm sorry, but I disagree with this current trend of making language "safe" for everyone. Yes, I know about triggers and some good reasons for changing words (there's no real reason to be using master/slave in a new piece of software).
Eventually you end up with bland, uninteresting language. Pact, while a little confronting if you follow the connotations far enough, is an excellent and succinct name.
That's actually a pretty good question. I would guess that killing is so generic from the News, games, movies, etc that killing doesn't usually strike a personal chord - whereas family and friends of suicide victims[1] tend to take suicide personally.
1. Typing that out reinforces how weird it is to think about suicide terminology - a subject one would be advised to not spend too much time pondering.
Someone want fill me in on the piece of popular culture I apparently missed? All I've got is either "an agreement" or compilers for ancient IBM mainframes (704s, I think it was?).
spitballing here - some of these may be more offensive than pact, included to get mental juices flowing. Also, not looking these up for dupes in current use.
mad - mutually assured destruction
mat - mut. ass. termination
jenga
atdi - atomic disintegrator
dms - dead mans switch
psd - process safety device
vigil - alert watching
turret - are you still there
ff - fail fast
faro - the pharoah gets buried with his servants
tact - terminal action
pact - positive action (same name, different story)
I see why you were downvoted for the initial comment, but I don't see why you are being downvoted for this one. This seems like a creative list of alternatives to back your complaint. Personally I don't think the name should change at all. Although, I do like ff for the alternative name you could give it in your head that describes the exclamations of the processes involved. Upvoted for creativity and constructivity.
Basically you write simple shell script to start your processes and at the and you exec prace so it takes over children of shell:
You could also do this as a part of shell script in this way: 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.