Re: [slurm-users] sacct does always print all jobs regardless filter parameters with accounting_storage/filetxt
Am Fri, 31 Jan 2020 20:57:16 -0800 schrieb Chris Samuel : > You're using a very very very old version of slurm there (15.08) Well, that's what happens when an application gets into the mainstream and is included in the OS distribution. On this cluster, we just try to run with what Ubuntu LTS gives us. And I guess it is not atypical to keep a base OS release during the lifetime of a cluster, while this one already had 2 upgrades to newer LTS (another one probably should ivolve a rebuilding of the cluster) … You should get accustomed to people keeping asking questions about _really_ outdated Slurm versons;-) > should upgrade to a recent one (I'd suggest 19.05.5) to check whether > it's been fixed in the intervening years. But this seems to confirm my suspicion that at least people were not concerned that much with the simple text storage … otherwise it would be better known if this works or not. I tried running sacct from 19.05.5 on our config without touching the running instance of Slurm and it at least doesn't complain. The only difference I can see is that the default changed from showing all jobs in the history to showing none. Adding -u and -j works, but -N/-S/-E are still ignored. So apparently, during development of Slurm the journey quickly moved on to database storage before people got annoyed by long job lists, or the functionality got removed accidentally after the plain text storage went out of fashion. Well, since running a modern sacct directly on the old system works, I might get around to hack in the missing matches. Any helpful pointers before I blindly dig into the code? Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
Re: [slurm-users] sacct does always print all jobs regardless filter parameters with accounting_storage/filetxt
On 30/1/20 10:20 am, Dr. Thomas Orgis wrote: Matching for user (-u) and Job ID (-j) works, but not -N/-S/-E. So is this just the current state and it's up to me to provide a patch to enable it if I want that behaviour? You're using a very very very old version of slurm there (15.08), you should upgrade to a recent one (I'd suggest 19.05.5) to check whether it's been fixed in the intervening years. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Berkeley, CA, USA
Re: [slurm-users] sacct does always print all jobs regardless filter parameters with accounting_storage/filetxt
Am Thu, 30 Jan 2020 19:03:38 +0100 schrieb "Dr. Thomas Orgis" : > batch 1548429637 1548429637 - - 0 1 4294536312 > 48 node[09-15,22] (null) > > So, matching for job ID, user name (via numerical uid lookup), > timestamps and the nodes should be possible, it's all there. > > Can someone confirm that it indeed is the case that _none_ of the > filtering options of sacct are supposed to work on filetxt? Matching for user (-u) and Job ID (-j) works, but not -N/-S/-E. So is this just the current state and it's up to me to provide a patch to enable it if I want that behaviour? Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
Re: [slurm-users] sacct does always print all jobs regardless filter parameters with accounting_storage/filetxt
Am Thu, 30 Jan 2020 19:07:59 +0300 schrieb mercan : > Note: The filetxt plugin records only a limited subset of accounting > information and will prevent some sacct options from proper operation. Thank you for looking this up. But since the filetxt does contain the start/end timestamps and the nodes the job ran on, it is strange that sacct should not be able to filter on those criteria. This is an example line of the accounting file, with obvious identifying fields replaced by : batch 1548429637 1548429637 - - 0 1 4294536312 48 node[09-15,22] (null) So, matching for job ID, user name (via numerical uid lookup), timestamps and the nodes should be possible, it's all there. Can someone confirm that it indeed is the case that _none_ of the filtering options of sacct are supposed to work on filetxt? Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
Re: [slurm-users] sacct does always print all jobs regardless filter parameters with accounting_storage/filetxt
hi; From the slurm.conf documentation web page: Note: The filetxt plugin records only a limited subset of accounting information and will prevent some sacct options from proper operation. regards; Ahmet M. 29.01.2020 21:47 tarihinde Dr. Thomas Orgis yazdı: Hi, I happen to run a small cluster that doesn't use a slurmdbd but the plain log in a text file, accounting_storage/filetxt in slurm.conf. It is running Ubuntu 16.04 LTS and the slurm 15.08.7 provided with that. Can someone tell me if it is normal (or at least a known bug) that with this setup, sacct -X -N node04 always returns the full list of all jobs recorded in the accounting file? Likewise for filtering for start/endtime with -S/-E, no effect at all. It is also apparent that it really takes a long time for sacct to digest the text file, even if it is reduced to less than 5 jobs and about 6M in size. To give a figure: 24 seconds user time, keeping one core of a Xeon E5-2609 v2 @ 2.5 GHz busy. Alrighty then, Thomas PS: Please no pointers about better running a proper database with slurmdbd … I know that that works;-)
[slurm-users] sacct does always print all jobs regardless filter parameters with accounting_storage/filetxt
Hi, I happen to run a small cluster that doesn't use a slurmdbd but the plain log in a text file, accounting_storage/filetxt in slurm.conf. It is running Ubuntu 16.04 LTS and the slurm 15.08.7 provided with that. Can someone tell me if it is normal (or at least a known bug) that with this setup, sacct -X -N node04 always returns the full list of all jobs recorded in the accounting file? Likewise for filtering for start/endtime with -S/-E, no effect at all. It is also apparent that it really takes a long time for sacct to digest the text file, even if it is reduced to less than 5 jobs and about 6M in size. To give a figure: 24 seconds user time, keeping one core of a Xeon E5-2609 v2 @ 2.5 GHz busy. Alrighty then, Thomas PS: Please no pointers about better running a proper database with slurmdbd … I know that that works;-) -- Dr. Thomas Orgis HPC @ Universität Hamburg
