<div dir="auto"><div>Hi, <br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Feb 2023, 13:04 Diego Zuccato, <<a href="mailto:diego.zuccato@unibo.it">diego.zuccato@unibo.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
<br>
I'm no expert, but it seems ChatGPT is confusing "queued" and "running" <br>
jobs.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">That's what I also suspected. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Assuming you are interested in temporarily shutting down slurmctld <br>
node for maintenance.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Temporarily and daily. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br><br><br><br><br>
If the jobs are still queued ( == not yet running) what do you need to <br>
save? The queue order is dynamically adjusted by slurmctld based on the <br>
selected factors, there's nothing special to save.<br>
For the running jobs, OTOH, you have multiple solutions:<br>
1) drain the cluster: safest but often impractical<br>
2) checkpoint: seems fragile, expecially if jobs span multiple nodes<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I just have one node, but the bigger problem with check pointing is that GPUs don't seem to be supported. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) have a second slurmd node (a small VM is sufficient) that takes over <br>
the cluster management when the master node is down (be *sure* the state <br>
dir is shared and quite fast!)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I've just got that one "node" for compute and login and storage and everything. </div><div dir="auto"><br></div><div dir="auto">It's a Tyrone server with 64 cores and a couplea raided hdds. Just wanna run some DFT/QM/MM simulations for myself and departmental colleagues, and do some exact diagonalization problems. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) just hope you'll be able to recover the slurmctld node before a job <br>
completes *and* the timeouts expire<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I booted into gparted live and beefed up the swap space to 200 gigs (the ram is 93 G). I've setup a mandatory (through qos settings) Slurm reservation that kills all running jobs in the normal qos after 8:30 pm everyday and a cron job that starts @ 835 pm, drains the partitions, suspends all jobs running on elevated qos privileges, then hibernates the whole sumbich to swap. Another script runs whenever the fella comes outta hibernation, resets the slurm partitions and resumes the suspended jobs.</div><div dir="auto"><br></div><div dir="auto">Its an ugly jugaad, I know. </div><div dir="auto"><br></div><div dir="auto">I guess it's tough noogies for the normal qos people if their jobs ran past the reservation or were not properly checkpointed before a blackout, but I don't see any other alternative.</div><div dir="auto"><br></div><div dir="auto"> My department refuses to let me run my thingie 24/7, and power outages occur frequently round here. </div><div dir="auto"><br></div><div dir="auto">I'm concerned about implementing a failsafe in case this Rube Goldberg like setup takes a hard left. </div><div dir="auto"><br></div><div dir="auto">Was thinking about a systemd service that kills all running jobs, then simply runs "scontrol shutdown" to preserve the state of queued jobs and then resumes a regular system shutdown. In that case, automatic checkpointing of the jobs with dmtcp/mana would be cool, and I was encouraged when chatgpt claimed that slurm supported this. But the recent docs don't corroborate this claim,so I guess it got deprecated or something... </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While 4 is relatively risky (you could end up with runaway jobs that <br>
you'll have to fix afterwards), it does not directly impact users: their <br>
jobs will run and complete/fail regardless of slurmctld state. At most <br>
the users won't receive a completion mail and they will be billed less <br>
than expected.<br>
<br>
Diego<br>
<br>
Il 10/02/2023 20:06, Analabha Roy ha scritto:<br>
> Hi,<br>
> <br>
> I'm having some complex issues coordinating OpenMPI, SLURM, and DMTCP in <br>
> my cluster. On a whim, I logged into ChatGPT and asked the AI about it.<br>
> It told me things that I couldn't find in the current version of the <br>
> SLURM docs (I looked). Since ChatGPT is not always reliable, I reproduce <br>
> the<br>
> contents of my chat session in my GitHub repository for peer review and <br>
> commentary by you fine folks.<br>
> <br>
> <a href="https://github.com/hariseldon99/buparamshavak/blob/main/chatgpt.md" rel="noreferrer noreferrer" target="_blank">https://github.com/hariseldon99/buparamshavak/blob/main/chatgpt.md</a><br>
> <<a href="https://github.com/hariseldon99/buparamshavak/blob/main/chatgpt.md" rel="noreferrer noreferrer" target="_blank">https://github.com/hariseldon99/buparamshavak/blob/main/chatgpt.md</a>><br>
> <br>
> I apologize for the poor formatting. I did this in a hurry, and my <br>
> knowledge of markdown is rudimentary.<br>
> <br>
> Please do comment on the veracity and reliability of the AI's response.<br>
> <br>
> AR<br>
> <br>
> -- <br>
> Analabha Roy<br>
> Assistant Professor<br>
> Department of Physics <br>
> <<a href="http://www.buruniv.ac.in/academics/department/physics" rel="noreferrer noreferrer" target="_blank">http://www.buruniv.ac.in/academics/department/physics</a>><br>
> The University of Burdwan <<a href="http://www.buruniv.ac.in/" rel="noreferrer noreferrer" target="_blank">http://www.buruniv.ac.in/</a>><br>
> Golapbag Campus, Barddhaman 713104<br>
> West Bengal, India<br>
> Emails: <a href="mailto:daneel@utexas.edu" target="_blank" rel="noreferrer">daneel@utexas.edu</a> <mailto:<a href="mailto:daneel@utexas.edu" target="_blank" rel="noreferrer">daneel@utexas.edu</a>>, <br>
> <a href="mailto:aroy@phys.buruniv.ac.in" target="_blank" rel="noreferrer">aroy@phys.buruniv.ac.in</a> <mailto:<a href="mailto:aroy@phys.buruniv.ac.in" target="_blank" rel="noreferrer">aroy@phys.buruniv.ac.in</a>>, <br>
> <a href="mailto:hariseldon99@gmail.com" target="_blank" rel="noreferrer">hariseldon99@gmail.com</a> <mailto:<a href="mailto:hariseldon99@gmail.com" target="_blank" rel="noreferrer">hariseldon99@gmail.com</a>><br>
> Webpage: <a href="http://www.ph.utexas.edu/~daneel/" rel="noreferrer noreferrer" target="_blank">http://www.ph.utexas.edu/~daneel/</a> <br>
> <<a href="http://www.ph.utexas.edu/~daneel/" rel="noreferrer noreferrer" target="_blank">http://www.ph.utexas.edu/~daneel/</a>><br>
<br>
-- <br>
Diego Zuccato<br>
DIFA - Dip. di Fisica e Astronomia<br>
Servizi Informatici<br>
Alma Mater Studiorum - Università di Bologna<br>
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy<br>
tel.: +39 051 20 95786<br>
<br>
</blockquote></div></div></div>