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: [pbs-devel] applied: [PATCH proxmox-backup] rest-server/daemon: use sd_notify_barrier for service reloading
Date: Sat, 2 Oct 2021 11:52:53 +0200	[thread overview]
Message-ID: <b428a10b-717b-92fe-d648-b2fecee0476e@proxmox.com> (raw)
In-Reply-To: <20210930071858.1116527-1-d.csapak@proxmox.com>

On 30.09.21 09:18, Dominik Csapak wrote:
> until now, we manually polled the systemd service state during a reload
> so that the sd_notify messages get processed in the correct order
> (RELOAD(old) -> MAINPID(old) -> READY(new))
> 
> with systemd >= 246 there is now 'sd_notify_barrier' which
> blocks until systemd processed all prior messages
> 
> with that change, the daemon does not need to know the service name anymore
> 
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
>  debian/control                                |  2 +-
>  .../examples/minimal-rest-server.rs           |  1 -
>  proxmox-rest-server/src/daemon.rs             | 61 +++++++------------
>  src/bin/proxmox-backup-api.rs                 |  1 -
>  src/bin/proxmox-backup-proxy.rs               |  1 -
>  5 files changed, 22 insertions(+), 44 deletions(-)
> 

applied, thanks! made a few followups, see inline.

> @@ -248,7 +251,6 @@ impl Reloadable for tokio::net::TcpListener {
>  pub async fn create_daemon<F, S>(
>      address: std::net::SocketAddr,
>      create_service: F,
> -    service_name: &str,
>  ) -> Result<(), Error>
>  where
>      F: FnOnce(tokio::net::TcpListener) -> Result<S, Error>,
> @@ -289,7 +291,10 @@ where
>          if let Err(e) = systemd_notify(SystemdNotify::Reloading) {
>              log::error!("failed to notify systemd about the state change: {}", e);
>          }
> -        wait_service_is_state(service_name, "reloading").await?;

I added a comment here to actually give an answer to why-reason.

> +        if let Err(e) = systemd_notify_barrier() {
> +            log::error!("failed to wait on systemd-processing: {}", e);
> +        }
> +
>          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()));


>  #[link(name = "systemd")]
>  extern "C" {
>      fn sd_notify(unset_environment: c_int, state: *const c_char) -> c_int;
> +    fn sd_notify_barrier(unset_environment: c_int, timeout: u64) -> c_int;
>  }
>  
>  /// Systemd sercice startup states (see: ``man sd_notify``)
> @@ -358,6 +326,19 @@ pub enum SystemdNotify {
>      MainPid(nix::unistd::Pid),
>  }
>  
> +/// Waits until all previously sent messages with sd_notify are processed
> +pub fn systemd_notify_barrier() -> Result<(), Error> {
> +    let rc = unsafe { sd_notify_barrier(0, u64::MAX) }; // infinite timeout

I exposed the timeout to the caller, making it act more like the thin FFI wrapper
it is.

> +    if rc < 0 {
> +        bail!(
> +            "systemd_notify_barrier failed: {}",
> +            std::io::Error::from_raw_os_error(-rc),
> +        );
> +    }
> +
> +    Ok(())
> +}
> +

this was barging in between the SystemdNotify enum that is explicitly for, well
systemd_notify below, while not using that itself -> so I moved it out of the way.

>  /// Tells systemd the startup state of the service (see: ``man sd_notify``)
>  pub fn systemd_notify(state: SystemdNotify) -> Result<(), Error> {
>  





      parent reply	other threads:[~2021-10-02  9:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  7:18 [pbs-devel] " Dominik Csapak
2021-09-30  8:19 ` Thomas Lamprecht
2021-10-02  9:52 ` 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=b428a10b-717b-92fe-d648-b2fecee0476e@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