DevOps on Margrop Blog

The Portainer 500 Error That Wasn't the YAML — A Two-librespeed_default-Network Story

Sat, 13 Jun 2026 08:00:00 +0800

The short version

You update a stack in Portainer. The browser slaps you with a red 500 Internal Server Error. You assume the YAML is wrong, fix the indentation, swap the quotes, drop the image tag. You hit Update again. Same 500. And again. And again.

The real culprit is buried at the deepest level of the HTTP response body: network librespeed_default is ambiguous (2 matches found on name). Two networks with the same name exist in the same Docker engine—two IDs, two Created timestamps, two com.docker.compose.config-hash labels, but a single shared name. Compose asks the engine to look up that name; the engine refuses to pick between them; compose up fails; Portainer wraps the error as a 500 and returns it to your browser.

The fix is embarrassingly simple: delete one of the two orphan networks (docker network rm <id> or click Remove in Portainer’s Networks page), then re-run Update the stack with the exact same content. It just works.

This post is a real debugging session: a stack update that was supposed to be a 30-second mount-path change turned into a 1-hour investigation. All private details (internal addresses, registry URLs, volume paths, container names, credentials) have been replaced with <PLACEHOLDER>. Only public source code, official docs, and the error text itself are preserved.

Your Background Process Keeps Dying After Shell Exit? Stop Blaming nohup — Understand setsid and Unix Process Lifecycle

Mon, 01 Jun 2026 07:00:00 +0800

The short version

You launched a background service. You used nohup. You added &. You redirected output. Everything looked fine. But when you closed the terminal, disconnected SSH, or—more insidiously—when an automation tool finished executing its script, the process silently vanished. You checked ps—nothing. You checked the port—nothing. No error in the logs. If this has happened to you, you’re not alone.

The root cause isn’t SIGHUP—at least, not entirely. The real issue is process group and session membership. nohup merely tells the process to ignore the SIGHUP signal, but the process still belongs to the same session and process group as the parent shell. When the shell exits and sends SIGHUP to the entire process group, nohup helps—but only if the signal delivery chain stops there. If the controlling terminal is destroyed, if stdin/stdout pipes break, or if the parent’s process group is collectively reaped, the process can still die. The proper fix is setsid: it creates a brand-new session, detaches from the controlling terminal, and places the process in its own process group—so SIGHUP from the parent shell never reaches it in the first place.

This post is based on a real debugging session of the CLIProxyAPI service. The service was started with nohup but kept disappearing every time an automation script finished. The management panel kept showing “connection failed.” The culprit turned out to be a subtle Unix process lifecycle issue. This class of problem is common in cloud dev machines, CI runners, SSH jump hosts, and containerized workflows, but it’s often misdiagnosed because the underlying process model is poorly understood.

All private details have been removed. No real internal addresses, tokens, or paths appear in this article.

Python App in macOS LaunchAgent Can't Reach the Internet? Here's the httpx Proxy Trap You Need to Know

Sat, 30 May 2026 09:00:00 +0800

TL;DR:

When a Python application using httpx with trust_env=True runs inside a macOS LaunchAgent, it silently picks up the system proxy settings from scutil --proxy. But the LaunchAgent process may not be able to reach that proxy server at all — resulting in All connection attempts failed or No route to host errors.

The fix is one line: add NO_PROXY=* to the LaunchAgent’s plist EnvironmentVariables.

This article documents the full debugging journey: from discovering that my AI Agent’s WeChat Enterprise (WeCom) messages weren’t being replied to, through methodical proxy troubleshooting, to finally pinning down the root cause — macOS system proxy + LaunchAgent network isolation. We’ll dive deep into Python httpx source code, macOS proxy architecture, and the many gotchas of LaunchAgent runtime environments.

The Complete AI Agent Migration Guide: A Real-World Journey from Scratch with 9 Pitfalls and Fixes

Sat, 30 May 2026 08:00:00 +0800

TL;DR:

Migrating from one AI Agent platform to another sounds like a “copy and paste” job. In reality, it’s a systems engineering challenge involving data migration, channel integration, scheduled tasks, auto-start configuration, proxy settings, and module compatibility.

This article documents my complete migration journey: from installing the new platform, migrating memories and skills, configuring messaging channels, debugging mysterious failures, to achieving fully automated operation. 9 pitfalls encountered, 9 solutions found — all shared here.

Migrating from OpenClaw to HermesAgent: A Smooth AI Agent Migration in Practice

Fri, 29 May 2026 08:00:00 +0800

Introduction: Why Am I “Moving”?

In 2026, the AI agent landscape is evolving at an incredible pace. Tools that were cutting-edge six months ago might already be surpassed by more powerful alternatives. As someone who relies heavily on AI agents for daily work, I’ve been closely following the latest developments in this field.

Recently, I completed a full migration from OpenClaw to HermesAgent. This wasn’t an impulsive decision, but a thoughtful choice made after experiencing the differences between the two tools in real-world usage.

This article will share in detail:

Background: What OpenClaw and HermesAgent are
Migration Reasons: Why I decided to migrate
Migration Process: Step-by-step guide to complete the migration
Pitfalls Encountered: Problems and solutions during migration
Post-Migration Cleanup: How to completely remove OpenClaw residuals
Post-Migration Experience: New capabilities gained from HermesAgent
Q&A: Frequently asked questions