Ticket 4088

Summary:	Sbatch verbose output returns wrong jobid
Product:	Slurm	Reporter:	Davide Vanzo <davide.vanzo>
Component:	Other	Assignee:	Director of Support <support>
Status:	RESOLVED INFOGIVEN	QA Contact:
Severity:	4 - Minor Issue
Priority:	---
Version:	17.02.6
Hardware:	Linux
OS:	Linux
Site:	Vanderbilt	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:	---
Machine Name:		CLE Version:
Version Fixed:		Target Release:	---
DevPrio:	---	Emory-Cloud Sites:	---

Description Davide Vanzo 2017-08-17 11:45:55 MDT

I just noticed that when I turn on the verbosity on sbatch output, the value for jobid does not match the actual job id but is equal to the CPU frequency field.
Below you can find an example.

Davide



sbatch: defined options for program `sbatch'
sbatch: ----------------- ---------------------
sbatch: user              : `vanzod'
sbatch: uid               : 389801
sbatch: gid               : 10000
sbatch: cwd               : /gpfs22/home/vanzod/Git/Sandbox/Slurm/LoadGenerator
sbatch: ntasks            : 3 (set)
sbatch: nodes             : 1-1
sbatch: jobid             : 4294967294 (default)
sbatch: partition         : default
sbatch: profile           : `NotSet'
sbatch: job name          : `job.sb'
sbatch: reservation       : `(null)'
sbatch: wckey             : `(null)'
sbatch: distribution      : unknown
sbatch: verbose           : 1
sbatch: immediate         : false
sbatch: overcommit        : false
sbatch: time_limit        : 60
sbatch: nice              : -2
sbatch: account           : (null)
sbatch: comment           : (null)
sbatch: dependency        : (null)
sbatch: qos               : (null)
sbatch: constraints       : mem-per-cpu=2M 
sbatch: geometry          : (null)
sbatch: reboot            : yes
sbatch: rotate            : no
sbatch: network           : (null)
sbatch: array             : N/A
sbatch: cpu_freq_min      : 4294967294
sbatch: cpu_freq_max      : 4294967294
sbatch: cpu_freq_gov      : 4294967294
sbatch: mail_type         : NONE
sbatch: mail_user         : (null)
sbatch: sockets-per-node  : -2
sbatch: cores-per-socket  : -2
sbatch: threads-per-core  : -2
sbatch: ntasks-per-node   : 3
sbatch: ntasks-per-socket : -2
sbatch: ntasks-per-core   : -2
sbatch: mem_bind          : default
sbatch: plane_size        : 4294967294
sbatch: propagate         : NONE
sbatch: switches          : -1
sbatch: wait-for-switches : -1
sbatch: core-spec         : NA
sbatch: burst_buffer_file : `(null)'
sbatch: remote command    : `/gpfs22/home/vanzod/Git/Sandbox/Slurm/LoadGenerator/job.sb'
sbatch: power             : 
sbatch: wait              : yes
sbatch: Consumable Resources (CR) Node Selection plugin loaded with argument 20
sbatch: Cray node selection plugin loaded
sbatch: Linear node selection plugin loaded with argument 20
sbatch: Serial Job Resource Selection plugin loaded with argument 20
Submitted batch job 41

Comment 2 Tim Shaw 2017-08-17 13:28:53 MDT

Hello Davide,

Actually, the number 4294967294 (0xfffffffe) is Slurm's internal representation of "not set" or NO_VAL as it's referred to in the code.  In this case, the job hasn't received an allocation and job_id yet from the slurmctld so it's set to NO_VAL.  There are several other fields that are also set to NO_VAL.

Hope that helps.

Regards.

Tim

Comment 3 Davide Vanzo 2017-08-17 13:58:38 MDT

Tim,

It makes totally sense now. Thank you for the clarification.
Please close the ticket.

Have a great day!

Davide

Comment 4 Tim Shaw 2017-08-17 14:16:48 MDT

Resolving.