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$/;
> }
>
next prev parent 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