public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] tools/daemon: improve reload behaviour
Date: Thu, 17 Dec 2020 13:49:46 +0100	[thread overview]
Message-ID: <5d0ab7cb-0a77-5a10-d8a4-fc7a916dfdf9@proxmox.com> (raw)
In-Reply-To: <20201216081209.6997-1-d.csapak@proxmox.com>

On 16/12/2020 09:12, Dominik Csapak wrote:
> 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 {

hmm, this feels and reads a bit weird, "wait_for_reload" false meaning
"wait for any status that is not reloading" seems subtle.

Combined with the name of the function this implies passing true means
that it will be waited until the service is active *or* reloading, and 
passing false implies its just waited until active.

Can you rethink the interface here, maybe split it (I'm a bit buried in
other work for more useful thoughts/proposal - sorry).

>              return Ok(());
>          }
>          tokio::time::delay_for(std::time::Duration::new(5, 0)).await;
> 





      parent reply	other threads:[~2020-12-17 12:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-16  8:12 Dominik Csapak
2020-12-16 10:21 ` Fabian Ebner
2020-12-16 12:09   ` Fabian Ebner
2020-12-17 12:49 ` Thomas Lamprecht [this message]

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=5d0ab7cb-0a77-5a10-d8a4-fc7a916dfdf9@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal