SP starts up and runs but systemd things it timed out

Peter Schober peter.schober at univie.ac.at
Thu Sep 9 18:46:05 UTC 2021

* Herron, Joel D <herronj at uww.edu> [2021-09-09 20:29]:
> I saw some mention of TimeoutStartSec as a potential workaround by
> setting it to something large like 2 or 4hrs but that seems like a
> bandaid for a miss configuration.

It is what it is. Verifying the signature on very large metadata
aggregates (e.g. the size of InCommon) takes an absurdly long time
these days. The technical reasons for that are well-known but
practically impossible to replace (as discussed on this list).

(I.e., if you're NOT verifying signatures here with the SP and/or the
SP does NOT load a very large metadata aggregate then something else
is afoot and you'd need to share more technical details.)

So the best workaround would be to stop loading very large aggregates,
in the case of InCommon you'd use their MDQ service instead (see
InCommon documentation).

If that doesn't work for you for some reason I find that one of two
workarounds are very much tolerable:

1.a Make your the MetadataFilter of type=Signature has an
    verifyBackup="false" XML attribute set.
1.b Disable systemds timeout *once* (set to "infinite") and let the SP
    verify the metadata and write out a backup copy as usual.

Once that's done even restarts are very fast because of the previously
validated backup copy.

2. Download and verify metadata outside of the Shib SP (e.g. using a
   shell script with curl, xmllint, xmlsec1 or XmlSecTool) and if all
   your checks succeed move the metadata to a file system location the
   Shib SP is configured to look for it, but without a MetadataFilter
   of type=Signature in the SP.

In both cases you'll need to trust the local file system, but since
the SP loads keys and its own configuration from local files that's
not an additional worry.


More information about the users mailing list