RFR: 8367801: jtreg failure_handler - don't use the -L option for ps command

[Jaikiran Pai]

On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change to a jtreg failure handler command?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this PR removes the use of "-L" option from the "ps" command to reduce the noise in the output of "ps". I have verified that the command continues to function properly when run as a failure handler action and it no longer contains the thread entries in the output.
> 
> The use of "-L" was introduced when this support to run failure handlers was first introduced in https://bugs.openjdk.org/browse/JDK-8132961. So there's wasn't explicit prior reason for including the "-L" option.

Hello Aleksey,

> How bad is the output with -L, really?

I checked one recent run which collected this ps output when a test timed out. On that run, the "ps" output had 1638 lines (each representing a process/thread). Out of those 1638 lines, there were only 461 unique processes. The rest of them were entries corresponding to the threads in these processes.

> I would have thought having more debugging info is better for post-mortem diagnostics

It's true that having additional information typically helps analyze the failures better. In this ps output however, the entries belonging to the threads haven't provided us anything unique or informative that may have helped understand the failures/time outs. We do collect a lot more thread specific details through jstack, native thread dumps and various other tools and we have relied on those for anything thread specific.

Of course, this isn't a new thing and has been this way always. The reason why this is coming up now is because we have started seeing a lot more intermittent timeout failures in our CI after the recent timeout factor changes and when investigating those failures, the "ps" output tends to be extremely long with these repeated pids (each one for a different thread).

Having said that, I'll let this PR settle for a couple of days to see if the preference is to let that command stay in its current form.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27328#issuecomment-3302398625