A lot of this is automated in the new versions of slurm.  You should just need to run:

sacctmgr show runawayjobs

It will then give you an option to clean them and slurm will handle the rest.  If you add the -i option it will just clean them automatically.

-Paul Edmon-

On 3/6/2019 11:58 AM, Cyrus Proctor wrote:

Hi Brian,

Others probably have better suggestions before going the route I'm about to detail. If you do go this route, be warned, you definitely have the ability to irrevocably lose data or destroy your Slurm accounting database. Do so at your own risk. I got here with Google-foo after being out of other (known to me) options. Someone please save Brian having to do what comes below ;-)

Last warning: I'd recommend turning off slurmdbd and backing up the database (mysqldump) before going forward.

In my case, runaway jobs did not show up with `sacctmgr list runawayjobs`. My problem was removing a user from the Slurm database because it thought they still had active jobs. The likely cause of this was the slurmdb daemon not shutting down gracefully at some point. The job was long gone but it was still in a pending state:

# sacct -j 899139
        JobID    JobName  Partition    Account  AllocCPUS      State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
899139            equil   gpu-long    p-1234         20    PENDING      0:0
# scontrol show job 899139
slurm_load_jobs error: Invalid job id specified
# mysql -u root -p
...
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7453
Server version: 5.1.73 Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use slurm_acct_db;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select state,time_end,time_start,time_submit,id_assoc,partition from 
banana_job_table where id_job=899139;
+-------+----------+------------+-------------+----------+-----------+
| state | time_end | time_start | time_submit | id_assoc | partition |
+-------+----------+------------+-------------+----------+-----------+
|     0 |        0 |          0 |  1546880711 |     2078 | gpu-long  |
+-------+----------+------------+-------------+----------+-----------+
1 row in set (0.00 sec)

mysql> update banana_job_table set state=3 where id_job=899139;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select state,time_end,time_start,time_submit,id_assoc,partition from 
banana_job_table where id_job=899139;
+-------+----------+------------+-------------+----------+-----------+
| state | time_end | time_start | time_submit | id_assoc | partition |
+-------+----------+------------+-------------+----------+-----------+
|     3 |        0 |          0 |  1546880711 |     2078 | gpu-long  |
+-------+----------+------------+-------------+----------+-----------+
1 row in set (0.00 sec)

mysql> update banana_job_table set time_start=1546880712 where id_job=899139;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select state,time_end,time_start,time_submit,id_assoc,partition from 
banana_job_table where id_job=899139;
+-------+----------+------------+-------------+----------+-----------+
| state | time_end | time_start | time_submit | id_assoc | partition |
+-------+----------+------------+-------------+----------+-----------+
|     3 |        0 | 1546880712 |  1546880711 |     2078 | gpu-long  |
+-------+----------+------------+-------------+----------+-----------+
1 row in set (0.00 sec)

mysql> update banana_job_table set time_end=1546880713 where id_job=899139;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select state,time_end,time_start,time_submit,id_assoc,partition from 
banana_job_table where id_job=899139;
+-------+------------+------------+-------------+----------+-----------+
| state | time_end   | time_start | time_submit | id_assoc | partition |
+-------+------------+------------+-------------+----------+-----------+
|     3 | 1546880713 | 1546880712 |  1546880711 |     2078 | gpu-long  |
+-------+------------+------------+-------------+----------+-----------+
1 row in set (0.00 sec)
In this case for job ID 899139 on the banana cluster, the state was not updated and neither were start or end times. I went in and manually edited the job entries such that Slurm thought they were complete with feasible start and end times. Again, this worked for me. I don't know if this is your problem or not. If you choose this route, be careful and good luck!

On 3/6/19 10:15 AM, Brian Andrus wrote:

It shows several jobs that all have "Unknown" for end_time. Some are PENDING and some are RUNNING (none are truly in either state).

It asked to fix them, which I did, but nothing seems to have changed. They still show up with that command and in reports.


Brian

On 3/5/2019 10:34 PM, Chris Samuel wrote:
On Tuesday, 5 March 2019 10:07:30 AM PST Brian Andrus wrote:

Does anyone have a process they use to handle empty (aka "Unknown") end
times for jobs that are not running?
What does:

sacctmgr list runawayjobs

say?


Reply via email to