- 29 Nov, 2012 2 commits
-
-
Morris Jette authored
-
Morris Jette authored
-
- 28 Nov, 2012 2 commits
-
-
Danny Auble authored
-
Danny Auble authored
you query against that with -N and -E you will get all jobs during that time instead of only the ones running on -N. Signed-off-by:
Danny Auble <da@schedmd.com>
-
- 27 Nov, 2012 5 commits
-
-
Danny Auble authored
-
Danny Auble authored
was already in error and isn't deallocating and underlying hardware goes bad one could get overlapping blocks in error making the code assert when a new job request comes in.
-
Danny Auble authored
overcommit.
-
Danny Auble authored
overcommit.
-
Morris Jette authored
Previously only requeued the job once
-
- 26 Nov, 2012 2 commits
-
-
Danny Auble authored
where needed)
-
jette authored
Otherwise an aborted slurmstepd can cause the srun process to hang indefinitely; a problem reported in trouble ticket 149.
-
- 22 Nov, 2012 1 commit
-
-
Danny Auble authored
introduce step accounting for a Cray.
-
- 21 Nov, 2012 3 commits
-
-
Morris Jette authored
-
Morris Jette authored
-
Morris Jette authored
This is needed if the munge deamon is under very heavy load (e.g. with 1000 slurmd daemons per compute node).
-
- 20 Nov, 2012 3 commits
-
-
Danny Auble authored
slurmctld restart.
-
Morris Jette authored
Modify sbast logic to continue when slurmd daemon restarts Previously a file transmission in progress would be aborted when any of the slurmd daemons restarted. Now it reconnects, revalidates the credential, and resumes file transmission.
-
Morris Jette authored
-
- 19 Nov, 2012 3 commits
-
-
Danny Auble authored
allocation.
-
Morris Jette authored
NOTE: If you were setting the environment variable SLURMSTEPD_OOM_ADJ=-17, it should be set to -1000 for Linux 2.6.36 kernel or later.
-
Danny Auble authored
-
- 09 Nov, 2012 2 commits
-
-
Morris Jette authored
-
Danny Auble authored
-
- 08 Nov, 2012 2 commits
-
-
Danny Auble authored
-
Danny Auble authored
Signed-off-by:
Danny Auble <da@schedmd.com>
-
- 07 Nov, 2012 5 commits
-
-
Danny Auble authored
-
Danny Auble authored
aprun process instead of a perl script.
-
Janne Blomqvist authored
the attached patch changes the default timestamp format in logfiles to conform to RFC 5424 (the current version of the syslog RFC). It is identical to the current default "ISO 8601" timestamp used by slurm, with the exception that the timezone offset is appended. This has the benefits of 1) It's unambiguous. 2) Avoids potential confusion for admins running cluster(s) in different timezones. 3) Might help debug issues related to DST transitions. (More on that later..) (To be pedantic, a RFC 5424 timestamp is still a valid ISO 8601 timestamp, but the converse is not necessarily true. So there is RFC 3339 which is a "profile" of ISO 8601, that is a subset, recommended for internet protocols. The RFC 5424 timestamp, in turn, is a subset of the RFC 3339 timestamps.) The previous behavior of can be used by running configure with the --disable-rfc5424time flag.
-
Danny Auble authored
-
Danny Auble authored
specifying the number of tasks and not the number of nodes.
-
- 05 Nov, 2012 2 commits
-
-
Morris Jette authored
On job kill requeust, send SIGCONT, SIGTERM, wait KillWait and send SIGKILL. Previously just sent SIGKILL to tasks.
-
Morris Jette authored
On job kill requeust, send SIGCONT, SIGTERM, wait KillWait and send SIGKILL. Previously just sent SIGKILL to tasks.
-
- 02 Nov, 2012 3 commits
-
-
Morris Jette authored
-
Morris Jette authored
-
Morris Jette authored
-
- 31 Oct, 2012 1 commit
-
-
Mark Nelson authored
launching that wouldn't be able to run to completion because of a GrpCPUMins limit.
-
- 29 Oct, 2012 2 commits
-
-
Morris Jette authored
Now try to get max node count rather than minimizing leaf switches used. For example, if each leaf switch has 8 nodes then a request for -N4-16 would allocate 8 nodes (one leaf switch) rather than 16 nodes over two leaf switches.
-
Morris Jette authored
Anyhow, after applying the patch, I was still running into the same difficulty. Upon a closer look, I saw that I was still receiving the ALPS backend error in the slurmctld.log file. When I examined the code pertaining this and ran some SLURM-independent tests, I found that we were executing the do_basil_confirm function multiple times in the cases where it would fail. My independent tests show precisely the same behaviour; that is, if you make a reservation request, then successfully confirm it and then attempt to confirm it again, you receive this error message. However, the "apstat -rvv" command shows that the ALPS reservation is fine and therefore I concluded that this particular ALPS/BASIL message is more of an informational one and not a "show-stopper." In other words, I can consider the node ready at this point. As a simple work around, I currently just inserted an if-block immediately after the call to "basil_confirm" in function "do_basil_confirm" in ".../src/plugins/select/cray/basil_interface.c." The if-statment checks for "BE_BACKEND" and if this is the result then it prints an informational message to slurmctld.log and sets the variable rc=0 so that we can consider the node ready. This, now allows my prolog scripts to run and I can clearly see the SLURM message that I had placed in that if-block. However, I am not certain if we really should just allow this error code to pass through as it seems like it could be a fairly generic code and there could be various other causes of it where we would not wish to allow it to pass. I really only want to limit the number of calls to basil_confirm to one. Perhaps I could add a field to the job_record so that I can mark whether the ALPS reservation had been confirmed or not.
-
- 26 Oct, 2012 2 commits
-
-
Danny Auble authored
instead of putting 0's into the database we put NO_VALS and have sacct figure out jobacct_gather wasn't used.
-
Olli-Pekka Lehto authored
-