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 11/19] vzdump: back up guests of a job in parallel
Date: Fri, 6 Nov 2026 15:49:02 +0100	[thread overview]
Message-ID: <5bf543d6-b5c4-4d63-8187-023fd4da159c@proxmox.com> (raw)
In-Reply-To: <20261101225849.884587-12-t.lamprecht@proxmox.com>

Am 02.11.26 um 12:02 AM schrieb Thomas Lamprecht:
> +my sub fork_guest_backup {
> +    my ($self, $task, $running, $interrupted) = @_;
> +
> +    pipe(my $output_reader, my $output_writer) or die "unable to create pipe - $!\n";
> +    pipe(my $result_reader, my $result_writer) or die "unable to create pipe - $!\n";
> +    pipe(my $start_reader, my $start_writer) or die "unable to create pipe - $!\n";
> +
> +    # Until the child set up its own handlers, a signal would only reach the inherited one of the
> +    # job process and get lost.
> +    my $signals = POSIX::SigSet->new(
> +        POSIX::SIGINT(),
> +        POSIX::SIGTERM(),
> +        POSIX::SIGQUIT(),
> +        POSIX::SIGHUP(),
> +        POSIX::SIGPIPE(),
> +    );
> +    my $old_mask = POSIX::SigSet->new();
> +    POSIX::sigprocmask(POSIX::SIG_BLOCK(), $signals, $old_mask)
> +        or die "unable to block signals - $!\n";
> +
> +    my $pid = fork();
> +    if (!defined($pid)) {
> +        my $err = $!;
> +        POSIX::sigprocmask(POSIX::SIG_SETMASK(), $old_mask);
> +        die "unable to fork guest backup - $err\n";
> +    }
> +
> +    if (!$pid) {
> +        my $interrupted = 0;
> +        $SIG{INT} = $SIG{TERM} = $SIG{QUIT} = $SIG{HUP} = $SIG{PIPE} = sub {
> +            # a second signal must not abort the cleanup the first one started
> +            die "interrupted by signal\n" if !$interrupted++;
> +        };
> +
> +        my $exitcode = 1;
> +        eval {
> +            POSIX::sigprocmask(POSIX::SIG_SETMASK(), $old_mask);
> +            close($output_reader);
> +            close($result_reader);
> +            close($start_writer);
> +            # only the job process reads the output of the other guest backups
> +            for my $sibling (values $running->%*) {
> +                close($_) for grep { defined } $sibling->@{qw(output result)};
> +            }
> +            open(STDOUT, '>&', $output_writer) or die "unable to redirect STDOUT - $!\n";
> +            open(STDERR, '>&', $output_writer) or die "unable to redirect STDERR - $!\n";
> +            close($output_writer);
> +
> +            sysread($start_reader, my $start, 1) or die "interrupted by signal\n";

Could maybe warrant a short comment why this error message is used here.
See also my next comment below.

> +            close($start_reader);
> +
> +            PVE::INotify::inotify_close();
> +
> +            eval { $self->exec_backup_task($task) };
> +            my $err = $@;
> +
> +            my $result = { map { $_ => $task->{$_} } $guest_result_keys->@* };
> +            print $result_writer Storable::nfreeze($result);
> +            close($result_writer);
> +
> +            die $err if $err;
> +            $exitcode = 0;
> +        };
> +        warn $@ if $@ && $@ !~ m/^interrupted by signal$/;
> +        STDOUT->flush();
> +        POSIX::_exit($exitcode);
> +    }
> +
> +    POSIX::sigprocmask(POSIX::SIG_SETMASK(), $old_mask);
> +
> +    close($output_writer);
> +    close($result_writer);
> +    close($start_reader);
> +
> +    # A stop request that came in while forking reached only the job process, so the backup
> +    # process must not start then.
> +    my $cancelled = $$interrupted;
> +    if (!$cancelled) {
> +        local $SIG{PIPE} = 'IGNORE';
> +        syswrite($start_writer, '1');
> +    }

Should we send a different message if cancelled? Then we could
distinguish other failure from that above.

> +    close($start_writer);
> +
> +    return {
> +        pid => $pid,
> +        cancelled => $cancelled,
> +        task => $task,
> +        output => $output_reader,
> +        result => $result_reader,
> +        'output-buffer' => '',
> +        'result-data' => '',
> +    };
> +}
> +
> +my sub forward_guest_output {
> +    my ($child, $data, $final) = @_;
> +
> +    my $vmid = $child->{task}->{vmid};
> +
> +    $child->{'output-buffer'} .= $data;
> +    $child->{'output-buffer'} .= "\n" if $final && length($child->{'output-buffer'});
> +
> +    while ($child->{'output-buffer'} =~ s/^(.*)\n//) {
> +        my $line = $1;
> +        # warnings of a guest backup process count for the task, but its counter ends with it
> +        PVE::RPCEnvironment::get()->{warning_count}++ if $line =~ m/^WARN: /;
> +        print STDERR "$vmid: $line\n";
> +    }
> +}
> +
> +my sub read_guest_backup_pipe {
> +    my ($child, $kind) = @_;
> +
> +    my $count = sysread($child->{$kind}, my $data, 64 * 1024);
> +    return if !defined($count) && ($!{EINTR} || $!{EAGAIN});
> +
> +    if (!$count) {
> +        close(delete $child->{$kind});
> +        forward_guest_output($child, '', 1) if $kind eq 'output';
> +    } elsif ($kind eq 'output') {
> +        forward_guest_output($child, $data);
> +    } else {
> +        $child->{'result-data'} .= $data;
> +    }
> +}
> +
> +my sub finish_guest_backup {
> +    my ($child, $status) = @_;
> +
> +    # the backup process is gone, but helpers it started might still hold the output pipe
> +    for my $kind (qw(result output)) {
> +        while ($child->{$kind} && IO::Select->new($child->{$kind})->can_read(0)) {
> +            read_guest_backup_pipe($child, $kind);
> +        }
> +        close(delete $child->{$kind}) if $child->{$kind};
> +    }
> +    forward_guest_output($child, '', 1);

This might be a second call to forward_guest_output() with $final=1 if
it was called by read_guest_backup_pipe() already. Should be guarded by
checking $child->{output}, or?

> +    return if $child->{cancelled};
> +
> +    my $task = $child->{task};
> +    my $result = eval { Storable::thaw($child->{'result-data'}) };
> +    if (ref($result) eq 'HASH') {
> +        $task->{$_} = $result->{$_} for keys $result->%*;
> +    } else {

Might be better as a separate "if ($status != 0)" instead of an else?

> +        my $reason = $status & 127 ? "signal " . ($status & 127) : "exit code " . ($status >> 8);
> +        fail_task($task, "backup process ended unexpectedly ($reason)");
> +    }
> +}
> +




  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
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 [this message]
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=5bf543d6-b5c4-4d63-8187-023fd4da159c@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