I’m seeing a lot of this in the logs:
11/11/2019 15:23:55;0004;pbs_sched;Fil;holidays;The holiday file is out of date; please update it.
Year 0 in our conf file. According to this comment from 2016, we can have Year 0 but there will be an error message in the logs.
Is that the message, and is there any way to not have a holiday file? I note that there are other solutions here but nothing that both removes the need to have a holiday file and removes the log message?
holidays file is required for the prime/non-prime time
Please comment the entire holidays file and kill -HUP or restart pbs services.
This will make sure the message is not seen in the sched logs . This will make everything is prime time
Thanks! Am investigating now the reasons for having prime time.
We checked in some enhancements to the holidays file feature some time back: https://github.com/PBSPro/pbspro/pull/979
Setting year to 0 should also not cause it to print the “holidays file is out of date” message anymore.
But maybe you’ll find use of the prime-time feature, so do check that out.
That’s great - which version of PBSPro does that ship in? By my reckoning (a quick visual analysis of release dates) it was merged after v19.1.1 was released. Thanks
This commit contains the above PR :
* commit 9e03b31cb3355304969b6afccf1e78d709231757
| Author: Ravi Agrawal <firstname.lastname@example.org>
| Date: Mon Feb 4 16:36:19 2019 +0530
| holidays file: 24hrs prime-time for missing/inconsistent days
If you use previous version of PBS and building from source, You have some choices.
In our cluster, I use PBSPro v18.1.4 and building from source code (cloned by github),
(and v19.x did not work), so I did:
$ git fetch --all
$ git cherry-pick 9e03b31cb3355304969b6afccf1e78d709231757
Sorry for the late reply. Sounds like you were able to cherry-pick the commit, hopefully it works out ok.
Can you tell me what issues you came across when building v19.x from source?
Hi @agrawalravi90 !
Build is successfully.
I submit 1 job, then the node status becomes ‘job-busy’, even if the node have more free cpus.
This problem also happens on 18.1.x, but
I know that I can correct this problem by restarting pbs_server (sudo service pbs restart).
But In 19.x, I couldn’t correct it even if I restarted server.
And now I try to investigate the minimal configurations which reproduces problem (and then I’d like to post forum if I find reproduce conditions).
By gitting bisect, the following commit raises this ?:
* commit e270920b3d6cb8912f0bb420ee2821bea0e201e8 (HEAD, refs/bisect/bad)
| Author: Suresh Thelkar <suresh.thelkar...
| Date: Thu Aug 16 16:40:33 2018 +0530
| Database refactoring, creation and using API for the same
Thanks for explaining the issue @Takahiro. Just to be sure, the node’s ‘sharing’ attribute is set to ‘default_shared’ right? That should be the value that it gets out of the box.
@suresht might know more about the commit that you found. Although, I suspect that the commit just made it so that some information that was previously not stored to the database was now stored, that’s why you still see the issue after a server restart.