sap_swpm: sap_install sum_push_to_finish.yaml

[rel0aded0ne]

Ansible Role

sap_swpm

OS Family

SLES

Ansible Controller - Python version

python3 --version
3.6.15

python3.11 --version
3.11.13

Ansible-core version

ansible-core | 2.16.0

Bug Description

When performing an UpToDate installation with SUM, I receive the following error in the step "Checking the status of SUM (BIND_PATCH)":

TASK [community.sap_install.sap_swpm : Checking the status of SUM (BIND_PATCH)] ***
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (60 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (59 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (58 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (57 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (56 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (55 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (54 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (53 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (52 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (51 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (50 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (49 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (48 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (47 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (46 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (45 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (44 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (43 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (42 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (41 retries left).
fatal: [SAP]: UNREACHABLE! =>
{
    "changed": false,
    "msg": "Failed to create temporary directory.
            In some cases, you may have been able to authenticate and did not have permissions on the target directory.
            Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\", for more error information use -vvv.
            Failed command was:
            ( umask 77 && mkdir -p \"` echo /tmp `\"
            && mkdir \"` echo /tmp/ansible-tmp-1765031130.8066328-3947948-46034691601514 `\"
            && echo ansible-tmp-1765031130.8066328-3947948-46034691601514=\"` echo /tmp/ansible-tmp-1765031130.8066328-3947948-46034691601514 `\" ),
            exited with result -13",
    "unreachable": true
}

When I open SUM, the process is stuck at 10% and is waiting for me to click Next.

Bug reproduction

The problem can be reproduced with every update process. I always have to open SUM manually and confirm the step at 10% by clicking Next.

Community participation

Unfortunately I am not in a position to help with the bug fix

[marcelmamula]

Hello @rel0aded0ne ,
Your output log mentions Failed to create temporary directory. In some cases, you may have been able to authenticate and did not have permissions on the target directory. which could be just generic error masking your actual issue.

Can you share more details as:

• Release number of sap_install collection.
• SUM related variables set when running role (sap_swpm_sum_*
• Was this fresh install?
• What page was SUM stuck at?
• This task checks URL https://localhost:1129/lmsl/sumobserver/<SID>/analysis/SUMOBSERVER.XML so it would be great if you could check its contents before you are forced to push next.
• Do you have any security measures in place like Apparmor that could block filesystem access for ansible in tmp?

@berndfinger

[sean-freeman]

@marcelmamula 10% should be versions confirmation page

If /tmp had read/write permission issues, I would've expected an error earlier in sap_swpm Ansible Role or any of the proceeding Ansible Roles. For example the previous Ansible Task uses Ansible Module ansible.builtin.command which would have also used a temp file, and yet this Ansible Task using Ansible Module ansible.builtin.uri fails?

The error message shown is return code -13, which is simply permission denied. See below that this could just be because the SSH ControlPersist expired after 20 minutes? :

• https://forum.ansible.com/t/tmp-issue/37046/3
• >>> https://github.com/ansible/ansible/issues/81777

Very odd behaviour

@rel0aded0ne When the Ansible Task freezes, from another SSH session please run this shell command to see if there is some issue at the host-level accessing the file:

# Define SAP System ID, edit with connection details
sap_system_id_upper="S01"
sap_system_id_adm="s01adm"
sap_system_id_adm_password='NewPass$321'

# Retrieve observer file, and show return code (should be 200) and we're specifically looking for XML element <dialogId>
curl --verbose --insecure --user "$sap_system_id_adm":"$sap_system_id_adm_password" \
https://localhost:1129/lmsl/sumobserver/$sap_system_id_upper/analysis/SUMOBSERVER.XML

[rel0aded0ne]

First of all, thank you very much for your responses. I started the installation and the SUM process three times and each time I encountered the same error. In the last attempt earlier today, it went past the 10% mark, and it seems that everything is working now. That's a little odd.

TASK [community.sap_install.sap_swpm : Checking the status of SUM (BIND_PATCH)] ***
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (60 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (59 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (58 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (57 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (56 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (55 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (54 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (53 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (52 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (51 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (50 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (49 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (48 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (47 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (46 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (45 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (44 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (43 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (42 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (41 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (40 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (39 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (38 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (37 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (36 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (35 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (34 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (33 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (32 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (31 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (30 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (29 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (28 retries left).
FAILED - RETRYING: [SAP]: Checking the status of SUM (BIND_PATCH) (27 retries left).
ok: [SAP]

TASK [community.sap_install.sap_swpm : Get the config XML from SUM (BIND_PATCH)] ***
ok: [SAP]

TASK [community.sap_install.sap_swpm : Get the CSRF token from SUM (BIND_PATCH)] ***
ok: [SAP]

TASK [community.sap_install.sap_swpm : Move SUM to the next step (SPAUINFO)] ***
ok: [SAP]

[sean-freeman]

@rel0aded0ne OK so that's not right either. ansible-playbook -vvvv please 🙂

Either we need to add some debug documentation, checks before execution, or warning messages.

[rel0aded0ne]

@rel0aded0ne OK so that's not right either. ansible-playbook -vvvv please 🙂

Either we need to add some debug documentation, checks before execution, or warning messages.

I will start a new run later that day or tomorrow and execute the playbook with -vvv.
But I noticed something else. The SUM actually finished successfully, but the playbook kept waiting unsuccessfully on the step “Checking the status of SUM (SPAUINFO) every 5 minutes.”

Apparently, no SPAU came up during the installation, and therefore it got stuck in that phase — 145 attempts every 5 minutes.

`FAILED - RETRYING: [sapmwtpas@Rechenzentrum-Volmarstein_16543_S0005049321]: Checking the status of SUM (SPAUINFO) every 5 minutes (1 retries left).
fatal: [sapmwtpas@Rechenzentrum-Volmarstein_16543_S0005049321]: FAILED!

=> {"attempts": 144, "cache_control": "max-age=15", "changed": false, "connection": "close", "content": "\n\n \n SUM4ABAP\n SUM4ABAP\n slp.task.type.PROCESS\n SAPup\n Update on SAP S/4HANA (Single System)\n slp.task.state.RUNNING\n UPGRADE\n \n <estimate left="23:12">2025/12/08 18:00:04\n 63792120\n 20251209044651\n 1\n 85\n 0\n logs\n \n \n 1\n Current Phase: MAIN_TRANSEXEC/ACT_TRANS\n \n \n \n \n EXECUTE\n EXECUTE\n slp.task.type.ROADMAP.TECH\n EXECUTE\n slp.task.state.RUNNING\n SUM4ABAP\n \n \n 1\n Activating ABAP Dictionary Objects\n\n \n \n \n \n MAIN_TRANSEXEC\n MAIN_TRANSEXEC\n slp.task.type.ROADMAP.TECH\n MAIN_TRANSEXEC\n slp.task.state.RUNNING\n EXECUTE\n \n \n 1\n Activating ABAP Dictionary Objects\n\n \n \n \n \n ACT_TRANS\n ACT_TRANS\n slp.task.type.STEP\n ACT_TRANS\n slp.task.state.RUNNING\n MAIN_TRANSEXEC\n 2025-12-08T17:36:52\n \n \n 1\n Activating ABAP Dictionary Objects\n\n \n \n \n \n PARALLEL_PROCESSES\n PARALLEL_PROCESSES\n slp.task.type.INTERNAL_SUBSTEP\n PARALLEL_PROCESSES\n slp.task.state.RUNNING\n ACT_TRANS\n \n \n 1\n Activating ABAP Dictionary Objects\n\n \n \n \n\n", "content_length": "2613", "content_type": "text/xml", "cookies": {}, "cookies_string": "", "date": "Tue, 09 Dec 2025 03:47:06 GMT", "elapsed": 0, "etag": ""E5274DF3BA2BED53A565535FEAC26B3"", "failed_when_result": true, "last_modified": "Tue, 09 Dec 2025 03:46:59 GMT", "msg": "OK (2613 bytes)", "redirected": false, "server": "SAP Host Agent", "status": 200, "url": "https://localhost:1129/lmsl/sumobserver/MWT/analysis/SUMOBSERVER.XML", "x_frame_options": "SAMEORIGIN", "x_saphostagent_correlation_id": "3183617606481FD0B5941EEFDEBC0000"}
`

[marcelmamula]

Current workflow of this task file is:

• 5 min async wait for process SAPup_real
• 60 min async wait for BIND_PATCH phase using https://localhost:1129/lmsl/sumobserver/{{ sap_swpm_sid | upper }}/analysis/SUMOBSERVER.XML
  • Extract config from https://localhost:1129/slp/sumabap/{{ sap_swpm_sid | upper }}/config and push back same unchanged config to move it to next phase SPAUINFO
• 12 hour async wait for SPAUINFO phase using https://localhost:1129/lmsl/sumobserver/{{ sap_swpm_sid | upper }}/analysis/SUMOBSERVER.XML
  • Extract config and push back to move to another phase again, until EXIT.

It is possible that in your cause SPAU phase behaved differently than expected by this workflow.

[rhmk]

Hi,
"Failed Retrying" - is not an error message. Nonetheless it is misleading.
In Ansible you have to run large jobs, like the SWPM install asynchronously, i.e. the job runs in the background.

We then wait for the job to be finished. So there "Error" message just means, that the job in the background is still running. When it returns with ok before the "tries" are over the job was successful.

A few outputs earlier the role prints a "tail command" that you should run on the managed node, to follow the REAL logs and messages. This is important because if any error occurs it is only listed in the file that is tailed.
The SWPM command comes always - no matter which error occured - with a message that there is a profile error.

Hope that clarifies the behaviour. The role is working as it should work.

[rhmk]

Unfortunately there is no way in Ansible to change the output "FAILED - RETRYING" in something like "WAITING ON TASK TO FINISH"
The only thing we could do is to clarify the output behind "FAILED - RETRYING" with something like:

loop_control:
    label: "Waiting on task to finish (Attempt {{ sum_status.attempts | default(1) }})"

[rel0aded0ne]

Sorry, I think I expressed myself incorrectly.
What you are saying is correct, but if SUM does not require a SPAU step, it will always get stuck at that step, right?
If I understood correctly, the playbook waits for SPAU to come up,
but if it never appears, the step TASK [community.sap_install.sap_swpm : Checking the status of SUM (SPAUINFO) every 5 minutes] will never be completed, and therefore it understandably fails.

SUM has finished, but no SPAU was ever requested.

[rel0aded0ne]

Hi, "Failed Retrying" - is not an error message. Nonetheless it is misleading. In Ansible you have to run large jobs, like the SWPM install asynchronously, i.e. the job runs in the background.

We then wait for the job to be finished. So there "Error" message just means, that the job in the background is still running. When it returns with ok before the "tries" are over the job was successful.

A few outputs earlier the role prints a "tail command" that you should run on the managed node, to follow the REAL logs and messages. This is important because if any error occurs it is only listed in the file that is tailed. The SWPM command comes always - no matter which error occured - with a message that there is a profile error.

Hope that clarifies the behaviour. The role is working as it should work.

The error message in this case should only indicate that it reached the maximum number of retries while waiting for SPAU. But SPAU never appeared because it wasn’t required. The messages themselves are not the problem — the issue is simply that it keeps waiting for a SPAU step that will never occur.

[marcelmamula]

Yes you are correct, it is specifically waiting for SPAU by checking status xml for string <dialogId>SUM4ABAP|POST-EXECUTE|MAIN_POSTPROC|SPAUINFO|FinishSPAU</dialogId> and response 200.

This means that if yours was skipped and went directly to next step, it will wait until end of loop attempts and check failed condition.

It would make sense to update this look to be able to skip SPAU.

[rel0aded0ne]

Yes you are correct, it is specifically waiting for SPAU by checking status xml for string <dialogId>SUM4ABAP|POST-EXECUTE|MAIN_POSTPROC|SPAUINFO|FinishSPAU</dialogId> and response 200.

This means that if yours was skipped and went directly to next step, it will wait until end of loop attempts and check failed condition.

It would make sense to update this look to be able to skip SPAU.

Wouldn't it be possible to prevent the step from aborting if the condition is not met?

failed_when: _sap_swpm_sum_push.status != 200 or '<dialogId>SUM4ABAP|CONFIGURE|PREP_EXTENSION|BIND_PATCH|PatchSelection</dialogId>' not in _sap_swpm_sum_push.content

If the condition is not met within 60 minutes, couldn’t we assume that there was no SPAU?

[marcelmamula]

Yes that should not be an issue, but it will require proper testing.
Maybe original author of this SUM logic can give us his opinion @rob0d

[rob0d]

Hi @rel0aded0ne,

If SUM is executed correctly at the end of SWPM install it will go through all three steps: BIND_PATCH, SPAUINFO and MAIN_POSTCLEAN|EXIT. Based on what you mentioned above it seems that SUM is either finishing before going through these steps or not going through all of them. It is likely that the problem isn't with Ansible, but with what SUM is doing.

To gain better understanding, can you provide a copy of the PDF file that's generated at the end of Maintenance Planner transaction? I suspect that the selection there is what's causing this behaviour.

As as side note I am working on a updated version of the SUM handling code which will be more flexible and use events rather than follow linear execution, but that's not going to be ready until early next year.