<div dir="ltr"><div>I agree with Christopher Coffey - look at the sssd caching.</div><div>I have had experience with sssd and can help a bit.</div><div>Also if you are seeing long waits could you have nested groups?</div><div>sssd is notorious for not handling these well, and there are settings in the configuration file which you can experiment with.</div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Thu, 13 Jun 2019 at 16:52, Mark Hahn <<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">On Thu, 13 Jun 2019, Christopher Harrop - NOAA Affiliate wrote:<br>
...<br>
> One way I?m using to work around this is to inject a long random string<br>
>into the ?comment option.  Then, if I see the socket timeout, I use squeue<br>
>to look for that job and retrieve its ID.  It?s not ideal, but it can work.<br>
<br>
I would have expected a different approach: use a unique string for the<br>
jobname, and always verify after submission.  after all, squeue provides<br>
a --name parameter for this (efficient query by logical job "identity").<br>
<br>
regards, mark hahn.<br>
<br>
</blockquote></div>