[slurm-users] [External] How can I do to prevent a specific job from being prempted?

顏文 peteryen2017 at gmail.com
Tue Sep 14 07:59:02 UTC 2021


Dear Mr. Zillner

I would like the specific running job not being rescheduled , but also can
not be terminated or cancelled in any way. If the job is cancelled, I need
to start it over again. Normally this kind of jobs require weeks to finish.
So the time costs it take to restart is quite significant. Can your
suggestions also achieve that? Thanks.

with regards,
Peter

Florian Zillner <fzillner at lenovo.com> 於 2021年9月14日 週二 下午3:40寫道:

> See the no-requeue option for SBATCH:
>
> --no-requeue
> Specifies that the batch job should never be requeued under any
> circumstances. Setting this option will prevent system administrators from
> being able to restart the job (for example, after a scheduled downtime),
> recover from a node failure, or be requeued upon preemption by a higher
> priority job. When a job is requeued, the batch script is initiated from
> its beginning. Also see the --requeue option. The JobRequeue configuration
> parameter controls the default behavior on the cluster.
>
> https://slurm.schedmd.com/sbatch.html
>
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* slurm-users <slurm-users-bounces at lists.schedmd.com> on behalf of
> 顏文 <peteryen2017 at gmail.com>
> *Sent:* Tuesday, September 14, 2021 7:02:13 AM
> *To:* slurm-users at lists.schedmd.com <slurm-users at lists.schedmd.com>
> *Subject:* [External] [slurm-users] How can I do to prevent a specific
> job from being prempted?
>
> Dear slurm users,
>
> I have some specific jobs that can't be terminated, otherwise they need to
> be rerun from the beginning. Can we simply apply some settings (either by
> user or administrator) so that these jobs will not be preempted ? Thanks.
>
> with regards,
> Peter
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20210914/8b4b4704/attachment.htm>


More information about the slurm-users mailing list