SP starts up and runs but systemd things it timed out

[Herron, Joel D]

So something is afoot then, I'm not loading any aggregates at all just my local IDP metadata file which is maybe 5kb.

Everything loads

Endpoints, certs, metadata, everything no errors or warnings the last thing I see in the log is: 

2021-09-09 14:08:20 INFO Shibboleth.Listener : listener service starting 

Startup to that line is less than a second.

Systemctl start shibd.service just hangs there till it timeouts and then begins the infinite loop

Service file:

[Unit]
Description=Shibboleth Service Provider Daemon
Documentation=man:shibd(8)
Documentation=https://wiki.shibboleth.net/confluence/display/SP3/Home
After=network.target
Before=httpd.service

[Service]
Type=notify
NotifyAccess=main
User=shibd
#Environment=LD_LIBRARY_PATH=/opt/shibboleth/lib
ExecStart=/opt/shibboleth-sp/sbin/shibd -f -F
StandardInput=null
StandardOutput=null
StandardError=journal
TimeoutStopSec=10s
TimeoutStartSec=30s
Restart=on-failure
RestartSec=30s

[Install]
WantedBy=multi-user.target


Metadata section from shib2.xml

<!-- metadata provider. -->
        <MetadataProvider type="XML" url="XXXXXXX"
              backingFilePath="idp-metadata.xml" reloadInterval="7200">
              <MetadataFilter type="RequireValidUntil" maxValidityInterval="20734000"/>
              <MetadataFilter type="Signature" certificate="XXXXXX"/>
        </MetadataProvider>

        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" validate="true" url="XXXXXXXX"
                backingFilePath="XXXXXXXX" reloadInterval="7200"/>

I can provide the shibd log if that'd be helpful

On 9/9/21, 1:46 PM, "users on behalf of Peter Schober" <users-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at> wrote:

    *EXTERNAL EMAIL*

    * 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.

    -peter
    -- 
    For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net