<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Systemd on StackOnward</title><link>https://stackonward.com/tags/systemd/</link><description>Recent content in Systemd on StackOnward</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 11 Sep 2026 05:00:00 +0800</lastBuildDate><atom:link href="https://stackonward.com/tags/systemd/index.xml" rel="self" type="application/rss+xml"/><item><title>Automatic rollback for a failed deployment: transaction state, traffic switch, and rollback limits</title><link>https://stackonward.com/posts/automatic-deployment-recovery/</link><pubDate>Fri, 11 Sep 2026 05:00:00 +0800</pubDate><guid>https://stackonward.com/posts/automatic-deployment-recovery/</guid><description>&lt;p&gt;Automatic rollback for a failed deployment is not &lt;code&gt;docker compose down&lt;/code&gt; after the script dies. Recovery depends on three facts: whether the candidate already took public traffic, whether the previous upstream can still be restored, and whether business checks finished. If the previous version is still serving, stop only this candidate. If the traffic switch may be half-done, restore the previous upstream. If the new version is still in the observation window, switch back. Recovery should finish the commit records only when the release has already entered the commit phase.&lt;/p&gt;</description></item></channel></rss>