TRestRun member replacement using temporary file causes problems

REST version : v2.2.12_dev
REST commit : 8eb5a028

Hi,

Description of the problem

it seems to me that when I launch now a file to process it creates a temporary file and then it moves or replaces to the final filename once the processing finishes.

In practice, while processing the file something like that appears in the destination directory

R[fRunNumber][fParentRunNumber][fRunType]_[fRunTag]_usertrex_V[fVersion].root

Once the file has finished processing that file is replaced by

R01141_00040_RawData_BackgroundRadon_usertrex_V2.2.12.root

Conflicts

The problem appears when I launch several restManager in parallel in the same machine, same destination path.

In fact that at the last commit 96244982 @ v2.2.12_dev the situation changes, the problem is that the filename generated is not replaced at all, and I end up with the following file once the processing has completely finished.

R[fRunNumber]_[fParentRunNumber]_[fRunType]_[fRunTag]_usertrex_V[fVersion].root

The problem disappears reverting 4bbc9d43. It must be connected to that commit.

There are actually three problems revealed in this post.

  1. The segmentation fault is caused by TRestRawSignalAnalysisProcess itself. The pipeline already shows the problem. Can you receive the e-mail of pipeline failing from SJTU gitlab? You can also check manually if the your commit passes the auto test.
  1. I have found the bug that the file name remains to be R[fRunNumber]_[fParentRunNumber]_[fRunType]_[fRunTag]_usertrex_V[fVersion].root. It is fixed in commit 8ac0d27f

  2. Indeed it is a problem (potential conflict) that all the fille names will remain un-replaced before the job finishes. I have updated the logic in 2063a768

I guess that problem is independent of this topic? I introduced the problem at TRestRawSignalAnalysisProcess in commit 98938a43, I fixed that in commit 96244982. Do you mean that the pipeline at SJTU detected the segmentation fault? Thats nice!

Now, there is a Red Cross in the commit just before the last one. But the problem seemed connected to g4Analysis.rml? And solved in the next commit?

Not sure if connected to this topic, but I have also seen the new lines in TRestProcessRunner. The null output is specified using restManager ... --o null or restManager ... --o /dev/null? Or both are valid?

Ok for 2. and 3. I believe that solves the problems I had.

Yes. I have fixed that now. Now the problems should gone.

Both are valie. But you seems to have reverted that commit. So now it is not OK

Yes, I did that temporary, and locally, because it was causing me some problems during data processing. It was not my intention to push that to the remote. But I understand now it is fine as it is.

I don’t get the notifications from SJTU Gitlab. I am watching any activity in my profile settings, but still I don’t see any e-mail.

Seems that only the “trigger” of the pipline will recieve the email, which is me only(because my account pushes the commits from lfna to sjtu, i.e., repository mirroring). I have just added your e-mail javier.galan.lacarra@cern.ch to an additional pipline mailing list. Hopefully you can recieve the emails later on(only the pipline failing emails).

1 Like

Yes, I am receiving them now.