wrong exit status after a signal
After catching a signal art exits with status code 0. This is wrong, because the processing of the input dataset was not completed.
Art caught and handled signal 2.
Art has completed and will exit with status 0.
#1 Updated by Christopher Green about 4 years ago
- Tracker changed from Bug to Feature
- Category set to Application
- Status changed from New to Feedback
- SSI Package art added
- SSI Package deleted (
We believe that the current behavior is as intended, but the behavior change you desire seems reasonable to us. We would like to discuss this in the upcoming stakeholder meeting.
#2 Updated by Kyle Knoepfel about 4 years ago
- Status changed from Feedback to Assigned
- Assignee set to Kyle Knoepfel
- Target version set to 1.18.00
- Estimated time set to 1.00 h
Per consensus of the stakeholders, the default behavior when handling a signal will be to exit with return code 128+n (130, in the case above). A configuration option will be provided so that the legacy behavior, as described above, can be retained.
#4 Updated by Kyle Knoepfel about 4 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
The default behavior has been adjusted as described above. Users interested in maintaining the legacy behavior may specify:
services.scheduler.SIGINTisNotError : true
in their configuration. A command-line option exists for convenience:
art --SIGINT-is-not-error -c config.fcl
Should a user specify
SIGINTisNotError : false in his configuration and
--SIGINT-is-not-error at the command-line, the command-line takes precedence.
Implemented with commit art:76e74bf2903754bfa4edc1084856d74f410ba1a3.
#7 Updated by Kyle Knoepfel over 3 years ago
The above FHiCL/command-line syntax has been changed for the sake of semantics. To restore the legacy behavior, you must use the following:
In your FHiCL file:
services.scheduler.errorOnSIGINT: false #legacy, not default
or at the command-line
art --errorOnSIGINT=false -c config.fcl