search for: reopening

If you can find out whether it's possible with the latest phab, I can update our instance. On Tue, Jun 7, 2016, 9:15 PM Tobias Grosser <tobias at grosser.es> wrote: > On 06/07/2016 09:14 PM, Kuba Brecka via llvm-dev wrote: > > From an unrelated thread: > > > >> ... This will need to be fixed before we can commit the patch. Since > >> Phabricator

We use a custom sh plugin to test retries are working. --- tests/Makefile.am | 8 +++ tests/test-retry-reopen-fail.sh | 108 ++++++++++++++++++++++++++++++++ tests/test-retry.sh | 97 ++++++++++++++++++++++++++++ 3 files changed, 213 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 1b1e05b..af9b9d9 100644 --- a/tests/Makefile.am +++

On 9/19/19 9:33 AM, Richard W.M. Jones wrote: > This is intended for use by the forthcoming retry filter to close and > reopen the backend chain. It is handled entirely by server/backend.c > as no cooperation is needed with the plugin. > > Note the explicit readonly parameter: An alternative would be to store > the previous readonly setting in the b_conn_handle struct. However

I still see the issue below. Is there anyone running separate LMTP logging that could check if they experience the same issue? Best regards Henrik Larsson -------- Original Message -------- Subject: "doveadm log reopen" don't reopen separate lmtp log Date: Sun, 25 Sep 2011 00:23:49 +0200 From: Henrik Larsson <dovecot-user at spambox.dk> To: dovecot at dovecot.org Dear all

On 9/19/19 10:26 AM, Richard W.M. Jones wrote: > We use a custom sh plugin to test retries are working. > --- > tests/Makefile.am | 8 +++ > tests/test-retry-reopen-fail.sh | 108 ++++++++++++++++++++++++++++++++ > tests/test-retry.sh | 97 ++++++++++++++++++++++++++++ > 3 files changed, 213 insertions(+) > > +++

...t;name); > + > + if (h->handle != NULL) > + backend_close (b, conn); > + return backend_open (b, conn, readonly); Do we want to grab a resource lock at this point? Should we be trying hard to prevent further client calls from going to the retry filter while the retry filter is reopening the real plugin? Or do those locks belong in the retry filter itself? If nothing else, we probably want some sort of locking to ensure that two threads are not trying reopen at the same time. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qem...

I think this is my last round of patches for issues I identified with the retry filter. With this in place, it should be safe to interject another filter in between retry and the plugin. Eric Blake (5): retry: Don't call into closed plugin tests: Refactor test-retry-reopen-fail.sh tests: Enhance retry test to cover failed reopen server: Move prepare/finalize/close recursion to

From an unrelated thread: > ... This will need to be fixed before we can commit the patch. Since Phabricator automatically closed http://reviews.llvm.org/D12761 <http://reviews.llvm.org/D12761>, I've created a new revision. The attached diff is a very a slightly modified version of your original patch ... I have wanted to reopen a Phabricator revision too many times already, but

Dear all I have setup separate pop3/imap log "/var/log/dovecot" and lmtp delivery log "/var/log/dovecot-deliver". After rotating logfiles, i run "doveadm log reopen". I see that my pop3/imap log "/var/log/dovecot" is used straight away, but my lmpt log "/var/log/dovecot-deliver" isn't used at first. After some time, usually a few minutes,

v2 was here: https://www.redhat.com/archives/libguestfs/2019-September/msg00221.html I think this is more like "the one". It handles reopen failing correctly, and there is a second test for that. I also ran my sshd tests locally and it worked in all scenarios I could think up (except of course sshd not being available at the start, but we want that to fail). Rich.

I rotate logs every night on my Director, running "doveadm log reopen" I've noticed a problem with processes not closing correctly, they can be open for days and cause corrupt index files because they are connected to different backends (so it writes to the wrong server when the process disconnects) 23518 ? S 140:53 dovecot/anvil [4 connections] 23519 ? S

Hi, I'm adapting the omega (in a Python way ;) to do search across multiple remotes database, for now, I have only one xapian-tcpsrc running, but I have documents being inserted at the same time, so (like I have readed in others e-mails) the xapian-tcpsrc throw the following message: Connection from 192.168.0.101, port 64161 Got exception DatabaseModifiedError: The revision being read has

This is intended for use by the forthcoming retry filter to close and reopen the backend chain. It is handled entirely by server/backend.c as no cooperation is needed with the plugin. Note the explicit readonly parameter: An alternative would be to store the previous readonly setting in the b_conn_handle struct. However passing it explicitly allows the retry filter to retry as readonly, which

This is intended for use by the forthcoming retry filter to close and reopen the backend chain. It is handled entirely by server/backend.c as no cooperation is needed with the plugin. Note the explicit readonly parameter: An alternative would be to store the previous readonly setting in the b_conn_handle struct. However passing it explicitly allows the retry filter to retry as readonly, which

Hi all, Currently I'm implementing a retrieval system with multiple reader processes and only one writer process updating the database periodically. In a reader process, whenever a Xapian::DatabaseModifiedError exception is caught, I call function reopen() and retry. However, my problem is, when there is only a small set of modification, e.g. only one new document is added, the reader would

On 8.7.2019 14.54, Tom Sommer via dovecot wrote: > > On 2019-07-08 13:36, Tom Sommer via dovecot wrote: >> I rotate logs every night on my Director, running "doveadm log reopen" > > It happens on "/etc/init.d/dovecot restart", not "doveadm log reopen" > - sorry > > So it happens when you run killproc on dovecot > > --- > Tom Do

After a retry, if the second connection has fewer permissions than the first, but we blindly call next_ops->FOO, we end up triggering an assertion failure in backend.c. This is particularly noticeable when the force_readonly flag is in effect, as that makes it much easier for there to be fewer permissions than before. Add testsuite coverage of pwrite to demonstrate. Signed-off-by: Eric Blake

Processing commands for control at bugs.debian.org: > unarchive 763102 Bug #763102 {Done: Ian Campbell <ijc at debian.org>} [xen-utils-common] xen-utils-common: xen-init-list fails to parse xm output -> cannot shutdown domains with service xendomains Unarchived Bug 763102 > reopen 763102 Bug #763102 {Done: Ian Campbell <ijc at debian.org>} [xen-utils-common] xen-utils-common:

Has re-opening the logfiles broken between 2.2.32 and 2.2.33 releases? Using the same config that I've had for the past 10 or so point releases, /usr/bin/doveadm log reopen works perfectly up until 2.2.32, but with 2.2.33 (and .1 and .2) no new logfiles are created, file descriptors still have the original files open and keep writings to those logs. On an idling test instance, I get: master:

...gt; References: <1087307353.28637.11.camel@forge.intermeta.de> <200406161051.03808.msmith@xiph.org> Message-ID: <1087392799.7778.4.camel@forge.intermeta.de> Hi, yes, I tested the patch. Then I sent you the wrong version. I attached the correct one. Yes, this one works. Why just reopening the log files and not reloading the configuration? Well, with regular log file rotation, you have a cron job sending this signal to the process once in a while. If an attacker manages to change the configuration, the process will sooner or later reload this changed configuration. If the signal jus...