You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently learned that there are some (weirdly configured) clusters on which users do not have access to sacct and each sacct call will fail. I am not sure how common this is (and I do not understand the necessity that leads cluster admins to this sort of configs), but we should be able to also write a version of the asyncmd.slurm.SlurmProcess that uses scontrol to check for the running jobs.
This version will probably less performant and it will unfortunately not be able to parse all exit codes that slurm logs as scontrol only works for running jobs and only the database accessible through sacct keeps track of all expired jobs (successful and failed). It should therefore only be enabled via a configuration function (asyncmd.config.enable_slurm_scontrol_job_parsing or similar) and live parallel to the sacct implementation.
The text was updated successfully, but these errors were encountered:
I recently learned that there are some (weirdly configured) clusters on which users do not have access to
sacct
and eachsacct
call will fail. I am not sure how common this is (and I do not understand the necessity that leads cluster admins to this sort of configs), but we should be able to also write a version of theasyncmd.slurm.SlurmProcess
that usesscontrol
to check for the running jobs.This version will probably less performant and it will unfortunately not be able to parse all exit codes that slurm logs as
scontrol
only works for running jobs and only the database accessible throughsacct
keeps track of all expired jobs (successful and failed). It should therefore only be enabled via a configuration function (asyncmd.config.enable_slurm_scontrol_job_parsing
or similar) and live parallel to thesacct
implementation.The text was updated successfully, but these errors were encountered: