Project

General

Profile

Bug #6827

request for fixes to jobsub_tools v1_3_1_1

Added by Andrei Gaponenko about 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
08/19/2014
Due date:
% Done:

100%

Estimated time:
First Occurred:
Occurs In:
Stakeholders:
Duration:

Description

Hello,

As we know already, v1_3_1_1 broke existing mu2e grid scripts.
I see two issues:

1) The new version started relying on files in a user-controlled $TMPDIR.
Mu2e scripts have always "cleaned up after themselves". Everything inside
$TMPDIR is wiped away once the payload script terminates, leading to
the complaints about JOBSUB_LOG_FILE not found.

This can be worked around in Mu2e scripts, but it would be cleaner
for jobsub to keep its internal files apart from the user-generated ones.

2) v1_3_1_1 stopped providing the environment with ifdhc set up.
This is why mu2e users do not get their files back.
Is there a valid reason to NOT provide an ifdhc setup to the user script
via the jobsub wrapper?

I suggest to release a new version of jobsub_tools that fixes the issues:
- re-instate the ifdh setup in the wrapper
- do not put any jobsub internal files into the user's TMPDIR

Andrei

History

#1 Updated by Dennis Box about 5 years ago

Hi Andrei,

Is there a valid reason to NOT provide an ifdhc setup to the user script
via the jobsub wrapper?

Some experiments are/were hard wired to specific releases of ifdh. Setting up ifdh in the jobsub wrapper messed up their environments, they requested that any jobsub wrapper ifdh setup and calls be spawned to a separate shell ($TMP/ifdh.sh) to fix this. In hindsight this does break any user script that expects ifdh to already be set up.

I can think of ways to fix the 'expect ifdh to be/not be set up' problem on a per-experiment basis (in the jobsub.ini file for instance), but it seems messy.

Moving my script to a different directory than where the user script executes is a good idea, I can do that right away.

Dennis

#2 Updated by Dennis Box about 5 years ago

For some reason Andrei's email reply didn't make it into the ticket, here it is:

Date: Tue, 19 Aug 2014 16:18:43
From: Andrei Gaponenko <>
To:
Cc: ,
Subject: Re: [JobSub - Bug #6827] request for fixes to jobsub_tools v1_3_1_1

On Tue, 19 Aug 2014, wrote:

Issue #6827 has been updated by Dennis Box.

Hi Andrei,

Is there a valid reason to NOT provide an ifdhc setup to the user script
via the jobsub wrapper?

Some experiments are/were hard wired to specific releases of ifdh. Setting up ifdh in the jobsub wrapper messed up their environments, they requested that any jobsub wrapper ifdh setup and calls be spawned to a separate shell ($TMP/ifdh.sh) to fix this. In hindsight this does break any user script that expects ifdh to already be set up.

I can think of ways to fix the 'expect ifdh to be/not be set up' problem on a per-experiment basis (in the jobsub.ini file for instance), but it seems messy.

Would a command line option be easier? That would work as well.

In the generated ifdh.sh instead of the

ifdh "$@"

line at the end you can do

if [ "$1" != "--jobsub-internal-setup" ]; then
ifdh "$@"
fi

Then you can use ifdh.sh from the wrapper as before. In addition if
the user wants ifdh set up you can

source ${TMP}/ifdh.sh --jobsub-internal-setup

from the wraapper before running the payload.

Moving my script to a different directory than where the user script executes is a good idea, I can do that right away.

Excellent!

Andrei

Dennis

----------------------------------------
Bug #6827: request for fixes to jobsub_tools v1_3_1_1
https://cdcvs.fnal.gov/redmine/issues/6827#change-16901

Author: Andrei Gaponenko
Status: New
Priority: Normal
Assignee:
Category:
Target version:
First Occurred:
Occurs In:
Stakeholders:

Hello,

As we know already, v1_3_1_1 broke existing mu2e grid scripts.
I see two issues:

1) The new version started relying on files in a user-controlled $TMPDIR.
Mu2e scripts have always "cleaned up after themselves". Everything inside
$TMPDIR is wiped away once the payload script terminates, leading to
the complaints about JOBSUB_LOG_FILE not found.

This can be worked around in Mu2e scripts, but it would be cleaner
for jobsub to keep its internal files apart from the user-generated ones.

2) v1_3_1_1 stopped providing the environment with ifdhc set up.
This is why mu2e users do not get their files back.
Is there a valid reason to NOT provide an ifdhc setup to the user script
via the jobsub wrapper?

I suggest to release a new version of jobsub_tools that fixes the issues:
- re-instate the ifdh setup in the wrapper
- do not put any jobsub internal files into the user's TMPDIR

Andrei

--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://cdcvs.fnal.gov/redmine/my/account

#3 Updated by Dennis Box about 5 years ago

Hi Andrei,

I have installed jobsub_tools v1_3_1_1_1, which is v1_3_1_1 patched with your requests on mu2egpvm01 in /fnal/ups/db .

To use:
ssh mu2egpvm01
source /fnal/ups/etc/ups.sh
setup jobsub_tools
jobsub (stuff)

Can this location be made to work with the mu2e scripts for testing? If it works I can propagate it to /grid/fermiapp/products but I would rather it be tested here first.

Cheers
Dennis

#4 Updated by Parag Mhashilkar about 5 years ago

  • Assignee set to Dennis Box
  • Target version set to v1.0.2

Dennis, is this still an issue? If not feel free to close it.

#5 Updated by Dennis Box about 5 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

patched in jobsub_tools v1_3_1_1_2 (current on gpsn01)
resolved in jobsub_tools v1_3_2_0

#6 Updated by Parag Mhashilkar almost 5 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF