Issue Summary: Docker Volume Mapping Inconsistency in fix/5709-sync-stall (v5.0.0+15)

Technical Support
1

A significant change in user privilege handling was observed when upgrading from the base Zebra v5.0.0 release to the temporary fix/5709-sync-stall branch (v5.0.0+15).

  • Previous Behavior (Standard v5.0.0): In the standard v5.0.0 release, the Docker container was configured to run the zebrad process as a non-root user. The application correctly identified the home directory as /home/zebra, and consequently, the block data was stored at /home/zebra/.cache/zebra. Binding the host volume to this path allowed for seamless data persistence and resumption.

  • Current Behavior in fix/5709-sync-stall (v5.0.0+15): In the fix/5709-sync-stall branch (v5.0.0+15), the container environment has been modified to execute the zebrad engine with root (administrator) privileges.

    Due to this change, the Linux operating system forces the application’s home directory to shift from /home/zebra to /root. Consequently, the node ignores the previously established volume mount at /home/zebra and defaults to creating a new database at /root/.cache/zebra, leading to a full re-synchronization (Height(0)) from scratch.

  • Resolution: To maintain data persistence when using this specific patch branch (v5.0.0+15), users must update their Docker run command to target the root cache directory:

    -v /host/path/to/zebra_data:/root/.cache/zebra

I would like to express my sincere gratitude to Autotunafish for introducing the fix/5709-sync-stall branch (v5.0.0+15). It has been incredibly helpful. I have been monitoring this version for over an hour, and all stall issues have completely disappeared. I hope this information is helpful to other node operators

2

Running a service as root in a container is generally a bad practice… I hope this regression will be revert before merging on main and releasing.

1 Like
3

I agree with you, but I’m just happy that it’s syncing without any stalls for now. Thanks for your advice!