[
https://issues.apache.org/jira/browse/CAMEL-26911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-26911:
-----------------------------------
Assignee: Claus Ibsen
> camel-jbang - process management: camel stop can kill an unrelated process
> through a stale status file, and lost or torn action replies
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26911
> URL: https://issues.apache.org/jira/browse/CAMEL-26911
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Found by an analysis of the Camel CLI on the night of 2026-11-12, with the
> unpacked 4.24.0-SNAPSHOT camel-launcher on macOS. *(exp)* means reproduced by
> experiment, *(read)* means traced in the code. Paths are relative to
> {{dsl/camel-jbang/}}, and line numbers are from main at that time. Dependency
> resolution of camel run is covered separately by CAMEL-26901.
> h3. 1. camel stop can kill an unrelated process (exp, high)
> {{ProcessFinder.scan()}} (camel-jbang-core {{common/ProcessFinder.java}}
> around lines 187-205) treats any live PID that has a {{<pid>-status.json}} in
> {{~/.camel}} as a Camel integration, and never checks that the process is the
> one that wrote the file.
> An integration killed with SIGKILL, by the OOM killer, or a crash leaves its
> files behind, and {{camel stop --kill}} itself leaves them (8 files). Once
> the PID is reused by another process:
> * {{camel ps}} lists a ghost integration
> * {{camel stop <name>}}, or {{camel stop}} for all, sends SIGTERM to whatever
> process owns that PID now, and SIGKILL with {{--kill}}
> macOS PIDs wrap at 99999, so this is reachable on a developer machine.
> Reproduced: a {{sleep 600}} with a fake status file was killed by {{camel
> stop ghost}}.
> Suggested fix: write the process start instant
> ({{ProcessHandle.info().startInstant()}}) into the status file, and only
> treat the PID as the integration when it matches; remove the stale files
> otherwise. {{camel stop --kill}} should also clean up the files of the
> process it killed.
> h3. 2. A slow action blocks stop and status (exp)
> One connector thread does the lock-file check, the status writes and the
> actions. During {{camel cmd send --poll --timeout=15000}}, {{camel stop}}
> took 16.9s, and {{camel ps}}, {{camel get}} and the TUI showed stale data for
> that time.
> h3. 3. camel trace clear and camel receive clear lose the next batch (read +
> parse test)
> They write an empty JSON object with no newline ({{CamelTraceAction}} around
> line 229, {{CamelReceiveAction}} around line 284). The connector then appends
> the next JSON object plus a newline, so the line holds two JSON objects and
> fails to parse: the first batch after a clear is lost.
> h3. 4. Torn reads of action replies (suspected)
> {{writeReply}} writes the reply file in place (only the status file uses a
> tmp file plus atomic move), and {{ActionClient.executeText}} returns any
> non-blank text, so AI and MCP tools can read truncated JSON. The follow loops
> drop a partial last line.
> h3. 5. camel log is 12x slower with color (exp)
> {{CamelCommand.printColored}} writes through the unbuffered
> {{AnsiConsole.out()}}, and color is on even when the output is not a TTY.
> 100k lines: 4.88s with color vs 0.42s without.
> h3. 6. camel log with 2+ integrations moves stack traces away from their
> records (exp)
> The comparator that merges the logs gives lines without a timestamp -1, so
> the lines of a stack trace are sorted away from the record they belong to.
> h3. 7. A background run writes its log twice with no size limit (exp)
> {{<pid>-run.log}} is byte-identical to {{<pid>.log}} (27 MB each after 6
> minutes). {{-run.log}} is left behind after {{--max-seconds}}, {{camel stop
> --no-wait}} or a crash.
> h3. 8. camel log --follow never closes the reader of a stopped integration
> (read)
> A file descriptor leak for a long follow session. Minor: {{camel ps}} parses
> each status file twice (0.35s flat, fine today).
> h3. Came out clean
> {{ActionClient}} waits are bounded at 10s, requests are published atomically,
> and a missing {{~/.camel}} is handled.
> h3. Suggested order
> # 1 (small fix, worst outcome)
> # 3 and 4 (lost or torn data for the AI and MCP tools)
> # 2, 5, then the rest
> _Claude Code on behalf of Claus Ibsen (davsclaus)_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
