Description
The PHP backend tries to make sure that the intelmqctl
calls do not
take too long by implementing some kind of timeout. It tries two
mechanisms, which both fail to work AFAICT.
One is using PHP's set_time_limit
function. Unfortunately, time spent
executing subprocesses is not included in that timeout. The Note section
in https://www.php.net/manual/en/function.set-time-limit.php says:
Any time spent on activity that happens outside the execution of the
script such as system calls using system(), [...] is not included when
determining the maximum time that the script has been running.
The other method is some shell code that tries to kill the subprocess
after 20s using kill
. This doesn't work in the usual setup where the
web-server code uses sudo
to run intelmqctl
as the intelmq
user
because the kill
fails due to insufficient permissions (kill: Operation not permitted
).
It would probably work when intelmqctl
is run without sudo
.
All this does make me wonder why the fix for #164 works, because AFAICT
it shouldn't work, and in my tests (making intelmqctl artificially slow
with a sleep) set_time_limit
indeed doesn't cause a timeout. The kill
in the shell code doesn't stop the process and doesn't make PHP send the
response faster, but its error message makes the PHP code produce a 500
response.
I noticed this while working on ther Python-API (#80). The obvious way
to implement a subprocess timeout in Python is the timeout
parameter
of the subprocess module. This doesn't work for exactly the same reason
the shell approach in the PHP code doesn't work: The Python code is not
permitted to send signals to a subprocess that uses sudo.
Before I put more time into coming up with ways to implement timeouts
anyway, it's probably best to decide how important this timeout feature
actually is. Given that it doesn't work in the PHP implementation, and
doesn't seem to be a problem in practice, it seems to be acceptable for
now at least not to drop it.