.BR PTRACE_ATTACH ,
.B PTRACE_SEIZE
does not stop the process.
+Group-stops are reported as
+.B PTRACE_EVENT_STOP
+with
+.I WSTOPSIG(status)
+== stopping_signal.
+Automatically attached children stop with
+.B PTRACE_EVENT_STOP
+with
+.I WSTOPSIG(status)
+==
+.B SIGTRAP
+instead of having
+.B SIGSTOP
+signal delivered to them.
+.BR evecve (2)
+does not deliver an extra
+.BR SIGTRAP.
Only a
.BR PTRACE_SEIZE d
process can accept
and
.B PTRACE_LISTEN
commands.
+The "seized" behavior just described is inherited by
+children that are automatically attached using
+.BR PTRACE_O_TRACEFORK ,
+.BR PTRACE_O_TRACEVFORK ,
+and
+.BR PTRACE_O_TRACECLONE .
.I addr
must be zero.
.I data
.B PTRACE_INTERRUPT
command, or group-stop, or initial ptrace-stop when a new child is attached
(only if attached using
-.BR PTRACE_SEIZE ),
-or
-.B PTRACE_EVENT_STOP
-if
-.B PTRACE_SEIZE
-was used.
+.BR PTRACE_SEIZE ).
.TP
.B PTRACE_EVENT_SECCOMP
Stop triggered by a
.B PTRACE_O_TRACEEXEC
option is
.I not
-in effect for the execing tracee, the kernel delivers an extra
+in effect for the execing tracee,
+and if tracee was
+.BR PTRACE_ATTACH ed
+rather that
+.BR PTRACE_SEIZE d,
+the kernel delivers an extra
.B SIGTRAP
to the tracee after
.BR execve (2)
to suppress is not easy.
Setting the
.B PTRACE_O_TRACEEXEC
-option and thus suppressing this extra
+option or using
+.B PTRACE_SEIZE
+and thus suppressing this extra
.B SIGTRAP
is the recommended approach.
.SS Real parent