Problem: Email Delivery Failures in ums-umc-server - "Task was destroyed but it is pending!"

Knowledge Base Community
, , , ,
1

Problem

Some instances may experience a complete failure in sending emails. During investigation, the system logs of the ums-umc-server pod exhibit a recurring error message indicating that asynchronous tasks are being destroyed prematurely.
Symptomatic Log Entries:

{"time":"...Z","log":"task: <Task pending name='Task-XXXX' coro=<wait_task() running at /usr/lib/python3/dist-packages/univention/management/console/resources.py:1080> ..."}
{"time":"...Z","log":"Task was destroyed but it is pending!"}

These entries repeat frequently throughout the day and correlate with the inability of the system to dispatch email notifications.

Root Cause

The issue is caused by a race condition in the asynchronous session handling of the Management Console, specifically within the SSELogoutNotifer component.

The system creates asyncio tasks to monitor session events. When a client connection is closed abruptly, these tasks are marked for cancellation.
If the parent object is garbage-collected before the asyncio event loop can formally transition the task to a done state, Python triggers the Task was destroyed but it is pending! warning.

While this appears to be a logging issue, the accumulation of these orphaned tasks can destabilize the global asyncio event loop, which in turn blocks other critical asynchronous operations, such as the communication with the email delivery module.

Bug Report: #59757

Environment

The issue has been identified in the following environment:

  • Product: Nubus for Kubernetes
  • Nubus Version: 1.19.1
  • UMC Server Version: 12.0.29
  • Component: ums-umc-server (Python-based management console)

Investigation

The root cause was identified through the following diagnostic steps:

  1. Log Correlation: Analyzing the timestamps of the Task was destroyed warnings and correlating them with the timing of failed email deliveries.
  2. Stack Trace Analysis: Tracing the error to /usr/lib/python3/dist-packages/univention/management/console/resources.py around the wait_task function.
  3. Resource Monitoring: Observation of the pod’s resource consumption, suggesting that event loop instability was impacting inter-process communication (IPC) between the UMC server and the underlying module processes.
  4. Code Review: Analysis of the SSELogoutNotifer class revealed that the asyncio tasks were not being held by a strong reference, allowing the Garbage Collector to destroy them while they were still in a pending state.

Workaround

Short-term Workaround
If email delivery is currently blocked, you can temporarily restore functionality by restarting the affected pod. This clears the current state of the asyncio event loop and removes pending orphaned tasks.
Command:
kubectl rollout restart statefulset/ums-umc-server -n <your-namespace>

Long-term Solution
The definitive fix requires a patch to the resources.py file to ensure that all asynchronous tasks are tracked in a reference set until they reach a terminal state. This fix is being tracked and implemented via the official update process. Please update your umc-server image to the version referenced in Bugreport #59757 once available.