public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH manager 06/19] vzdump: notification: capture guest logs right after each backup
Date: Fri, 6 Nov 2026 15:49:03 +0100	[thread overview]
Message-ID: <d952d4dc-a710-45fc-a9ff-7adbf5a915ac@proxmox.com> (raw)
In-Reply-To: <20261101225849.884587-7-t.lamprecht@proxmox.com>

Am 01.11.26 um 11:59 PM schrieb Thomas Lamprecht:
> The log of a guest backup is written to a path derived from the guest
> alone and was only read back when sending the notification at the end
> of the job. This relies on no other backup of the guest starting in the
> meantime, which no longer holds once backup jobs can run alongside each
> other.
> 
> Read the log as the last step of each guest backup instead. Logs
> longer than the notification size limit are cut, as they would not be
> included anyway.
> 
> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> ---
>  PVE/VZDump.pm | 27 +++++++++++++++++++--------
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
> index defe9e0a5..d07ced61b 100644
> --- a/PVE/VZDump.pm
> +++ b/PVE/VZDump.pm
> @@ -368,24 +368,35 @@ sub read_vzdump_defaults {
>      return $res;
>  }
>  
> -my sub read_backup_task_logs {
> +use constant MAX_LOG_SIZE => 1024 * 1024;
> +
> +my sub read_guest_log {
> +    my ($path) = @_;
> +
> +    open(my $fh, '<', $path) or return undef;

Nit: should we log/capture the error code?

> +    my $log = '';
> +    read($fh, $log, MAX_LOG_SIZE + 1); # anything longer is not sent anyway
> +    close($fh);
> +
> +    return $log;
> +}
> +
> +my sub format_backup_task_logs {
>      my ($task_list) = @_;
>  
>      my $task_logs = "";
>  
>      for my $task (@$task_list) {
>          my $vmid = $task->{vmid};
> -        my $log_file = $task->{tmplog};
>          if (!$task->{tmplog}) {
>              $task_logs .= "$vmid: no log available\n\n";
>              next;
>          }
> -        if (open(my $TMP, '<', "$log_file")) {
> -            while (my $line = <$TMP>) {
> +        if (defined(my $log = $task->{log})) {
> +            for my $line (split(/^/m, $log)) {
>                  next if $line =~ /^status: \d+/; # not useful in mails
>                  $task_logs .= encode8bit("$vmid: $line");
>              }
> -            close($TMP);
>          } else {
>              $task_logs .= "$vmid: Could not open log file\n\n";
>          }
> @@ -484,8 +495,6 @@ my sub get_hostname {
>      return $hostname;
>  }
>  
> -use constant MAX_LOG_SIZE => 1024 * 1024;
> -
>  sub send_notification {
>      my ($self, $tasklist, $total_time, $err, $detail_pre, $detail_post) = @_;
>  
> @@ -514,7 +523,7 @@ sub send_notification {
>  
>      my $text_log_part = "$cmdline\n\n";
>      $text_log_part .= $detail_pre . "\n" if defined($detail_pre);
> -    $text_log_part .= read_backup_task_logs($tasklist);
> +    $text_log_part .= format_backup_task_logs($tasklist);
>      $text_log_part .= $detail_post if defined($detail_post);
>  
>      if (length($text_log_part) > MAX_LOG_SIZE) {
> @@ -1385,6 +1394,8 @@ sub exec_backup_task {
>      eval { $self->run_hook_script('log-end', $task); };
>      debugmsg('warn', $@) if $@; # message already contains command with phase name
>  
> +    $task->{log} = read_guest_log($task->{tmplog}) if $task->{tmplog};

Nit: we could unlink $task->{tmplog} here after reading, and maybe even
drop it from the hash since we are not supposed to access it afterwards
anymore. Of course then the check for $task->{tmplog} in
format_backup_task_logs() would need to be dropped too. We could put
"$vmid: no log available\n\n" in $task->{log} at the beginning of the
task, so we end up with that message if it never is replaced.

> +
>      die $err if $err && $err =~ m/^interrupted by signal$/;
>  }
>  





  reply	other threads:[~2026-11-06 14:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-01 22:58 [PATCH cluster,storage,guest-common,container,manager,docs 00/19] parallel guest backups and backup concurrency limits Thomas Lamprecht
2026-11-01 22:58 ` [PATCH cluster 01/19] datacenter config: add backup concurrency setting Thomas Lamprecht
2026-11-01 22:58 ` [PATCH cluster 02/19] datacenter config: backup concurrency: add cluster-wide limit Thomas Lamprecht
2026-11-01 22:58 ` [PATCH storage 03/19] add backup concurrency option to storages Thomas Lamprecht
2026-11-01 22:58 ` [PATCH guest-common 04/19] vzdump: add options for parallel guest backups and overlapping jobs Thomas Lamprecht
2026-11-01 22:58 ` [PATCH container 05/19] vzdump: honor bandwidth limit for backups to Proxmox Backup Server Thomas Lamprecht
2026-11-06 10:28   ` applied: " Fiona Ebner
2026-11-01 22:58 ` [PATCH manager 06/19] vzdump: notification: capture guest logs right after each backup Thomas Lamprecht
2026-11-06 14:49   ` Fiona Ebner [this message]
2026-11-01 22:58 ` [PATCH manager 07/19] vzdump: stop all running backup jobs of the node Thomas Lamprecht
2026-11-06 14:48   ` Fiona Ebner
2026-11-01 22:58 ` [PATCH manager 08/19] vzdump: show the error if a job could not get the global lock Thomas Lamprecht
2026-11-01 22:58 ` [PATCH manager 09/19] vzdump: run job-init hook and set up target once the job may start Thomas Lamprecht
2026-11-06 14:48   ` Fiona Ebner
2026-11-01 22:58 ` [PATCH manager 10/19] vzdump: list guests as skipped if the job could not start Thomas Lamprecht
2026-11-01 22:58 ` [PATCH manager 11/19] vzdump: back up guests of a job in parallel Thomas Lamprecht
2026-11-06 14:49   ` Fiona Ebner
2026-11-01 22:58 ` [PATCH manager 12/19] vzdump: allow jobs to run alongside each other Thomas Lamprecht
2026-11-06 14:49   ` Fiona Ebner
2026-11-01 22:58 ` [PATCH manager 13/19] ui: options: add backup concurrency for datacenter and nodes Thomas Lamprecht
2026-11-01 22:58 ` [PATCH manager 14/19] ui: backup job: add concurrency and overlap options Thomas Lamprecht
2026-11-01 22:58 ` [PATCH manager 15/19] vzdump: limit concurrent guest backups cluster-wide Thomas Lamprecht
2026-11-06 14:49   ` Fiona Ebner
2026-11-01 22:58 ` [PATCH manager 16/19] vzdump: honor backup concurrency limits of storages Thomas Lamprecht
2026-11-01 22:58 ` [PATCH manager 17/19] api: backup info: add endpoints for cluster-wide backup slots Thomas Lamprecht
2026-11-01 22:58 ` [PATCH manager 18/19] ui: add cluster-wide and storage backup concurrency limits Thomas Lamprecht
2026-11-01 22:58 ` [PATCH docs 19/19] vzdump: document concurrent backups and their limits 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=d952d4dc-a710-45fc-a9ff-7adbf5a915ac@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@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