ci(tests): start every resource-monitor sample on its own line (#1888)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change. Narrow runs only, listed below.

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Root cause. The resource-monitor sampler in .github/workflows/experimental.yml wrote each sample with printf '\n%s\n' "$(sample …)". bash line-buffers builtin output, so that printf goes out as several writes. The tests step then interleaves those writes with pytest's progress through tail -F, so a later write of one sample could land after pytest's unfinished line. That is the uuu.u[monitor] … ps row seen in #1881's job 117297298108.

The worker counted the writes with a SOCK_SEQPACKET socket: a 3-line sample was 3 writes under bash 4.2 and 5.3.

Fix. The step builds the sample first, then writes it with cat <<< $'\n'"$lines", which emits it as one write that opens on a newline. The log format is unchanged, so the stop step's count still reads it.

Test. The new test_each_sample_is_one_write_so_no_output_lands_inside_it runs the real start step against a SOCK_SEQPACKET socket and puts pytest-style output between every two writes, so it does not depend on timing. It fails with the old step and passes now. The test file passed 45 of 45 looped runs.

Unverified: CI's coreutils 9 tail relaying a single write in one piece; the host here has coreutils 8.22.

Closes #1888

[JarryShaw]

Verdict: GOOD TO GO at 75209fefb. A Sonnet cross-review could not break the fix or the test.

• The mechanism is real. The base step wrote a realistic 1.6 KB sample in 10 separate writes, and the same happens on a plain file. The PR's step writes it once: 1653 bytes, opening and ending on a newline. In an end-to-end tail -F run with a racing writer, base produced 362 lines with a [monitor] mid-line and the PR produced 0.
• No sample comes near PIPE_BUF. ps is capped at head -6 | cut -c1-300, so the largest plausible sample is about 2.7 KB against the 4096-byte PIPE_BUF. The test's PIPE_BUF assertion guards that headroom.
• The test is real. The new test failed 3 of 3 times against the old step; the whole file passed 10 of 10 runs on the PR head.
• Nothing else changed. The log format is identical, the stop step still counts samples, and the containment summary still parses. experimental.yml's permissions are unchanged.

Unverified: GitHub-hosted runners' bash and coreutils builds. The reviewer tested bash 5.3 here.

[github-actions]

Coverage: 90.06% (unit tier, Python 3.15, 75209fefb, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	2	20	2	96.77%
pcapkit/const	19595	881	2618	867	92.11%
pcapkit/corekit	2462	69	780	35	96.55%
pcapkit/dumpkit	276	3	100	3	98.40%
pcapkit/foundation	2914	164	1016	34	93.59%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17406	224	4580	189	98.10%
pcapkit/toolkit	872	177	298	8	77.18%
pcapkit/utilities	512	2	158	4	99.10%
pcapkit/vendor	4429	2341	1018	156	43.62%

Per-file detail: the coverage-html artifact of this run.