Skip to content

Test SIGTERM vs ~TFile #13300

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
1 task
Axel-Naumann opened this issue Jul 21, 2023 · 5 comments · May be fixed by #18403
Open
1 task

Test SIGTERM vs ~TFile #13300

Axel-Naumann opened this issue Jul 21, 2023 · 5 comments · May be fixed by #18403
Assignees
@dpiparo
Labels
bug good first issue in:I/O

Comments

@Axel-Naumann
Copy link
Member

Check duplicate issues.

  • Checked for duplicates

Description

Rumors have it that SIGTERM doesn't trigger writing in-memory objects to open TFiles. We should have a test for this.

Reproducer

Likely this should be enough:

TFile file("out.root", "RECREATE");
TH1F hist("h", "h", 10, 0., 1.);
raise(SIGTERM);

ROOT version

6.29/01

Installation method

From source

Operating system

Some Linux

Additional context

No response
@Axel-Naumann Axel-Naumann self-assigned this Jul 21, 2023
@Axel-Naumann
Copy link
Member Author

It might be that this bug requires the object to be in a sub-TDirectory:

TFile file("out.root", "RECREATE");
file.mkdir("subdir")->cd();
TH1F hist("h", "h", 10, 0., 1.);
raise(SIGTERM);

@dpiparo dpiparo assigned dpiparo and unassigned Axel-Naumann Feb 5, 2024
@ferdymercury
Copy link
Collaborator

ferdymercury commented Apr 14, 2025 •
edited
Loading

If we add this in TerminalConfigUnix.cpp, then both examples are fixed.

#include "TROOT.h"
#include "TMethodCall.h"

if (signum==SIGTERM) { // SIGTERM is a gentle way of exiting, so it should auto-save open files
// TO-DO this could be moved to gROOT->CleanupOnSigterm();
if (gROOT) {
     R__LOCKGUARD(gROOTMutex);

     if (gROOT->GetListOfFiles()) {
        TIter next(gROOT->GetListOfFiles());
        TObject* obj = nullptr;
        while((obj = (TObject*)next())) {
           if (obj) {
              TMethodCall call1(obj->IsA(), "Write", "");
              TMethodCall call2(obj->IsA(), "Close", "");
              call1.Execute((void *)(obj));
              call2.Execute((void *)(obj));
           }
        }
     }
  gROOT->GetListOfFiles()->Delete("slow");
  }
      if (gROOT->GetListOfSockets())
         gROOT->GetListOfSockets()->Delete();
      if (gROOT->GetListOfMappedFiles())
         gROOT->GetListOfMappedFiles()->Delete("slow");
      if (gROOT->GetListOfClosedObjects())
         gROOT->GetListOfClosedObjects()->Delete("slow");
}
  signal(signum, SIG_DFL); // unregister ourselves

ferdymercury added a commit to ferdymercury/root that referenced this issue Apr 14, 2025
@ferdymercury
[textinput] handle Unix SIGTERM to save and close files before exit
8356178 
Fixes root-project#13300
ferdymercury added a commit to ferdymercury/root that referenced this issue Apr 14, 2025
@ferdymercury
[test] Implement Sigterm-equivalent test for Unix
6aab401 
Fixes root-project#13300
@ferdymercury ferdymercury linked a pull request Apr 14, 2025 that will close this issue
Open
2 tasks
@pcanal
Copy link
Member

pcanal commented Apr 14, 2025

It might be that this bug requires the object to be in a sub-TDirectory:

Is there really a difference between the 2 cases?

Rumors have it that SIGTERM doesn't trigger writing in-memory objects to open TFiles.

It is debatable whether this is the desired behavior or not. We do not know whether the user sent a SIGTERM to 'prevent' the process for doing any more 'damage' to the file or whether they expected TFile to behave as a google doc with an auto-save features.

The best/most we should do is make sure the file is 'properly' closed via the execution of TROOT::CloseFiles.

@ferdymercury
Copy link
Collaborator

It is debatable whether this is the desired behavior or not. We do not know whether the user sent a SIGTERM to 'prevent' the process for doing any more 'damage'

Wouldn't the user send then a SIGKILL instead ?

@pcanal
Copy link
Member

pcanal commented Apr 14, 2025

Wouldn't the user send then a SIGKILL instead ?

That is a good question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dpiparo dpiparo

Labels
bug good first issue in:I/O
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[io] Prevent losing data due to SIGTERM (under Unix) ferdymercury/root
4 participants
@Axel-Naumann @pcanal @dpiparo @ferdymercury