I am encountering a strange issue with email notifications. If I submit a regular job and use the #PBS -m abe and #PBS -M email@address.tld, I get notified of the job start and end. If I do the same with an array job there are no emails sent out. The only time I see emails sent out for array jobs is when the job is cancelled by the root user.
Am I missing an option to have array jobs send out emails?
Looks like a known bug. From the 14.2.1 (commercial) User Guide subjobs should send email:
The mail points argument is a string which consists of either the single character “n”, or one or more of the characters “a”, “b”, and “e”.
a Send mail when job or subjob is aborted by batch system
b Send mail when job or subjob begins execution
e Send mail when job or subjob ends execution
But there is an open bug (see PP-773):
Array jobs do not send any emails when specified with -m abe. The situation is reproducible.
The below does not send any email -
I have tested job array function with open source pbspro. there are two issues identified,
a testing environment has one server and two compute nodes each having 12 cores.
I submitted an array job with 30 subjobs. only 7 subjobs rather than 12 subjobs ran on each nodes. why? resources were not fully utilized.
I also tested preemption with array job. by setting sched_preempt_enforce_resumption as true in shecduler’s configuration file, I expect that the scheduler would treat preempted subjobs as top jobs so that when the preempor job completes, the suspended subjobs would resume to run immediately. However, the other queued subjobs started running while preempted subjobs were still suspended until there were free cores.
running array jobs is getting popular on many HPC facilities now. if these issues existed, many systems would stick to torque and maui.
Thanks for sharing what you are seeing. I would recommend that you start a new post since the two issues that you pointed out do not have much to do with the title of this post.
My guess is something is not configured correctly on your nodes. Can you provide the output of pbsnodes -a on the forum? Also, can you provide the output of qmgr -c “p s”?
It is possible that there is a bug here. Please review these bugs (https://pbspro.atlassian.net/browse/PP-310?jql=text%20~%20"resumption") and see if one of them matches what you are seeing. If not, please file a bug at pbspro.attlassian.net. If you are able to also provide the steps you took to encounter that issue that would be helpful for us to address the issue.
create resource Qlist
set resource Qlist type = string_array
set resource Qlist flag = h
Create queues and set their attributes.
Create and define queue workq
create queue workq
set queue workq queue_type = Execution
set queue workq enabled = True
set queue workq started = True
Create and define queue physics
create queue physics
set queue physics queue_type = Execution
set queue physics Priority = 10
set queue physics default_chunk.Qlist = physics
set queue physics enabled = True
set queue physics started = True
Create and define queue cmt
create queue cmt
set queue cmt default_chunk.Qlist = cmt
Create and define queue yossarian
create queue yossarian
set queue yossarian queue_type = Execution
set queue yossarian default_chunk.Qlist = yossarian
set queue yossarian enabled = True
set queue yossarian started = True
Create and define queue hippocrates
create queue hippocrates
set queue hippocrates queue_type = Execution
set queue hippocrates Priority = 200
set queue hippocrates default_chunk.Qlist = hippocrates
set queue hippocrates enabled = True
set queue hippocrates started = True
Set server attributes.
set server scheduling = True
set server default_queue = physics
set server log_events = 511
set server mail_from = adm
set server query_other_jobs = True
set server resources_default.ncpus = 1
set server default_chunk.ncpus = 1
set server scheduler_iteration = 600
set server resv_enable = True
set server node_fail_requeue = 310
set server max_array_size = 10000
set server pbs_license_min = 0
set server pbs_license_max = 2147483647
set server pbs_license_linger_time = 31536000
set server eligible_time_enable = False
set server max_concurrent_provision = 5
At first glance, I don’t see anything wrong with your configuration. Can you please share the command for how you submitted the job array? (i.e. qsub -J 1-30 …)
My only idea is that your jobs were very very short. The scheduler started a cycle and started running subjobs. Before the scheduler had finished its cycle, some subjobs had ended. By the time the cycle had ended, only 7 subjobs were running. It had run 10, but only 7 were remaining(indices 3-10). What was the array job’s array_indices_remaining attribute after the cycle?
sched_preempt_enforce_resumption is a sched object attribute set via qmgr. It isn’t set via the sched_config file. If set via the sched_config file, you’d get a error message in your sched log, but it’s kind of hidden in the startup messages. It’s really easy to miss.
It’s the memory on the nodes that’s hindering running more subjobs. My back of the envelope calculations show that you have 31gb per node. 7 subjobs require 28gb. There isn’t another 4gb to run another.
Hey Sue,
If you can set sched_preempt_enforce_resumption then the feature should work. You don’t need to wait for a future release.
How are jobs being preempted? Express queue? Soft limits? Are they suspended/requeued?
The preempted jobs should be top jobs in subsequent cycles after they are preempted. You should see a log message saying they are top jobs. It’s something like, "Job is a top job and will run at "
They are pretty high on the priority list. Any express queue jobs will come before them, but that’s it.
subjobs were pre-empted as suspended by a job through express queue. after I deleted the express job, other queued subjobs got to run while the pre-empted subjobs are still in suspension.
/usr/physics/pbspro/bin/qstat -1nt | more
headnode:
Req’d Req’d Elap
Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time
Sue,
I just found the issue in the code. Since subjobs don’t exist prior to being run, the scheduler makes sure it doesn’t alter them. It does this by checking if it is a subjob. Well after the job is run, it is still a subjob.
We mark a job as preempted by altering a boolean on the job.
This means the subjob never gets marked as preempted. Since it never gets marked as preempted, it doesn’t get higher priority in subsequent cycles.