bryancall commented on PR #13681:
URL: https://github.com/apache/trafficserver/pull/13681#issuecomment-5683953814
Two points from the automated reviews that came through as suppressed
comments,
so there was no thread to answer in place.
**EXIT trap not escalating** -- fixed in 9e106d6a11. `cleanup` now reuses
`end_connection` for every non-empty child pid, so the bounded TERM -> poll
`kill -0` -> KILL -> `wait` applies on an early exit from a `wait_for`
timeout or
a failed assertion, not only on the deliberate teardowns. Each pid is
cleared as
it is reaped, so neither the trap nor a later step can signal a pid the
kernel
has since recycled. Verified with a TERM-immune child:
```
pid 7224 ignored TERM after 3s; escalating to KILL
```
**`exec 4>&2` supposedly capturing /dev/null** -- this one is not a defect,
and
no change was made. `exec 4>&2` is outside the `{ ... } 2>/dev/null` group,
not
inside it, so fd 4 duplicates the real stderr and the group's redirection
only
applies to fd 2 within the group. Reduced:
```bash
probe() {
exec 4>&2
{ echo "MSG-VIA-FD4" >&4
echo "MSG-VIA-FD2" >&2
} 2>/dev/null
exec 4>&-
}
probe
```
With stderr sent to a file, the file contains `MSG-VIA-FD4` and not
`MSG-VIA-FD2`: fd 4 reaches real stderr, fd 2 is discarded, which is the
whole
point of saving it. The escalation diagnostic above was produced the same
way,
with the script's own `end_connection` and `2>` redirected to a file, so the
diagnostic the comment promises does arrive.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
