Bug 10460 - way to stop a run away report
Summary: way to stop a run away report
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Reports (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-13 12:07 UTC by Nicole C. Engard
Modified: 2022-12-06 01:26 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2013-06-13 12:07:21 UTC
Right now the only way to stop a runaway report is to go in to the command line. It would be great if there were a button that the librarian could hit on the reports page to "kill" a report that's taking too long to run.
Comment 1 Kyle M Hall (khall) 2013-08-21 12:57:13 UTC
This is a pretty complicated process. I think it would require something likes this:
a) Add a system preference "StopReports" ( or something similar ) and/or a new staff permission.
b) When enabled, running a report would immediately send a partial html page with a "Stop Report" button at the top, along with the PID of the process that is generating the report.
c) Clicking the "Stop Report" button would launch another script via ajax which sends the PID to a new script that does nothing but kill processes.
d) The script would attempt to kill the process generating the report and send back a confirmation to the requester. 
e) If the processes cannot be killed, the web page would pop up an alert, if the process was killed successfully, the page would redirect back to the report that had been run.
Comment 2 David Cook 2022-12-06 01:26:10 UTC
While technically it could be done, I don't think it would be a reasonable thing to do. 

--

That said, an interesting alternative could be to use BackgroundJobs and to have a maximum execution time allowed for a job where the worker kills its child process if it exceeds the maximum execution time.