DietPi-Services | docker.socket can accidentally wake up services and corrupt backups

[pacewicz]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | G_DIETPI_VERSION_CORE=10
  G_DIETPI_VERSION_SUB=3
  G_DIETPI_VERSION_RC=3
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'
  G_LIVE_PATCH_STATUS[0]='not applied'
  G_LIVE_PATCH_STATUS[1]='not applied'

• Distro version | bookworm

• Kernel version | Linux DietRock 6.18.22-current-rockchip64 #\1 SMP PREEMPT Sat Apr 11 12:26:52 UTC 2026 aarch64 GNU/Linux

• SBC model | Rock 4 SE

• Power supply used | 12V 2.5A

• SD card used | SanDisk Extreme A2 64G

Additional Information (if applicable)

• Software title | N/A
• Was the software title installed freshly or updated/migrated?
• Can this issue be replicated on a fresh installation of DietPi?

• Bug report ID | echo $G_HW_UUID

Steps to reproduce

when dietpi-backup runs:

• dietpi-services stop correctly stops docker.service
• It doesn't stop docker.socket, which is the socket-activation unit
• Any process touching /var/run/docker.sock during the backup window silently resurrects the daemon — in my case just a docker ps,
  but it's anything else on the system that might call Docker (monitoring tools, healthchecks, etc.)

Expected behaviour

not possible to accidentally wake up docker and corrupt backups.

Actual behaviour

possible to accidentally wake up docker and corrupt backups.

Extra details

My AI agent claims the fix in dietpi-services is one line: stop docker.socket alongside docker.service, and restore it on start.

Thank you for creating and maintaining a system that has been silently bringing a lot of simplicity into my life.

[MichaIng]

The AI agent is not wrong: docker.socket allows other processes to trigger docker.service to start. And containers which stop along with docker.service, usually also restart automatically when docker.service starts again. Depends on --restart option.

I remember we thought about this earlier, I need to check back whether there was some reason to not touch docker.socket.