3 ms·

If you're just looking for detection of child (owned) process death, I don't think you should need pidfds? Have you tried monitoring their stdio pipes (or a UNI

If you're just looking for detection of child (owned) process death, I don't think you should need pidfds? Have you tried monitoring their stdio pipes (or a UNIX socket or similar that you dupe into it) for closure? To my understanding pidfds were meant to take care of the more general case of awaiting the termination of an arbitrary process that you don't control.

gpm 6y ago
It's a shell, I don't necessarily have any pipes from the child. Moreover a child playing games with it's file descriptors shouldn't fool me into thinking it's dead and either cause me to block waiting for it to actually die or move on and never reap it.
- dataflow 6y ago
  Well you could create a pipe from the shell if you're spawning it (just create a pipe() when you fork() it), assuming it's inheriting your stdio so you can't already just wait on those. This is what I've done in the past. That said, if your child process has genuine potential to acting adversarially, I don't believe even pidfds would be enough; you'll need to make sure it doesn't spawn e.g. a child process to break away. However, I would guess that's not your actual use case? Rather, I'd assume you're trying to prevent against accidents. If you're in this boat like I'm assuming, I'd suggest thinking over whether the scenario you proposed is actually plausible. The only real-world instances I've seen a process playing "games" with file descriptors it did not previously open itself are (a) closing FDs after a fork, and (b) user code in a shell, doing something like exec 2>&3 or whatever. I assume you're worried about the latter given the former isn't relevant. In that case, you could work around it via dup2() after you fork(), by duping into a random high FD that nobody would be likely to mess with (like a random high number plus its own PID). This should solve it for practical purposes. Not that you shouldn't use pidfds necessarily, but I'm just throwing these out there because I've been in this situation before and these might help you solve your problem on other systems that don't support that.
  - gpm 6y ago
    Yes, I suppose random high numbered fd as a pipe would be fine from a practical perspective.

gpm 6y ago

It's a shell, I don't necessarily have any pipes from the child. Moreover a child playing games with it's file descriptors shouldn't fool me into thinking it's dead and either cause me to block waiting for it to actually die or move on and never reap it.

dataflow 6y ago
Well you could create a pipe from the shell if you're spawning it (just create a pipe() when you fork() it), assuming it's inheriting your stdio so you can't already just wait on those. This is what I've done in the past. That said, if your child process has genuine potential to acting adversarially, I don't believe even pidfds would be enough; you'll need to make sure it doesn't spawn e.g. a child process to break away. However, I would guess that's not your actual use case? Rather, I'd assume you're trying to prevent against accidents. If you're in this boat like I'm assuming, I'd suggest thinking over whether the scenario you proposed is actually plausible. The only real-world instances I've seen a process playing "games" with file descriptors it did not previously open itself are (a) closing FDs after a fork, and (b) user code in a shell, doing something like exec 2>&3 or whatever. I assume you're worried about the latter given the former isn't relevant. In that case, you could work around it via dup2() after you fork(), by duping into a random high FD that nobody would be likely to mess with (like a random high number plus its own PID). This should solve it for practical purposes. Not that you shouldn't use pidfds necessarily, but I'm just throwing these out there because I've been in this situation before and these might help you solve your problem on other systems that don't support that.
- gpm 6y ago
  Yes, I suppose random high numbered fd as a pipe would be fine from a practical perspective.