| Summary: | sprio not showing any output | ||
|---|---|---|---|
| Product: | Slurm | Reporter: | dl_support-hpc |
| Component: | User Commands | Assignee: | Dominik Bartkiewicz <bart> |
| Status: | RESOLVED INFOGIVEN | QA Contact: | |
| Severity: | 4 - Minor Issue | ||
| Priority: | --- | CC: | bart |
| Version: | 20.02.1 | ||
| Hardware: | Linux | ||
| OS: | Linux | ||
| Site: | WEHI | Alineos Sites: | --- |
| Atos/Eviden Sites: | --- | Confidential Site: | --- |
| Coreweave sites: | --- | Cray Sites: | --- |
| DS9 clusters: | --- | HPCnow Sites: | --- |
| HPE Sites: | --- | IBM Sites: | --- |
| NOAA SIte: | --- | OCF Sites: | --- |
| Recursion Pharma Sites: | --- | SFW Sites: | --- |
| SNIC sites: | --- | Linux Distro: | CentOS |
| Machine Name: | CLE Version: | ||
| Version Fixed: | Target Release: | --- | |
| DevPrio: | --- | Emory-Cloud Sites: | --- |
Hi This is the correct behavior. Sprio shows priority from multi-factor priority plugin. By default, this means only pending jobs. from sprio man: >>> sprio is used to view the components of a job's scheduling priority when the multi-factor priority plugin is installed. sprio is a read-only utility that extracts information from the multi-factor priority plugin. By default, sprio returns information for all pending jobs. Options exist to display specific jobs by job ID and user name. >>> You can change this by PriorityFlags CALCULATE_RUNNING. slurm.conf man: >>> CALCULATE_RUNNING If set, priorities will be recalculated not only for pending jobs, but also running and suspended jobs. >>> Even without that, you can still check the priority of running jobs other tools like scontrol or squeue. eg.: squeue -o "%i %Q" I'll also note that I have lowered the severity of this ticket to 4. We take the severity levels seriously at SchedMD so that we can correctly identify critical situations where a system is down or severely impacted. For your reference the descriptions of the severity levels are found below. Severity Levels Severity 1 — Major Impact A Severity 1 issue occurs when there is a continued system outage that affects a large set of end users. The system is down and non-functional due to Slurm problem(s) and no procedural workaround exists. Severity 2 — High Impact A Severity 2 issue is a high-impact problem that is causing sporadic outages or is consistently encountered by end users with adverse impact to end user interaction with the system. Severity 3 — Medium Impact A Severity 3 issue is a medium-to-low impact problem that includes partial non-critical loss of system access or which impairs some operations on the system but allows the end user to continue to function on the system with workarounds. Severity 4 — Minor Issues A Severity 4 issue is a minor issue with limited or no loss in functionality within the customer environment. Severity 4 issues may also be used for recommendations for future product enhancements or modifications. Dominik *** Ticket 9176 has been marked as a duplicate of this ticket. *** Hi Can you confirm that this issue only affects running jobs? If yes do you have any additional questions or can we close this bug? Dominik Hi Dominik, You can close the ticket. Thanks, Laszlo Closing out this ticket, feel free to reopen if you have any other questions. Dominik |
Hi Support I am running version 20.02.3 on slurmctld and slurmdbd on compute nodes 20.02.1 I have multifactor configured PriorityType=priority/multifactor When running sprio no output is shown, neither for individual job [root@milton-sml-002 ~]# squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 36164 regular bionix-o bedo.j R 22:46 1 milton-med-004 [root@milton-sml-002 ~]# sprio -j 36164 Unable to find jobs matching user/id(s) specified [root@milton-sml-002 ~]# sprio -w JOBID PARTITION PRIORITY SITE AGE FAIRSHARE JOBSIZE PARTITION QOS Weights 1 8000 10000 3000 1 8000 This is very similar to bug 8727. Thanks and Regards, Laszlo