-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implements system signal handling for archiving interruption / termination #22487
base: 5.x-dev
Are you sure you want to change the base?
Conversation
9a75dc0
to
78826a9
Compare
8d19658
to
138b7e8
Compare
a53f679
to
66d7fba
Compare
e467182
to
9e49bbc
Compare
66d7fba
to
ff22f4f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice clean implementation, with good test coverage 👍
public function setUp(): void | ||
{ | ||
if (!extension_loaded('pcntl') || !function_exists('pcntl_signal')) { | ||
$this->markTestSkipped('signal test cannot run without ext-pcntl'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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...
@@ -121,6 +131,11 @@ public function run() | |||
|
|||
// loop through each task | |||
foreach ($tasks as $task) { | |||
if (in_array($this->signal, [\SIGINT, \SIGTERM], true)) { | |||
$this->logger->info("Scheduler: Aborting due to received signal"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be helpful to log the signal that is received, SIGINT or SIGTERM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done indeed! The UI test failures are unrelated.
This issue is in "needs review" but there has been no activity for 7 days. ping @matomo-org/core-reviewers |
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 |
Description
Provides handling of
SIGINT
andSIGTERM
for bothcore:archive
andscheduled-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 withcurl
orshell_exec
will still be awaited to completion. Archiving tasks run withSymfony/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 toproc_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 orcore:archive
process.Refs DEV-18318
Review