<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 7:02 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> I'm asking because it takes quite a bit of time to restart shibd (about 8<br>
> minutes) and during this time the SP is unavailable.<br>
<br>
</span>There is no earthly reason shibd would take 8 minutes to start up barring no resources or a totally screwed up approach to metadata. Even the eduGAIN metadata aggregate doesn't take much more than a minute or so, still bad, but nothing like that. And we have that improved now so that initial startup doesn't verify the signature on the backup file, so I doubt it even takes that long. You're doing something wrong.<br></blockquote><div><br></div><div><div>$ shibd -v</div><div>shibboleth 2.4.3</div></div><div><br></div><div>Watching shibd start just now (using strace and top) it took 8 minutes, and for about almost 6 minutes of that it was just spinning at 100% cpu not making any system calls.  By the end it's using over 2GB of virtual and 1.1GB of resident memory.</div><div><br></div><div>We have seven federations configured as well as a few direct IdPs.  Does that still seem unreasonably long for that much configuration?  If so, any suggestion on additional debugging?<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> Our load balancer is currently configured for sticky sessions (by IP) for the SP cluster.  So, if one of<br>
> the SPs in the cluster is taken down then any in-flight authentications would fail.<br>
<br>
</span>Any in flight logins will fail on the initial redirect to a resource no matter what (unless the state is offloaded).<br></blockquote><div><br></div><div>Yes, that makes sense.</div><div><br></div><div>I don't suppose there a way to have the "POST /Shibboleth.sso/SAML2/POST" on our SP run a script directly instead of making the redirect back to the original resource, right?</div><div><br></div><div><br></div><div>Thanks!</div></div></div></div>