[Fix-18311][TaskPlugin] Fix task process kill status check

[zhuxiangyi]

Was this PR generated or assisted by AI?

YES. Codex/ChatGPT assisted with debugging, code changes, tests, issue drafting, and PR draft preparation. I reviewed the changes and verified them locally.

Purpose of the pull request

Fix task kill status checking when kill -0 returns Operation not permitted for an unkillable sudo parent process or when tenant login shell emits stderr with exit code 0.

Closes #18311.

Brief change log

• Add exit code accessor to ExitCodeException.
• Distinguish alive, not-alive, and no-permission process states in ProcessUtils.
• Continue killing permitted child processes instead of reporting success when only the sudo parent check is denied.
• Add unit coverage for ExitCodeException and the sudo-parent-denied plus killable-child process scenario.

Verify this pull request

This change added tests and can be verified as follows:

• ./mvnw -pl dolphinscheduler-common -Dspotless.check.skip=true -Djacoco.skip=true -Dtest=AbstractShellTest test
• ./mvnw -pl dolphinscheduler-task-plugin/dolphinscheduler-task-api -am -Dspotless.check.skip=true -Djacoco.skip=true -Dsurefire.failIfNoSpecifiedTests=false -Dtest=ProcessUtilsTest test
• ./mvnw -pl dolphinscheduler-common,dolphinscheduler-task-plugin/dolphinscheduler-task-api -DskipTests -Djacoco.skip=true spotless:check

Pull Request Notice

Pull Request Notice

If your pull request contains incompatible change, you should also add it to docs/docs/en/guide/upgrade/incompatible.md.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 60%)

See analysis details on SonarQube Cloud

[zhuxiangyi]

@SbloodyS Could you review this PR for me?

[SbloodyS]

This repair way is not very good. The UI does not classify the result type of kill. If we want to do this, we should first discuss how to show this type to users in the UI, and then decide how to realize it. cc @ruanwenjun

[zhuxiangyi]

This repair way is not very good. The UI does not classify the result type of kill. If we want to do this, we should first discuss how to show this type to users in the UI, and then decide how to realize it. cc @ruanwenjun

@SbloodyS Thanks for the review. I agree that exposing kill result types to users should be discussed separately. This PR does not intend to introduce a new user-visible kill state. The main problem here is that the worker currently treats any exception from kill -0 as "process not alive", which can cause a false successful kill log while child processes are still alive.

I can narrow this PR to only fix the false process-alive detection and avoid introducing a user-visible kill result classification.

[SbloodyS]

I don't think this needs to be repaired separately. Since this case will only appear when the user has no authority, it is a small probability event and can be easily avoided before deployment.