Project

General

Profile

Feature #8602

wrong exit status after a signal

Added by Andrei Gaponenko almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Kyle Knoepfel
Category:
Application
Target version:
1.16.00
Start date:
05/05/2015
Due date:
% Done:

100%

Estimated time:
1.00 h
Spent time:
1.00 h
Scope:
Internal
Experiment:
Mu2e
SSI Package:
art
Duration:

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

Related to art - Bug #8823: art exit codesClosed05/15/2015

History

#1 Updated by Christopher Green almost 6 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

#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 over 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

Also available in: Atom PDF