* Christian Brauner:
/* zombies */
Zombies can be signaled just as any other process. No special error will be
reported since a zombie state is an unreliable state (cf. [3]).
I still disagree with this analysis. If I know that the target process
is still alive, and it is not, this is a persistent error condition
which can be reliably reported. Given that someone might send SIGKILL
to the process behind my back, detecting this error condition could be
useful.
Rest looks good to me (with the usual caveats).
Thanks,
Florian
On Thu, 2018-12-06 at 13:30 +0100, Florian Weimer wrote:
* Christian Brauner:
quoted
/* zombies */
Zombies can be signaled just as any other process. No special error will be
reported since a zombie state is an unreliable state (cf. [3]).
I still disagree with this analysis. If I know that the target process
is still alive, and it is not, this is a persistent error condition
which can be reliably reported. Given that someone might send SIGKILL
to the process behind my back, detecting this error condition could be
useful.
As I understand it, kill() behaves the same way. I think it's good that
this new syscall keeps the behavior as close as possible to kill().
E.g., this would allow emulating kill() (or a higher level API
equivalent) on top of taskfds without subtle differences in behavior.
As the new syscall supports flags, we could consider introducing a flag
that changes the behavior in the zombie case. However, I think that
should be a separate discussion (after merge of the syscall) and the
default behavior makes sense as is.
Jürg
On Thu, Dec 06, 2018 at 01:30:19PM +0100, Florian Weimer wrote:
* Christian Brauner:
quoted
/* zombies */
Zombies can be signaled just as any other process. No special error will be
reported since a zombie state is an unreliable state (cf. [3]).
I still disagree with this analysis. If I know that the target process
is still alive, and it is not, this is a persistent error condition
which can be reliably reported. Given that someone might send SIGKILL
to the process behind my back, detecting this error condition could be
useful.
Apart from my objection that this is not actually a reliable state
because of timing issues between e.g. calling wait and a process exiting
I have two more concerns and one helpful suggestion.
First, this is hooking pretty deep into kernel internals. So far
EXIT_ZOMBIE is only exposed in kernel/exit.c and I don't see enough
value to drag all of this into kernel/signal.c
Second, all other signal syscalls don't do report errors when signaling
to zombies as well. It would be odd if this one suddenly did.
Third, if this really becomes such a big issue for userspace in the
future that we want to do that work then we can add a flag like
TASKFD_DETECT_ZOMBIE (or some such name) that will allow userspace to
get an error back when signaling a zombie.
As far as I'm concerned, this is out of scope for an initial
implementation. We are going to use fds for tasks that's enough
excitement for one patchset!
Rest looks good to me (with the usual caveats).
I take it that's your way of saying Acked-by? :)
Christian