[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: file permissions on joblog

From: Rob Sargent
Subject: Re: file permissions on joblog
Date: Thu, 28 Jul 2022 12:07:31 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 7/28/22 11:46, Christian Meesters wrote:

This is no SLURM job file, as it contains no '#SBATCH' directives. (Yes, they could be given on the command line).

You're correct. Sort of.  Recall from the original post that I submit a request to an intermediary which looks like this:
#c redwood
#t 96
/inst/sys/installdir/sgspub/bin/83a9a2ad.hcMt 4 Bb5V32
That intermediary converts that into a slurm request which when launched executes the "83a9a2ad.hcMt" script which is what I showed earlier.  At the slurm host this is run under an account over which I have no control and whose umask is apparently 0027 .

It is also a bit peculiar, as you must think it is necessary to adjust permissions. This is usually done in so-called prolog scripts, which run prior to the job start. If your cluster deviates, you should discuss this with your admins, as it makes your work cumbersome and error prone. Also, it is not necessary to infer the number of CPUs on a node as the number of CPUs available in your particular job should be available as environment variables (see the wiki-link I have given). Please contact your administrators about these things.

As for the job log: SLURM gathers stdout/stderr as specified by the sbatch -o and -e directives. They should be directed to shared file systems. Anything which is local to job, might not be accessible after the job finished. Whether or not /sratch is a global filesystem or a local one, cannot be understood from the context.

All in all, you should contact your local helpdesk, there are a number of things, which might be due to the application or the cluster settings, not parallel.

My "permission adjustments" run under the foreign account open the permissions on "my" files for me to view, delete as necessary.

All is working according to plan from the perspective of the intermediary and the slurm host.  I was only hoping there was some parallel nuance I could exploit to get access to the joblog file during the slurm run.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]