On 14/09/17 11:07, Lachlan Musicman wrote:
> Node configuration differs from hardware: CPUs=8:8(hw) Boards=1:1(hw)
> SocketsPerBoard=8:1(hw) CoresPerSocket=1:4(hw) ThreadsPerCore=1:2(hw)
OK, so this is saying that Slurm is seeing:
8 CPUs
1 board
1 socket per board
4 cores per socket
2 threads
I would suggest it is a more general requirement, not simply enforced by
use of munge, which does imply a unified uid trust level across all nodes
using the same preshared key, but also when jobs are started, they are
started with a particular uid and other credentials (transmitted in the
slurm
On 14 September 2017 at 11:10, Christopher Samuel
wrote:
>
> On 14/09/17 11:07, Lachlan Musicman wrote:
>
> > Node configuration differs from hardware: CPUs=8:8(hw) Boards=1:1(hw)
> > SocketsPerBoard=8:1(hw) CoresPerSocket=1:4(hw) ThreadsPerCore=1:2(hw)
>
> Hmm, are you
On 14/09/17 11:07, Lachlan Musicman wrote:
> Node configuration differs from hardware: CPUs=8:8(hw) Boards=1:1(hw)
> SocketsPerBoard=8:1(hw) CoresPerSocket=1:4(hw) ThreadsPerCore=1:2(hw)
Hmm, are you virtualised by some chance?
If so it might be that the VM layer is lying to the guest about
On 13/09/17 04:53, Phil K wrote:
> I'm hoping someone can provide an explanation as to why slurm
> requires uid/gid consistency across nodes, with emphasis on the need
> for the 'SlurmUser' to be uid/gid-consistent.
I think this is a consequence of the use of Munge, rather than being
inherent
I'm not trying to solve any problems, I'm just trying to understand the issue
well enough so that I can make informed decisions as a downstream package
maintainer. With the need for uid/gid consistency, we either need to pass on
the issue, i.e. package for use by root, or we need to do
On 2017-09-12 21:52, Phil K wrote:
I'm hoping someone can provide an explanation as to why slurm requires
uid/gid consistency
across nodes, with emphasis on the need for the 'SlurmUser' to be
uid/gid-consistent. I know
that slurmctld and slurmdbd can run as user `slurm` and that this would
be