This was a bug fixed in 15.08.2:
-- MYSQL - Remove restriction to have to be at least an operator to
query TRES
https://groups.google.com/forum/?fromgroups#!topic/slurm-devel/XiL7GA8CYj8
I am still running 15.08.1 but have a patch that seems to fix it if you're
interested.
M
On Tue, Nov 24, 2015 at 6:04 AM, Lucas Gabriel Vuotto <[email protected]>
wrote:
>
> Hello,
>
> we have a small HPC cluster managed by slurm. We're running version
> 15.08.1 on SL 6.5 . We implemented some per user cpu and gpu monthly quotas
> and we want them to be able to check their consumed quota. sreport would
> fill this task perfectly *excepts* that it returns:
>
> salvador@odin ~ $ sreport user top
> sreport: error: Access/permission denied
> sreport: fatal: Problem getting TRES data: Access/permission denied
>
> when run by a user with AdminLevel set to none. Even just running
> `sreport` gives the same error message. Both slurm.conf and slurmdbd.conf
> man pages says, in PrivateData description, that all users have, by
> default, access to all the information, and neither one says something
> about TRES data being private. We make clear that we let `PrivateData`
> unset in both config files.
>
> slurmdbd log doesn't shows any significant data (in our opinion) even when
> setting DebugLevel to debug4:
>
> slurmdbd: debug2: Opened connection 8 from 127.0.0.1
> slurmdbd: debug: DBD_INIT: CLUSTER:odin VERSION:7424 UID:2007
> IP:127.0.0.1 CONN:8
> slurmdbd: debug2: acct_storage_p_get_connection: request new connection 1
> slurmdbd: debug2: DBD_GET_TRES: called
> slurmdbd: error: Processing last message from connection 8(127.0.0.1)
> uid(2007)
> slurmdbd: debug4: got 0 commits
> slurmdbd: debug2: Closed connection 8 uid(2007)
>
> The "issue" isn't present when `sreport` is run by a user with AdminLevel
> set to operator or admin.
>
> Anyone have had this problem? Is there any way to fix it? Or should we
> stick to running a cron job every 5 minutes to gather the data with a
> privileged enough user and then make a mechanism so unprivileged users can
> access this data?
>
> If it's significant, we have both slurmctld and slurmdbd in the same
> machine.
>
> Cheers,
>
>
> -- lv.
>
