Using the syscalls directly rather than calling bin/(u)mount via
system() avoids a few fork + exec calls, and provides better error
handling if something goes wrong.

Users of this functionality are also updated to use slurm_strerror in
order to provide a more informative error message.

The mount and umount syscalls are Linux-specific, but so are cgroups
so no portability is lost.

Using the syscalls directly rather than calling bin/(u)mount via
system() avoids a few fork + exec calls, and provides better error
handling if something goes wrong.

Users of this functionality are also updated to use slurm_strerror in
order to provide a more informative error message.

The mount and umount syscalls are Linux-specific, but so are cgroups
so no portability is lost.

Using the syscalls directly rather than calling bin/(u)mount via
system() avoids a few fork + exec calls, and provides better error
handling if something goes wrong.

Users of this functionality are also updated to use slurm_strerror in
order to provide a more informative error message.

The mount and umount syscalls are Linux-specific, but so are cgroups
so no portability is lost.

    the current plugin has been loaded when using runjob_mux_refresh_config

Correct parsing of srun/sbatch input/output/error file names so that only
the name "none" is mapped to /dev/null and not any file name starting
with "none" (e.g. "none.o"). This fixes bug #98.

Gres: If a gres has a count of one and an associated file then when doing
a reconfiguration, the node's bitmap was not cleared resulting in an
underflow upon job termination or removal from scheduling matrix by the
backfill scheduler.

Cray and BlueGene - Do not treat lack of usable front-end nodes when
slurmctld deamon starts as a fatal error. Also preserve correct front-end
node for jobs when there is more than one front-end node and the slurmctld
daemon restarts.

while it is attempting to free underlying hardware is marked in error
making small blocks overlapping with the freeing block.  This only
applies to dynamic layout mode.

is always set when sending or receiving a message.

than 1 midplane but not the entire allocation.

multi midplane block allocation.

where other blocks on an overlapping midplane are running jobs.

hardware is marked bad remove the larger block and create a block over
just the bad hardware making the other hardware available to run on.

allocation.

for a job to finish on it the number of unused cpus wasn't updated
correctly.

See Bugzilla #73 for more complete description of the problem.
Patch by Martin Perry, Bull.

If job is submitted to more than one partition, it's partition pointer can
be set to an invalid value. This can result in the count of CPUs allocated
on a node being bad, resulting in over- or under-allocation of its CPUs.
Patch by Carles Fenoy, BSC.

Hi all,

After a tough day I've finally found the problem and a solution for 2.4.1
I was able to reproduce the explained behavior by submitting jobs to 2 partitions.
This makes the job to be allocated in one partition but in the schedule function the partition of the job is changed to the NON allocated one. This makes that the resources can not be free at the end of the job.

I've solved this by changing the IS_PENDING test some lines above in the schedule function in (job_scheduler.c)

This is the code from the git HEAD (Line 801). As this file has changed a lot from 2.4.x I have not done a patch but I'm commenting the solution here.
I've moved the if(!IS_JOB_PENDING) after the 2nd line (part_ptr...). This prevents the partition of the job to be changed if it is already starting in another partition.

job_ptr = job_queue_rec->job_ptr;

part_ptr = job_queue_rec->part_ptr;
job_ptr->part_ptr = part_ptr;
xfree(job_queue_rec);

if (!IS_JOB_PENDING(job_ptr))

continue; /* started in other partition */

Hope this is enough information to solve it.

I've just realized (while writing this mail) that my solution has a memory leak as job_queue_rec is not freed.

Regards,
Carles Fenoy

there are jobs running on that hardware.

correctly when transitioning.  This also applies for 2.4.0 -> 2.4.1, no
state will be lost. (Thanks to Carles Fenoy)

bg.properties in order for the runjob_mux to run correctly.

Signed-off-by: Danny Auble <da@schedmd.com>

but job is going to be canceled because it is interactive or other reason
it now receives the grace time.

check if a block is still makable if the cable wasn't in error.

removal of the job on the block failed.

29d79ef8

same time a block is destroyed and that block just happens to be the
smallest overlapping block over the bad hardware.

but not node count the node count is correctly figured out.

Without this fix, gang scheduling mode could start without creating
a list resulting in an assert when jobs are submitted.

packing the step layout structure.

we must use a small block instead of a shared midplane block.

still messages we find when we poll but haven't given it back to the real
time yet.