signals all job steps, but not the job script itself).

variable.

Allocate calls were using job table info in place after freeing mutex.
New logic copies data structures, frees mutex, sends message, and
then frees memory allocated for copy.

with SIGCONT.

requests can get backed up in a queue while the job actually completes).

   - fixes to help ensure slurmd uses the same key for shared memory
     on a restart (to avoid losing track of jobs)
   - slurmd only runs one launch thread at a time
   - fix bug in slurmd where multiple threads used same address space
     for connecting client address.
   - srun always sends SIGKILL to job step before issuing complete request
   - Changed short string for draining nodes to drng from drain.
   - srun default launch message timeout increased to 5s.

some problems with slurmctld communication hangs.

re-opening it for every write. Moving the log file generates a
SIGHUP, which triggers a re-open anyway.

away at any time anyway.

src/api/free_msg.c.

queued allocation request is satisfied. Srun just has a stub to catch
and log the message while using polling to notice the allocation has
been made.

 o Modify srun(1) man page to reflect that, really, slurmd debug level
   is only allowed to be set up to 4.

Change clamp test for opt.slurmd_debug to use LOG_LEVEL_DEBUG3 as the upper limit.  This seems to be what's intended by the man page.

structure.

DOWN or DRAIN state and not responding. Changed logic to clear NO_RESPOND
flag before proceeding with logic.

slurmctld restart).

reading job info.

Use it directly from  backfill plugin (instead of API call).

attempt failure (i.e. convert to event driven instead of just polling).
It does still have a 2-second timer to keep the overhead reasonable.

state saves, backfill scheduler runs, etc. when there was not a significant
state change that should trigger those events.

"SchedAuth" and "SchedPort".

be changed whenever a node responded to a "ping" and other insignificant
events, which resulted in the backfill scheduling running more frequently
than required.

The plugin now gets passed the then current maximum priority to use as a
basis for setting the new job's priority (or not...).