Implements system signal handling for archiving interruption / termination

[sgiehl]

Description

Provides handling of SIGINT and SIGTERM for both core:archive and scheduled-tasks:run.

SIGINT

When receiving SIGINT, the current step in the process (currently running archives, current scheduled task) should be completed and then the command should gracefully stop.

SIGTERM

When receiving SIGTERM, the archiving tries to stop immediately, based on the current step and system capabilities.

Due to the way the default CliMulti is implemented, archiving requests made with curl or shell_exec will still be awaited to completion. Archiving tasks run with Symfony/Process will be killed immediately and the invalidation of those are reset to be picked up in the next archiving run.

As scheduled tasks are stopped after the current task is finished, to avoid any timing problems with emails not being sent or being sent too often, or aborted downloads leaving the system in an unplanned state.

Tests

The behaviour of both signals should have full test coverage, documenting and asserting the way invalidations are handled.

As those tests require interaction with background shell processes, they currently use Symfony/Process, though a switch to proc_open is possible.

Every step in the tests is safeguarded by timeouts, to not leave zombie processes running if a test fails. For local debugging, depending on where a breakpoint is set (should work through the all shell execution levels), the timeouts can be changed in the implemented waitForSuccess helper methods to allow for an indefinite wait. This may require a local process cleanup after the test finishes, as some background tasks (e.g. CliMulti::executeAsyncCli) are not stopped with the associated test or core:archive process.

Refs DEV-18318

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed

[caddoo]

Nice clean implementation, with good test coverage 👍

[caddoo]

I don't understand exactly when this might happen, can you elaborate?

Just worried that for some reason we skip this test without realizing and things break.

[sgiehl]

If you run the tests on a system where the methods might be disabled for example. We have similar checks for other things as well. It might though be useful to start tracking skipped tests on our CI, so we are aware of changes...

[caddoo]

Would it be helpful to log the signal that is received, SIGINT or SIGTERM

[sgiehl]

Might not hurt, but it also doesn't make a difference between the signals here.
Also this is currently only triggered through core archiving, and that one prints the signal once it receives one: https://github.com/matomo-org/matomo/pull/22487/files#diff-f41c275e883996b8b69cb765b1818e12e82cbe034e648bc3f7d03610cc7abad1R317

[michalkleiner]

Nicely done indeed! The UI test failures are unrelated.

[github-actions]

This issue is in "needs review" but there has been no activity for 7 days. ping @matomo-org/core-reviewers

[github-actions]

This PR was last updated more than one month ago, maybe it's time to close it. Please check if there is anything we still can do or close this PR. ping @matomo-org/core-reviewers