blocks|key|980724|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<p>As your use-case is pretty custom and your needs might change a in the future, why don't you do something like the following...</p>
<p>create a new systemd timer (e.g. <code>failover-manager</code>) on both machines that runs once per minute.  The systemd timer will start an associated one-shot systemd service at regular intervals.</p>
<p>That one-shot systemd service can just run a bash script that contains your logic:</p>
<ul>
<li>run your <code>amIthePrimary</code> check</li>
<li>if primary, start your systemd service and check that it started without error.</li>
<li>if not primary, stop your systemd service if it is running.</li>
<li>if your script is unable to start/stop/verify-running, then it should fail (monitorable), otherwise succeeds.</li>
<li>this timer script doesn't need to output anything (noise wise) except when it makes a change ie:
<ul>
<li>&quot;I am primary, but service not running.  Starting...  Waiting a few seconds... verified service is running without error.&quot; or</li>
<li>&quot;I am not the primary but the service IS running.  Stopping.&quot;</li>
</ul>
</li>
</ul>
<p>This way you always know you can monitor that your regular/timer check is running without errors.
If your timer-service has issues (non-zero exit) you can catch this with monitoring.
You can monitor for failures of your main application service separately.</p>
<p>If your needs change you can easily adapt your timer script or the frequency it runs at.</p>
<p>There are probably cleaner ways to do this, but they would likely depend on an event being generated from whatever is behind your <code>amIthePrimary</code> check...and you didn't provide any details on that.  i.e. event driven failover rather than polling.</p>
<p>You could also put your <code>amIthePrimary</code> check into <code>ExecStartPre=</code>... but when it fails to prevent the service from starting, your service will be in a FAILED state which may confuse your monitoring because it isn't a bad fail but rather an intentional fail.  So you might prefer using the timer approach because then you can monitor your timer process and your main service process separately.  timer should always be running, active and not failing.  Your service (if running) should never be in a failed state or monitoring should go off.  There is another question about how to know whether the service should be running or not from a monitoring perspective, but that is beyond the scope of the question.</p>
<h1>Update - including sample implementation example</h1>
<p>Untested, but just to make my suggestion more clear.</p>
<h2><code>failover-manager.sh</code></h2>
<p>Let's say this script is deployed to <code>/opt/failover-manager/failover-manager.sh</code></p>
<pre class="lang-sh prettyprint-override"><code>#!/bin/bash

# expected ENV.  Provided by the service that starts this script.
#
# APP_SERVICE (your main application)
# SECONDS_TO_START (e.g. some java apps start very slowly)

if [ -z &quot;$APP_SERVICE&quot; -o -z &quot;$SECONDS_TO_START&quot; ]; then
    echo &quot;Missing environment&quot;
    exit 1
fi

function is_running {
    systemctl is-active --quiet $1
    return $?
}

if amIthePrimary; then
    if is_running $APP_SERVICE; then   # no change, no log
        exit 0
    else
        echo &quot;I AM primary, but service NOT running.  STARTING...&quot;
        systemctl start $APP_SERVICE
        sleep $SECONDS_TO_START
        if is_running $APP_SERVICE; then 
            echo &quot;Verified service is STARTED without error: $APP_SERVICE.&quot;
            exit 0
        else
            echo &quot;Service $APP_SERVICE has not yet STARTED after $SECONDS_TO_START seconds.&quot;
            exit 1
        fi
    fi
else
    if is_running $APP_SERVICE; then 
        echo &quot;I am NOT primary, but service IS running.  Stopping...&quot;
        systemctl stop $APP_SERVICE
        sleep $SECONDS_TO_START
        if is_running $APP_SERVICE; then 
            echo &quot;Service $APP_SERVICE has not yet STOPPED after $SECONDS_TO_START seconds.&quot;
            exit 1
        else
            echo &quot;Verified service is STOPPED: $APP_SERVICE.&quot;
            exit 0
        fi
    else   # no change, no log
        exit 0
    fi
fi

</code></pre>
<h2><code>failover-manager.timer</code></h2>
<pre><code>[Unit]
Description=Timer that starts failover-manager.service
Requires=failover-manager.service

[Timer]
Unit=failover-manager.service
# every 1 minute
OnCalendar=*:0/1
AccuracySec=1s
Persistent=true


[Install]
WantedBy=timers.target
</code></pre>
<h2><code>failover-manager.service</code></h2>
<p>This guy is run by the timer above.</p>
<pre><code>[Unit]
Description=Checks if we need to start or stop our application.

[Service]
Type=oneshot
Environment=APP_SERVICE=&quot;my-application.service&quot; SECONDS_TO_START=&quot;5&quot;    
WorkingDirectory=/opt/failover-manager/
ExecStart=/opt/failover-manager/failover-manager.sh

User=root
Group=root

</code></pre>
<h1>pure systemd options?</h1>
<p>If you are looking for a pure systemd mechanism to accomplish this in a clean way it may not be possible.</p>
<p>Your use-case is custom and IMO beyond the scope of systemd.</p>
<p>So you can &quot;hack&quot; it in using <code>ExecStartPre</code> or using <code>requires</code>/<code>wants</code> type dependency mechanisms...but all those approaches depend on a process either being in stopped state due to failure (breaks monitoring...is it an intended failure or something broken failure)... or that process being started/stopped by &quot;something&quot; that is aware of something outside the systemd world.  The latter doesn't break monitoring but does require something beyond systemd and what I proposed is one way to do that.</p>
<h1>alternatives</h1>
<p>Like @anx suggested... perhaps re-engineering how your DR failover works.</p>
<p>This is also the approach we take.  If we have a standby box/cloud/rack/etc, then we like to make sure everything is running already (e.g. services, etc).</p>
<p>Then the question is just... how to make the switch-over.</p>
<p>There are two common ways fail-over to a standby endpoint can be accomplished...</p>
<h2>1 - DNS failover</h2>
<p>Set a low DNS ttl (cache time) for your critical endpoints and update your DNS records to point at the standby endpoint (e.g. CNAME, A, AAAA DNS update) when a failure is detected.</p>
<p>Many managed DNS providers (e.g. dnsmadeeasy, dynect) offer this as part of their service (detection and fail-over).  But of course you can implement this with your own DNS or any DNS provider that enables you to set a low TTL and easily manually or automatically (monitoring + DNS API) update your DNS records.</p>
<p>One potential issue here is that you may worry about bots making requests to the &quot;non-active&quot; endpoint.  It will definitely happen but if your application is well designed it won't break anything to have a few requests coming into the standby DR endpoint.</p>
<p>The good thing is this forces you to think about how to make your application architecture more robust in terms of multiple concurrent endpoints receiving traffic (sharing databases, replication, etc).</p>
<p>If it is a big deal you can potentially add iptables rules to manage this...but then you may have the same problem as before...how to trigger the change (because now it is both DNS and iptables that need to have changes for the failover to happen).</p>
<h2>2 - load balancer failover</h2>
<p>It is quite common to have standby servers that are not active in a load balancer and can be quickly added/swapped into the pool of active servers behind the load balancer.</p>
<p>In this case the load balancer or a third component can manage the health checks and updating the load balancer config to swap healthy servers for unhealthy.</p>
<p>This doesn't work as well for a DR case as load balancers are usually rack or datacenter local.  So for DR you probably are better of building on a DNS-based fail-over to a different data-center/region.</p>


<p>We're using systemd to run various services in production. (Duh...)</p>
<p>We're building out a matching &quot;disaster-recovery&quot; site, which will have the same application installed -- with the same systemd-units to bring up its various components <em>in case of a disaster</em>.</p>
<p>This DR-environment is &quot;hot&quot;, ready to take over within a short time (the shorter the better) -- thus becoming production itself. Then, when the &quot;disaster&quot; is resolved, the other environment is to become the DR.</p>
<p>My question is, how to keep those systemd-services ready-to-start, but not <em>actually starting</em> until a certain condition becomes true?</p>
<p>In order to conclude, that a particular site is currently the <em>primary</em> (production), a command (<code>amIthePrimary</code>) needs to run and exit with a 0 exit-code. The check is easy and fast -- and can be performed as often as once a minute. But, because it requires running a command, there is no <a href="https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Conditions%20and%20Asserts" rel="nofollow noreferrer"><code>Condition</code> for it provided by systemd</a>.</p>
<p>Do I put that command into <em>every unit's</em> <code>ExecPre</code>, or will that become a noisy error, needlessly annoying the administrators? Do I put it into a unit of its own, with all other services <code>Require</code>-ing it?</p>
<p>Separately, once the condition is true -- and the services start -- how do I continue checking it, so they will all shut down, should it become false again?</p>


Systemd and Disaster-Recovery Stand-By systems

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我们使用systemd在生产中运行各种服务。(呃.)我们正在构建一个匹配的“灾难恢复”站点，该站点将安装相同的应用程序--具有相同的系统--单元，以便在发生灾难时调出其各种组件。这个DR-环境是“热”的，准备在短时间内接管(越短越好) --从而成为生产本身。然后，当“灾难”被解决后，另一个环境就变成了博士。我的问题是，如何使这些系统服务能够随时启动，但在某一特定条件变为真之前，却不能真正启动？为了

问系统和灾难恢复备用系统
EN

回答 1

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问系统和灾难恢复备用系统EN