The test code for the hanging case is:

CASE "check base env: set non-existing OCF_RESKEY_statusurl"
        Include prepare
        Env OCF_RESKEY_statusurl="yoyoyoyo"
        AgentRun start OCF_ERR_GENERIC


It looks like the env variable $OCF_RESKEY_statusurl gets used in the script in 
the apache_monitor_basic() routine, where it's used as $STATUSURL:

https://github.com/ClusterLabs/resource-
agents/blob/main/heartbeat/apache

I'm not certain how it is causing a hang in this case, but it's used
only by this line:

        if ${ourhttpclient}_func "$STATUSURL" | grep -Ei "$TESTREGEX" >
/dev/null  # <---

I'm guessing that `ourhttpclient` resolves to wget or curl or something.
Locally, both will error immediately:

stirling: ~/pkg/ResourceAgents/resource-agents-gu$ curl yoyoyoyo
curl: (6) Could not resolve host: yoyoyoyo
stirling: ~/pkg/ResourceAgents/resource-agents-gu$ wget yoyoyoyo
--2024-09-03 13:00:48--  http://yoyoyoyo/
Resolving yoyoyoyo (yoyoyoyo)... failed: Name or service not known.
wget: unable to resolve host address ‘yoyoyoyo’

Is it possible instead of erroring it is hanging, like on a domain
lookup?  I could imagine Launchpad's proxy blocking could do that.

It might be informative to do some instrumenting of the routine to see
where exactly it's failing, e.g.:

apache_monitor_basic() {
        echo "Attempting to run ${ourhttpclient}_func '$STATUSURL'..."
apache_monitor_basic() {
        if ${ourhttpclient}_func "$STATUSURL" | grep -Ei "$TESTREGEX" > 
/dev/null  # <---
        then
                echo "  ...unexpected success 1 (?!?)"
                return $OCF_SUCCESS
        fi

        attempt_index_monitor_request
        if [ $? -eq 0 ]; then
                echo "  ...unexpected success 2 (?!?)"
                return $OCF_SUCCESS
        fi

        if ! ocf_is_probe; then
                echo "  ...failed to probe httpd status page"
                ocf_exit_reason "Failed to access httpd status page."
        fi
        echo "...expected error situation"
        return $OCF_ERR_GENERIC
}

Honestly, I'm unclear if this test case is not super crucial for us to
run in Ubuntu's Autopkgtest; it is *supposed* to fail, just differently
than how it's failing for us.  :-P  It might be worth it to simply
disable the test case so the migration can complete, and maybe let
Debian and/or upstream know about the failure?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2078860

Title:
  DEP8 test case 3 fails, preventing migration in oracular

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/2078860/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to