Crontab on Margrop Blog

From 5m14s to 0.6s: How I Rebuilt My Docker Hub Mirror After Hitting Three Walls

Sat, 13 Jun 2026 07:20:00 +0800

TL;DR

My home lab had a registry:2 pull-through cache fronting Docker Hub for years, and it was fine. Then one day pulling a 5 MB alpine:3.19 took 5 minutes and 14 seconds. This post is the full forensic log of how I traced the slowdown, evaluated 8 candidate mirrors with real measurements (not vibes), and finished with a 5-line bash script on cron that auto-fails-over when the primary mirror goes down. Every number in this article was captured on my own hardware, in my own network, at one specific moment in time.

If you also self-host a Docker Hub mirror, or your team runs an internal registry, the Q&A at the bottom will probably save you 3 hours of pain.

PVE disk inspection connected to UptimeKuma - the 404 pitfall and the final script

Wed, 14 May 2025 22:16:48 +0800

Read first The previous article showed how to push the PVE host’s LVM-Thin usage to UptimeKuma. After following the instructions, some readers got a 404 when the script used curl. This article explains the cause, fixes the script, and provides an optional upgrade path. Follow along from scratch and you should succeed on the first try. 1 Phenomenon: curl ... 404 curl -fsS --retry 3 \ "${PUSH_URL}?status=up&msg=OK" \ -H 'Content-Type: application/json' \ --data-raw "$result" # ↳ curl: (22) The requested URL returned error: 404 The same URL works in a browser or with curl GET:

PVE host disk space monitoring - from pitfalls to UptimeKuma

Wed, 14 May 2025 22:11:33 +0800

Target Reader This article is written for readers who have just started using Proxmox VE (referred to as PVE) and want to copy the steps and get it running. The article aims to: explain why the problem happens provide the full command at each step give troubleshooting ideas when something goes wrong 0 Background - What went wrong? The official PVE installation wizard defaults to putting the VM disk into the LVM-Thin pool (commonly pve/data)

Scheduled Reboot for a Specific VM on PVE

Sun, 12 Mar 2023 20:59:38 +0800

Background

It was observed that the HomeAssistant VM’s memory usage kept increasing over time and eventually hit OOM. This happened no matter how many versions were upgraded, so it is suspected that HomeAssistant has a memory leak.

Solution

At the VM layer, reboot the VM periodically (once a day)
Log in to the server where PVE is running
Run crontab -e and enter the following:

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

0 12 * * * qm stop 2007 ; sleep 10 ; qm start 2007

Note: 2007 in the command is the vmid, the globally unique ID of the VM