Signed-off-by: Stoiko Ivanov
---
PVE/APIServer/AnyEvent.pm | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
index 0165264..9a4b7e7 100644
--- a/PVE/APIServer/AnyEvent.pm
+++ b/PVE/APIServer/AnyEvent.
if an error happens before AnyEvent::Handle registers the cleanup
callback, we should shutdown the socket, when handling it.
Co-Authored-by: Dominik Csapak
Signed-off-by: Stoiko Ivanov
---
PVE/APIServer/AnyEvent.pm | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff
Signed-off-by: Stoiko Ivanov
---
PVE/APIServer/AnyEvent.pm | 4
1 file changed, 4 insertions(+)
diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
index a679006..0165264 100644
--- a/PVE/APIServer/AnyEvent.pm
+++ b/PVE/APIServer/AnyEvent.pm
@@ -1547,6 +1547,7 @@ sub check_ho
v1->v2:
* increment of connection count now happens right before the AnyEvent::Handle
is created
* the handle-creation is guarded by an error-flag, and if it fails the
connection count is decremented (bounded to 0) again
* as suggested by Thomas - added a debug print sub which includes the
pa
Suggested-by: Thomas Lamprecht
Signed-off-by: Stoiko Ivanov
---
PVE/APIServer/AnyEvent.pm | 10 ++
1 file changed, 10 insertions(+)
diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
index c55da7f..7916bdd 100644
--- a/PVE/APIServer/AnyEvent.pm
+++ b/PVE/APIServer/AnyEve
When handling new connections in 'accept_connections' the number of
active connections got increased before the AnyEvent::Handle
registered the callback which would decrement it on error/eof.
Any error/die beforehand would skip the decrement, and leave the
process in an endless loop upon exiting i
I'm looking for some help on how to get it running and how to make it
reproducible :)
On Fri, Dec 4, 2020 at 4:21 PM Kamil Trzciński wrote:
> ARM64 is becoming increasingly popular, especially that PBS seems at least
> for my usage-pattern to be ideal to run on my arm64 NAS. In the end
> I want
ARM64 is becoming increasingly popular, especially that PBS seems at least
for my usage-pattern to be ideal to run on my arm64 NAS. In the end
I want to try to be able to recompile everything for arm64 and see how
nicely
it works there.
But first I decided to try to compile all packages for `amd64
On 04.12.20 12:57, Thomas Lamprecht wrote:
> On 04.12.20 12:30, Dominik Csapak wrote:
>> On 12/3/20 10:05 AM, Thomas Lamprecht wrote:
>>> On 02.12.20 10:21, Dominik Csapak wrote:
like we do in other apis of section configs (e.g. storage)
Signed-off-by: Dominik Csapak
---
On 04.12.20 12:30, Dominik Csapak wrote:
> On 12/3/20 10:05 AM, Thomas Lamprecht wrote:
>> On 02.12.20 10:21, Dominik Csapak wrote:
>>> like we do in other apis of section configs (e.g. storage)
>>>
>>> Signed-off-by: Dominik Csapak
>>> ---
>>> PVE/API2/Cluster/MetricServer.pm | 2 ++
>>> 1 fil
On 12/3/20 10:05 AM, Thomas Lamprecht wrote:
On 02.12.20 10:21, Dominik Csapak wrote:
like we do in other apis of section configs (e.g. storage)
Signed-off-by: Dominik Csapak
---
PVE/API2/Cluster/MetricServer.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/API2/Cluster/MetricSe
Signed-off-by: Fabian Ebner
---
PVE/VZDump.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
index 2e44908a..6a4e641b 100644
--- a/PVE/VZDump.pm
+++ b/PVE/VZDump.pm
@@ -75,7 +75,7 @@ my $parse_prune_backups_maxfiles = sub {
my $maxfiles = de
and prefer storage, because the storage configuration might contain more
settings. Warning is preferable over dying, because all backups would be
affected (even if they don't use the vzdump.conf parameters) and the settings
could've been compatible (i.e. dumpdir being the storage's dump dir). Previ
13 matches
Mail list logo
