A dedicated thread (_kill_thr) is launched by slurmstepd at the end of a
step in order to destroy the IO thread if it does not manage to correctly
terminate by itself after 300 seconds.

Two bugs are corrected in this logic by this patch.

First, the performed sleep(300) is not protected against interruptions
and this delay can be reduced to a few seconds in case of signals received
by slurmstepd, thus, reducing the delay and forcing the IO thread to
terminate before the expiration of the grace time. The logic is modified
to ensure that the delay is respected using a loop around the sleep().

Second, to terminate the IO thread, a SIGKILL is delivered to the IO thread
using pthread_kill. However, sending SIGKILL using pthread_kill is a
process-wide operation (see man pthread_kill), thus all the slurmstepd
threads are killed and slurmstepd is terminated. This logic is modified
by using pthread_cancel() instead of pthread_kill() thus letting the
pthread_join() of _wait_for_io() having a chance to act as expected.

Without this patch, when _kill_thr is interrupted, slurmstepd is
terminated, letting the step in a incomplete state, as the node may not
have been able to send the REQUEST_STEP_COMPLETE to the controler.
Thus, consecutive steps can no longer be executed and stay permanently in
the "Job step creation temporarily disabled, retrying" state.

When requesting a particular nodelist for a step, if at least one of the node is
still used by a former step (no REQUEST_STEP_COMPLETE received from that node),
the current behavior is to return ESLURM_INVALID_TASK_MEMORY and srun aborting
with "Memory required by task is not available".

This can be reproduced by launching consecutive steps with the -w parameter set
to $SLURM_NODELIST and introducing delays in the spank epilog on the execution
nodes.

The behavior is changed to only defer the execution of the step by returning
ESLURM_NODES_BUSY when it is detected that some nodes are blocked because of
already used memory.

When using consecutive steps, it appears that in some cases, the time required
by the slurmstepd on the execution nodes to inform the controler of the completion
of the step is higher than the time required to request the following step.
In that scenario, the controler can reject the step by returning the error code
ESLURM_REQUESTED_NODE_CONFIG_UNAVAILABLE even if the step could be executed if
all the former steps were correctly finished.

This can be reproduced by launching consecutive steps and introducing dalys in
the spank epilog on the execution nodes.

The behavior is changed to only defer the execution of the step by returning
ESLURM_NODES_BUSY when all the available nodes are not idle considering the
former steps.

slurmctld restart.

allocation.

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.

specifying the number of tasks and not the number of nodes.

On job kill requeust, send SIGCONT, SIGTERM, wait KillWait and send
SIGKILL. Previously just sent SIGKILL to tasks.

Incorrect error codes returned in some cases, especially if the slurmdbd is down

Previously for linux systems all information was placed on a single line.

interface instead of through the normal method.

for passthrough gets removed on a dynamic system.

in error for passthrough.

user's pending allocation was started with srun and then for some reason
the slurmctld was brought down and while it was down the srun was removed.

previously it overwrote the poll_thread id

This is needed for when a free request is added to a block but there are
jobs finishing up so we don't start new jobs on the block since they will
fail on start.