From: Dominik Csapak <d.csapak@proxmox.com>
To: pbs-devel@lists.proxmox.com
Subject: [pbs-devel] [PATCH proxmox-backup] tools/daemon: improve reload behaviour
Date: Wed, 16 Dec 2020 09:12:09 +0100 [thread overview]
Message-ID: <20201216081209.6997-1-d.csapak@proxmox.com> (raw)
it seems that sometimes, the child process signal gets handled
before the parent process signal. Systemd then ignores the
childs signal (finished reloading) and only after going into
reloading state because of the parent. this will never finish.
Instead, wait for the state to change to 'reloading' after sending
that signal in the parent, an only fork afterwards. This way
we ensure that systemd knows about the reloading before actually trying
to do it.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
this all goes away with systemds notify barrier hopefully....
src/tools/daemon.rs | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/tools/daemon.rs b/src/tools/daemon.rs
index 6bb4a41b..2aa52772 100644
--- a/src/tools/daemon.rs
+++ b/src/tools/daemon.rs
@@ -291,6 +291,7 @@ where
if let Err(e) = systemd_notify(SystemdNotify::Reloading) {
log::error!("failed to notify systemd about the state change: {}", e);
}
+ wait_service_is_active_or_reloading(service_name, true).await?;
if let Err(e) = reloader.take().unwrap().fork_restart() {
log::error!("error during reload: {}", e);
let _ = systemd_notify(SystemdNotify::Status("error during reload".to_string()));
@@ -305,7 +306,7 @@ where
// FIXME: this is a hack, replace with sd_notify_barrier when available
if server::is_reload_request() {
- wait_service_is_active(service_name).await?;
+ wait_service_is_active_or_reloading(service_name, false).await?;
}
log::info!("daemon shut down...");
@@ -313,7 +314,7 @@ where
}
// hack, do not use if unsure!
-async fn wait_service_is_active(service: &str) -> Result<(), Error> {
+async fn wait_service_is_active_or_reloading(service: &str, wait_for_reload: bool) -> Result<(), Error> {
tokio::time::delay_for(std::time::Duration::new(1, 0)).await;
loop {
let text = match tokio::process::Command::new("systemctl")
@@ -328,7 +329,8 @@ async fn wait_service_is_active(service: &str) -> Result<(), Error> {
Err(err) => bail!("executing 'systemctl is-active' failed - {}", err),
};
- if text.trim().trim_start() != "reloading" {
+ let is_reload = text.trim().trim_start() == "reloading";
+ if is_reload == wait_for_reload {
return Ok(());
}
tokio::time::delay_for(std::time::Duration::new(5, 0)).await;
--
2.20.1
next reply other threads:[~2020-12-16 8:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 8:12 Dominik Csapak [this message]
2020-12-16 10:21 ` Fabian Ebner
2020-12-16 12:09 ` Fabian Ebner
2020-12-17 12:49 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201216081209.6997-1-d.csapak@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox