Systemd ordering cycle on shutdown/reboot after ZimaOS 1.7.0 update

Meliodas · August 4, 2026, 6:42pm

Summary
After upgrading from a perfectly stable ZimaOS 1.6.0 or 1.6.1 to 1.7.0, the system fails to shut down or reboot cleanly. The journal shows a systemd ordering cycle that causes a forced reboot or kernel panic. This is a critical regression that affects system stability and makes unattended operation unreliable.

Hardware Context
The issue occurs on a system with ample resources, ruling out low-spec hardware as a cause:

CPU: Modern Intel Core i7 (12th gen or equivalent, 14 cores)
RAM: 62 GB total (14 GB used, 48 GB available)
Storage: Multiple drives (NVMe SSD for system + several HDDs for data)
Swap: 20 GB (originally a file inside /DATA, now moved to a dedicated partition)
Load average: ~3.5 (normal for this workload)
Temperatures: CPU 56–67°C, NVMe 37°C – well within limits

This is a capable server, not a low-end device.

The Problem (Only in 1.7.0)
The journal repeatedly shows:

var-lib-casaos_data.mount: Found ordering cycle:
DATA.mount/stop after DATA-.swapfile.swap/stop
after swap.target/stop after var.mount/stop
after var-lib-casaos_data.mount/stop - after DATA.mount

Root Cause:

Swap is located at /DATA/.swapfile.
/DATA is a bind mount of /var/lib/casaos_data.
DATA.mount has Requires=var-lib-casaos_data.mount.
var-lib-casaos_data.mount depends on var.mount.
var.mount has After=swap.target.
swap.target depends on the swap file inside /DATA.
On unmount, systemd tries to stop DATA.mount, which requires stopping var-lib-casaos_data.mount, which requires stopping var.mount, which waits for swap.target, but swap.target cannot be deactivated because /DATA is already being unmounted → deadlock.

This issue does not exist in 1.6.0 or 1.6.1. It is a regression introduced in 1.7.0.

Temporary Workaround Applied (For Reference)
To restore stability, the following workaround was applied:

Drop-in file for DATA.mount (/etc/systemd/system/DATA.mount.d/override.conf):

[Unit]
Requires=
After=var-lib-casaos_data.mount

(Removes Requires but keeps After for mount order)
Drop-in file for var.mount (/etc/systemd/system/var.mount.d/override.conf):

[Unit]
After=

(Removes After=swap.target)
Moved swap to a dedicated partition (e.g., /dev/sdX1) and updated /etc/fstab.

After these changes, the cycle disappears and the system shuts down/reboots cleanly. However, the original swap file /DATA/.swapfile is recreated automatically on every boot (likely by a CasaOS or ZimaOS startup script), which is unnecessary and could reintroduce the cycle if the drop‑ins are ever removed.

Steps to Reproduce (on 1.7.0)

Install or upgrade to ZimaOS 1.7.0 on a system where the default swap is placed inside /DATA (which is the default behaviour).
Reboot or shut down the system.
Observe the journal entry and the forced reboot.

Expected Fix (from the Official Side)

Option A (Recommended): Remove Requires=var-lib-casaos_data.mount from DATA.mount (keep After for mount order).
Option B: Remove After=swap.target from var.mount (tmpfs does not need to wait for swap).
Option C (Cleanest): Move the default swap location outside /DATA in future releases (e.g., to a dedicated partition or to /swapfile on the root filesystem, if writable).

Urgency
This is critical because it makes the system unreliable for unattended operation. Servers running ZimaOS 1.7.0 may reboot unexpectedly during routine shutdowns, causing service interruptions and potential data corruption. The issue does not exist in 1.6.x, so it is a clear regression that needs an urgent fix.

Additional Info

ZimaOS version: 1.7.0 (released 2026‑07‑28)
Systemd version: 255.6
Kernel: 6.1.94 (typical for ZimaOS)

Please investigate and provide an official fix. I am happy to test any patches.

github.com/IceWhaleTech/ZimaOS

Systemd ordering cycle on shutdown/reboot after ZimaOS 1.7.0 update

abierto 12:00PM - 04 Aug 26 UTC

Meliodas-96

Summary After upgrading from a perfectly stable ZimaOS 1.6.0 or 1.6.1 to 1.7.0, …the system fails to shut down or reboot cleanly. The journal shows a systemd ordering cycle that causes a forced reboot or kernel panic. This is a critical regression that affects system stability and makes unattended operation unreliable. Hardware Context The issue occurs on a system with ample resources, ruling out low-spec hardware as a cause: - CPU: Modern Intel Core i7 (12th gen or equivalent, 14 cores) - RAM: 62 GB total (14 GB used, 48 GB available) - Storage: Multiple drives (NVMe SSD for system + several HDDs for data) - Swap: 20 GB (originally a file inside /DATA, now moved to a dedicated partition) - Load average: ~3.5 (normal for this workload) - Temperatures: CPU 56–67°C, NVMe 37°C – well within limits This is a capable server, not a low-end device. The Problem (Only in 1.7.0) The journal repeatedly shows: var-lib-casaos_data.mount: Found ordering cycle: DATA.mount/stop after DATA-.swapfile.swap/stop after swap.target/stop after var.mount/stop after var-lib-casaos_data.mount/stop - after DATA.mount Root Cause: - Swap is located at /DATA/.swapfile. - /DATA is a bind mount of /var/lib/casaos_data. - DATA.mount has Requires=var-lib-casaos_data.mount. - var-lib-casaos_data.mount depends on var.mount. - var.mount has After=swap.target. - swap.target depends on the swap file inside /DATA. - On unmount, systemd tries to stop DATA.mount, which requires stopping var-lib-casaos_data.mount, which requires stopping var.mount, which waits for swap.target, but swap.target cannot be deactivated because /DATA is already being unmounted → deadlock. This issue does not exist in 1.6.0 or 1.6.1. It is a regression introduced in 1.7.0. Temporary Workaround Applied (For Reference) To restore stability, the following workaround was applied: 1. Drop-in file for DATA.mount (/etc/systemd/system/DATA.mount.d/override.conf): [Unit] Requires= After=var-lib-casaos_data.mount (Removes Requires but keeps After for mount order) 2. Drop-in file for var.mount (/etc/systemd/system/var.mount.d/override.conf): [Unit] After= (Removes After=swap.target) 3. Moved swap to a dedicated partition (e.g., /dev/sdX1) and updated /etc/fstab. After these changes, the cycle disappears and the system shuts down/reboots cleanly. However, the original swap file /DATA/.swapfile is recreated automatically on every boot (likely by a CasaOS or ZimaOS startup script), which is unnecessary and could reintroduce the cycle if the drop‑ins are ever removed. Steps to Reproduce (on 1.7.0) 1. Install or upgrade to ZimaOS 1.7.0 on a system where the default swap is placed inside /DATA (which is the default behaviour). 2. Reboot or shut down the system. 3. Observe the journal entry and the forced reboot. Expected Fix (from the Official Side) - Option A (Recommended): Remove Requires=var-lib-casaos_data.mount from DATA.mount (keep After for mount order). - Option B: Remove After=swap.target from var.mount (tmpfs does not need to wait for swap). - Option C (Cleanest): Move the default swap location outside /DATA in future releases (e.g., to a dedicated partition or to /swapfile on the root filesystem, if writable). Urgency This is critical because it makes the system unreliable for unattended operation. Servers running ZimaOS 1.7.0 may reboot unexpectedly during routine shutdowns, causing service interruptions and potential data corruption. The issue does not exist in 1.6.x, so it is a clear regression that needs an urgent fix. Additional Info - ZimaOS version: 1.7.0 (released 2026‑07‑28) - Systemd version: 255.6 - Kernel: 6.1.94 (typical for ZimaOS) Please investigate and provide an official fix. I am happy to test any patches.

piterdan · August 7, 2026, 2:50am

Hi, thanks for reporting this issue and for providing the detailed logs.
We’ve identified and fixed the systemd ordering cycle that occurred during shutdown/reboot after the ZimaOS 1.7.0 update. The fix will be included in the next ZimaOS update.
We apologize for the inconvenience and appreciate your help in improving ZimaOS.

Meliodas · August 7, 2026, 12:12pm

Thanks for the quick response and for confirming the fix. I’ve updated the GitHub issue with the additional findings. If you need someone to test future updates or provide more feedback, I’d be happy to help as a tester – I have the hardware available and can reproduce various scenarios.