Feature #8602
wrong exit status after a signal
Description
Hello,
After catching a signal art exits with status code 0. This is wrong, because the processing of the input dataset was not completed.
%MSG
Art caught and handled signal 2.
..........
Art has completed and will exit with status 0.
Andrei
Related issues
History
#1 Updated by Christopher Green over 5 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 over 5 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.
#3 Updated by Kyle Knoepfel over 5 years ago
- Related to Bug #8823: art exit codes added
#4 Updated by Kyle Knoepfel over 5 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.
#5 Updated by Kyle Knoepfel over 5 years ago
- Target version changed from 1.18.00 to 1.16.00
#6 Updated by Christopher Green over 5 years ago
- Status changed from Resolved to Closed
#7 Updated by Kyle Knoepfel about 5 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