<div dir="ltr"><div>A great detective story!</div><div><br></div><div> > June15 but there is no trace of it anywhere on the disk.</div><div><br></div><div>Do you have the process ID (pid) of the watchdog.sh</div><div>You could look in /proc/(pid) /cmdline and see what that shows</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 July 2018 at 11:37, Matteo Guglielmi <span dir="ltr"><<a href="mailto:Matteo.Guglielmi@dalco.ch" target="_blank">Matteo.Guglielmi@dalco.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Unbelievable... and got it by chance.<br>
<br>
jobs were killed (again) at 21:04 and in the user's list of running<br>
processes there was a 'sleep 50000' command (13 hours + 53<br>
minutes + 20 seconds) which was fired up exactly at the same<br>
time.<br>
<br>
The watchdog.sh script (from which the sleep command is fired)<br>
was started on June15 but there is no trace of it anywhere on the<br>
disk.<br>
<br>
What's in that script I don't know but it kills all the users jobs<br>
almost twice a day... and I've waited for it to do it again this<br>
morning at 10:57... and sure enough all jobs disappeared and<br>
a new sleep 50000 command was fired.<br>
<br>
Thank you all anyway!<br>
<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764719.out<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764720.out<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764721.out<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764722.out<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764723.out<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764724.out<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764725.out<br>
-rw-rw-r-- 1 moha moha 117 Jul 1 21:04 slurm-764726.out<br>
<br>
<br>
[moha@master ~]$ ps aux | grep moha<br>
moha 1695 0.0 0.0 113128 1416 ? S Jun15 0:00 sh watchdog.sh<br>
moha 76720 0.0 0.0 150844 2696 ? S Jun28 0:00 sshd: moha@pts/10<br>
moha 76724 0.0 0.0 116692 3532 pts/10 Ss+ Jun28 0:00 -bash<br>
moha 149663 0.0 0.0 150400 2240 ? S Jun28 0:00 sshd: moha@pts/0<br>
moha 149664 0.0 0.0 116692 3536 pts/0 Ss+ Jun28 0:00 -bash<br>
moha 156670 0.0 0.0 150400 2236 ? S Jun28 0:00 sshd: moha@pts/5<br>
moha 156671 0.0 0.0 116692 3604 pts/5 Ss+ Jun28 0:00 -bash<br>
moha 164364 0.0 0.0 107904 608 ? S 21:04 0:00 sleep 50000 <<<<<<<<<<=========== !!!!<br>
moha 190871 0.0 0.0 116684 3472 pts/4 S 21:46 0:00 -bash<br>
moha 194080 0.0 0.0 151060 1820 pts/4 R+ 21:52 0:00 ps aux<br>
moha 194081 0.0 0.0 112664 972 pts/4 S+ 21:52 0:00 grep --color=auto moha<br>
<br>
<br>
______________________________<wbr>__<br>
From: slurm-users <<a href="mailto:slurm-users-bounces@lists.schedmd.com">slurm-users-bounces@lists.<wbr>schedmd.com</a>> on behalf of Thomas M. Payerle <<a href="mailto:payerle@umd.edu">payerle@umd.edu</a>><br>
Sent: Friday, June 29, 2018 7:34:09 PM<br>
<span class="">To: Slurm User Community List<br>
Subject: Re: [slurm-users] All user's jobs killed at the same time on all nodes<br>
<br>
</span><span class="">A couple comments/possible suggestions.<br>
<br>
First, it looks to me that all the jobs are run from the same directory with same input/output files. Or am I missing something?<br>
<br>
Also, what MPI library is being used?<br>
<br>
I would suggest verifying if any of the jobs in question are terminating normally. I.e., is the mysterious issue which is causing all the user's jobs to terminate triggered by the completion of one of the jobs.<br>
<br>
I recall having an issue years ago with MPICH MPI libraries when having multiple MPI jobs from the same user running on the same node. IIRC, when one job terminated (usually successfully), it would call mpdallexit, which would happily kill all the mpds for that user on that node, making the other MPI jobs that user had on that node quite unhappy. The solution was to set the environmental variable MPD_CON_EXT to unique values for each of the jobs. See e.g. <a href="https://lists.mcs.anl.gov/pipermail/mpich-discuss/2008-May/003605.html" rel="noreferrer" target="_blank">https://lists.mcs.anl.gov/<wbr>pipermail/mpich-discuss/2008-<wbr>May/003605.html</a><br>
<br>
My users primarily use OpenMPI, and so do not have much recent experience with this issue. IIRC, this issue only impacted other MPI jobs running by the same user on the same node, so a bit different than the symptoms as you describe them (impacting all MPI jobs running by the same user on ANY node), but as some similarity in the symptoms I thought I would mention it anyway.<br>
<br>
<br>
</span><span class="">On Fri, Jun 29, 2018 at 7:24 AM, John Hearns <<a href="mailto:hearnsj@googlemail.com">hearnsj@googlemail.com</a><<wbr>mailto:<a href="mailto:hearnsj@googlemail.com">hearnsj@googlemail.com</a>><wbr>> wrote:<br>
I have got this all wrong. Paddy Doyle has got it right.<br>
<br>
However are you SURE than mpirun is not creating tasks on the other machines?<br>
I would look at the compute nodes while the job is running and do<br>
ps -eaf --forest<br>
<br>
Also using mpirun to run a single core gives me the heebie-jeebies...<br>
<br>
<a href="https://en.wikipedia.org/wiki/Heebie-jeebies_(idiom)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Heebie-jeebies_(idiom)</a><br>
<br>
<br>
<br>
<br>
</span><div><div class="h5">On 29 June 2018 at 13:16, Matteo Guglielmi <<a href="mailto:Matteo.Guglielmi@dalco.ch">Matteo.Guglielmi@dalco.ch</a><<wbr>mailto:<a href="mailto:Matteo.Guglielmi@dalco.ch">Matteo.Guglielmi@dalco.<wbr>ch</a>>> wrote:<br>
You are right but I'm actually supporting the system administrator of that cluster, I'll mention this to him.<br>
<br>
Beside that,<br>
<br>
the user runs this for loop to submit the jobs:<br>
<br>
<br>
# submit.sh #<br>
<br>
typeset -i i=1<br>
typeset -i j=12500 #number of frames goes to each core = number of frames (1000000)/40 (cores) =<br>
typeset -i k=1<br>
<br>
while [ $i -le 36 ] #the number of frames<br>
do<br>
<br>
sbatch run-5o$i.sh $i $j $k<br>
<br>
i=$i+1 # number of frames goes to each node (5*200 = 1000)<br>
done<br>
<br>
where each run-5oXX.sh jobfile looks like this:<br>
<br>
<br>
#!/bin/bash<br>
<br>
#SBATCH --job-name=charmm-test<br>
#SBATCH --nodes=1<br>
#SBATCH --ntasks=1<br>
#SBATCH --cpus-per-task=1<br>
<br>
export PATH=/usr/lib64/openmpi/bin/:$<wbr>PATH<br>
export LD_LIBRARY_PATH=/usr/lib64/<wbr>openmpi/lib:$LD_LIBRARY_PATH<br>
<br>
mpirun -np 1 /opt/cluster/programs/charmm/<wbr>c42b2/exec/gnu_M/charmm < newphcnl99a0.inp > newphcnl99a0.out<br>
<br>
<br>
<br>
<br>
so they are all independent mpiruns... if one of them is killed, why would all others go down as well?<br>
<br>
<br>
That would make sense if a single mpirun is running 36 tasks... but the user is not doing this.<br>
<br>
______________________________<wbr>__<br>
</div></div>From: slurm-users <<a href="mailto:slurm-users-bounces@lists.schedmd.com">slurm-users-bounces@lists.<wbr>schedmd.com</a><mailto:<a href="mailto:slurm-users-bounces@lists.schedmd.com">slurm-<wbr>users-bounces@lists.schedmd.<wbr>com</a>>> on behalf of John Hearns <<a href="mailto:hearnsj@googlemail.com">hearnsj@googlemail.com</a><<wbr>mailto:<a href="mailto:hearnsj@googlemail.com">hearnsj@googlemail.com</a>><wbr>><br>
<span class="">Sent: Friday, June 29, 2018 12:52:41 PM<br>
To: Slurm User Community List<br>
Subject: Re: [slurm-users] All user's jobs killed at the same time on all nodes<br>
<br>
Matteo, a stupid question but if these are single CPU jobs why is mpirun being used?<br>
<br>
Is your user using these 36 jobs to construct a parallel job to run charmm?<br>
If the mpirun is killed, yes all the other processes which are started by it on the other compute nodes will be killed.<br>
<br>
I suspect your user is trying to do womething "smart". You should give that person an example of how to reserve 36 cores and submit a charmm job.<br>
<br>
<br>
</span><div><div class="h5">On 29 June 2018 at 12:13, Matteo Guglielmi <<a href="mailto:Matteo.Guglielmi@dalco.ch">Matteo.Guglielmi@dalco.ch</a><<wbr>mailto:<a href="mailto:Matteo.Guglielmi@dalco.ch">Matteo.Guglielmi@dalco.<wbr>ch</a>><mailto:<a href="mailto:Matteo.Guglielmi@dalco.ch">Matteo.Guglielmi@<wbr>dalco.ch</a><mailto:<a href="mailto:Matteo.Guglielmi@dalco.ch">Matteo.<wbr>Guglielmi@dalco.ch</a>>>> wrote:<br>
Dear comunity,<br>
<br>
I have a user who usually submits 36 (identical) jobs at a time using a simple for loop,<br>
thus jobs are sbatched all the same time.<br>
<br>
Each job requests a single core and all jobs are independent from one another (read<br>
different input files and write to different output files).<br>
<br>
Jobs are then usually started during the next couple of hours, somewhat at random<br>
times.<br>
<br>
What happens then is that after a certain amount of time (maybe from 2 to 12 hours)<br>
ALL jobs belonging to this particular user are killed by slurm on all nodes at exactly the<br>
same time.<br>
<br>
One example:<br>
<br>
### master: /var/log/slurmctld.log ###<br>
<br>
[2018-06-28T18:43:06.871] _slurm_rpc_submit_batch_job: JobId=718560 InitPrio=4294185624 usec=255<br>
...<br>
[2018-06-28T19:29:04.671] backfill: Started JobID=718560 in partition on node38<br>
...<br>
[2018-06-28T23:37:53.471] _slurm_rpc_kill_job: REQUEST_KILL_JOB job 718560 uid 1007<br>
[2018-06-28T23:37:53.472] _job_signal: 9 of running JobID=718560 State=0x8004 NodeCnt=1 successful 0x8004<br>
<br>
### node38: /var/log/slurmd.log ###<br>
<br>
[2018-06-28T19:29:05.410] _run_prolog: prolog with lock for job 718560 ran for 0 seconds<br>
[2018-06-28T19:29:05.410] Launching batch job 718560 for UID 1007<br>
[2018-06-28T19:29:05.427] [718560.batch] Munge cryptographic signature plugin loaded<br>
[2018-06-28T19:29:05.431] [718560.batch] debug level = 2<br>
[2018-06-28T19:29:05.431] [718560.batch] starting 1 tasks<br>
[2018-06-28T19:29:05.431] [718560.batch] task 0 (69791) started 2018-06-28T19:29:05<br>
[2018-06-28T19:29:05.440] [718560.batch] Can't propagate RLIMIT_NOFILE of 65536 from submit host: Operation not permitted<br>
...<br>
[2018-06-28T23:37:53.480] [718560.batch] Sending signal 18 to pid 69794 (charmm)<br>
[2018-06-28T23:37:53.480] [718560.batch] Sending signal 18 to pid 69792 (mpirun)<br>
[2018-06-28T23:37:53.480] [718560.batch] Sending signal 18 to pid 69791 (slurm_script)<br>
[2018-06-28T23:37:53.480] [718560.batch] Sent signal 18 to 718560.429496729<br>
[2018-06-28T23:37:53.485] [718560.batch] error: *** JOB 718560 ON node38 CANCELLED AT 2018-06-28T23:37:53 ***<br>
[2018-06-28T23:37:53.488] [718560.batch] Sending signal 15 to pid 69794 (charmm)<br>
[2018-06-28T23:37:53.488] [718560.batch] Sending signal 15 to pid 69792 (mpirun)<br>
[2018-06-28T23:37:53.488] [718560.batch] Sending signal 15 to pid 69791 (slurm_script)<br>
[2018-06-28T23:37:53.488] [718560.batch] Sent signal 15 to 718560.4294967294<br>
[2018-06-28T23:37:53.492] [718560.batch] task 0 (69791) exited. Killed by signal 15.<br>
[2018-06-28T23:37:53.512] [718560.batch] job 718560 completed with slurm_rc = 0, job_rc = 15<br>
[2018-06-28T23:37:53.512] [718560.batch] sending REQUEST_COMPLETE_BATCH_SCRIPT, error:0 status 15<br>
[2018-06-28T23:37:53.516] [718560.batch] done with job<br>
<br>
The slurm cluster has a minimal configuration:<br>
<br>
ClusterName=cluster<br>
ControlMachine=master<br>
SchedulerType=sched/backfill<br>
SelectType=select/cons_res<br>
SelectTypeParameters=CR_Core<br>
FastSchedule=1<br>
SlurmUser=slurm<br>
SlurmdUser=root<br>
SlurmctldPort=6817<br>
SlurmdPort=6818<br>
AuthType=auth/munge<br>
StateSaveLocation=/var/spool/<wbr>slurm/<br>
SlurmdSpoolDir=/var/spool/<wbr>slurm/<br>
SwitchType=switch/none<br>
MpiDefault=none<br>
SlurmctldPidFile=/var/run/<wbr>slurmctld.pid<br>
SlurmdPidFile=/var/run/slurmd.<wbr>pid<br>
Proctracktype=proctrack/<wbr>linuxproc<br>
ReturnToService=2<br>
PropagatePrioProcess=0<br>
PropagateResourceLimitsExcept=<wbr>MEMLOCK<br>
TaskPlugin=task/cgroup<br>
SlurmctldTimeout=300<br>
SlurmdTimeout=300<br>
InactiveLimit=0<br>
MinJobAge=300<br>
KillWait=30<br>
Waittime=0<br>
SlurmctldDebug=4<br>
SlurmctldLogFile=/var/log/<wbr>slurmctld.log<br>
SlurmdDebug=4<br>
SlurmdLogFile=/var/log/slurmd.<wbr>log<br>
JobCompType=jobcomp/none<br>
JobAcctGatherType=jobacct_<wbr>gather/cgroup<br>
AccountingStorageType=<wbr>accounting_storage/slurmdbd<br>
AccountingStorageHost=master<br>
AccountingStorageLoc=all<br>
NodeName=node[01-45] Sockets=2 CoresPerSocket=10 State=UNKNOWN<br>
PartitionName=partition Nodes=ALL Default=YES MaxTime=INFINITE State=UP<br>
<br>
Thank you for your help.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Tom Payerle<br>
</div></div>DIT-ACIGS/Mid-Atlantic Crossroads <a href="mailto:payerle@umd.edu">payerle@umd.edu</a><mailto:<a href="mailto:payerle@umd.edu">payerle<wbr>@umd.edu</a>><br>
<div class="HOEnZb"><div class="h5">5825 University Research Park (301) 405-6135<br>
University of Maryland<br>
College Park, MD 20740-3831<br>
<br>
</div></div></blockquote></div><br></div>