Re: replication timeout

2024-03-28 Thread Andy Balholm

I'm not using any scheduler.
It's just being activated by the standard replication-notify mechanism 
in Dovecot.


Andy

On Thursday, March 28, 2024 12:56:18 AM PDT, Aki Tuomi wrote:

Hi!

We received some more information to this. Are you by chance 
running these from some scheduler? It seems that if dovecot is 
logging, some schedulers can actually start blocking on log 
writes to stdout/stderr, which can lead to this problem.


I wonder if this could be the case for you?

Aki


On 21/01/2024 17:36 EET Aki Tuomi via dovecot  wrote:

 
Can you try with doveadm -D and send the log?


Aki
 ...





___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Re[4]: panics

2024-03-28 Thread Michael Grant via dovecot

 >Am 27.03.24 um 18:49 schrieb Michael Grant via dovecot:
 >>I could really use some help debugging issue.
 >
 >Timo gave some debugging tips in a similar case cf.
 >https://dovecot.org/pipermail/dovecot/2023-March/126229.html
 >
 >In case you know how to use gdb, that should work and might get a reproducer 
so this error can be mended for everybody.

 This was helpful thanks.  I do know how to use gdb, but hoping it won't
 come to this.  I was thinking of how to do that anyway.  There must be
 way to start dovecot (in gdb) so it does not fork and runs on a
 non-standard port so I could configure the imap client to contact it on,
 for example, port 1993.  If someone knows how to do that, let me know.


gdb /usr/lib/dovecot/imap
r -u username

I tried what you said above.  It seems to start IMAP running on stdin 
connected to my username.


It's not clear to me how to debug this like that.  Any recommendation?

In the client, I can easily set a different port like 1993.  What I was 
imagining was to start dovecot (or imap?) in gdb then connect with the 
client, authenticate as myself, let it sync up it's folders, and then 
watch the crash and poke around and try to print out the message and 
folder.


Would it be easy for you to maybe print out the message and folder in 
the assertion that is failing?  Maybe this is easier for me to recompile 
dovecot with that instead of trying to get into debug in the correct 
child and all?

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Re: SAVEDATE is using ctime instead of btime for Maildir

2024-03-28 Thread Timo Sirainen
On 19. Mar 2024, at 0.43, Alex via dovecot  wrote:
> 
> Dovecot supports SAVEDATE IMAP extension [1].
> This is however not implemented correctly for Maildir storage.
> 
> Compared to "internal date", "save date" is supposed to be the same
> but well-defined for APPEND and preserved when COPY command is used.
> 
> However, for Maildir storage INTERNALDATE is implemented
> using mtime (modification timestamp)
> and SAVEDATE is implemented using ctime (status change timestamp) [2].
> ctime is changed even more often than mtime.
> For example, chown or chmod operations on the message change its
> ctime, but preserve its mtime.
> 
> Dovecot should instead use btime (creation timestamp) when it is available
> and not implement SAVEDATE at all if there is no btime.

ctime is not perfect, but I don't think it's completely unusable either. 
Normally mail files aren't being chmod/chowned. More troublesome is that 
message flag changes result in renaming the file, which changes ctime. Also it 
rather depends on what the SAVEDATE is used for whether this is a problem or 
not. The main reason SAVEDATE exists is for Dovecot to implement mailbox { 
autoexpunge } setting so mails moved to Trash can be deleted N days after they 
were moved there. For this purpose the current implementation is okay enough.

In any case btime would not be correct, since it would not change when 
copying/moving mail between folders. That is its most important purpose.

I guess we could hide the SAVEDATE capability if none of the configured mailbox 
formats support it perfectly.

> You can read more in the issue [3] where we have problems with incorrect 
> INTERNALDATE
> and investigated the possibility of using SAVEDATE, but found that it is not 
> implemented correctly
> and is changed even more often than INTERNALDATE. According to the standard 
> it should be the other way round,
> SAVEDATE should be more stable and survive COPY.

I don't see why you say it should be more stable. INTERNALDATE is entirely 
stable and never changes once mail is saved, as long as someone doesn't go 
poking the mails directly in the filesystem. SAVEDATE always changes on 
COPY/MOVE.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Re: Post-Auth external check?

2024-03-28 Thread Aki Tuomi via dovecot
Sounds like

https://doc.dovecot.org/configuration_manual/authentication/auth_policy/

Aki

> On 28/03/2024 10:19 EET Stephan von Krawczynski  wrote:
> 
>  
> Hello all,
> 
> is it possible to include some post-auth check in the password authentication?
> So after dovecot has found a user allowed to login to execute some external
> script for checking additional conditions which gives back simple true or
> false wether the login should be allowed?
> 
> -- 
> Regards,
> Stephan
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Re: Post-Auth external check?

2024-03-28 Thread Thomas Mechtersheimer
On Thu, Mar 28, 2024 at 09:19:56AM +0100, Stephan von Krawczynski wrote:
> is it possible to include some post-auth check in the password authentication?
> So after dovecot has found a user allowed to login to execute some external
> script for checking additional conditions which gives back simple true or
> false wether the login should be allowed?

Have a look at  https://doc.dovecot.org/admin_manual/post_login_scripting/
There is an example for denying a connection in an external script.

-- 
Thomas Mechtersheimer - Necklenbroicher Str. 45a - D-40667 Meerbusch - Germany
EMail: thom...@wupper.com IRC-Nick: Mechti
  Of course I'm crazy, but that doesn't mean I'm wrong. I'm mad but not ill.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Post-Auth external check?

2024-03-28 Thread Stephan von Krawczynski
Hello all,

is it possible to include some post-auth check in the password authentication?
So after dovecot has found a user allowed to login to execute some external
script for checking additional conditions which gives back simple true or
false wether the login should be allowed?

-- 
Regards,
Stephan
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Re: replication timeout

2024-03-28 Thread Aki Tuomi via dovecot
Hi!

We received some more information to this. Are you by chance running these from 
some scheduler? It seems that if dovecot is logging, some schedulers can 
actually start blocking on log writes to stdout/stderr, which can lead to this 
problem.

I wonder if this could be the case for you?

Aki

> On 21/01/2024 17:36 EET Aki Tuomi via dovecot  wrote:
> 
>  
> Can you try with doveadm -D and send the log?
> 
> Aki
> 
> > On 20/01/2024 19:51 EET Andy Balholm  wrote:
> > 
> >  
> > I forgot to mention in my original message that I'm running Dovecot
> > 2.3.21 (47349e2482).
> > 
> > It seems like the stalls are more likely to happen
> > when the type of sync is "incremental" rather than
> > "normal" or "full".
> > (I'm inclined to think they only happen for incremental syncs,
> > but I'm not sure.)
> > 
> > Andy
> > 
> > 
> > On Friday, January 19, 2024 9:26:29 AM PST, Andy Balholm wrote:
> > > I have two Dovecot mail servers that replicate to each other.
> > > Sometimes there are delays in the synchronization,
> > > and I notice that the mail log has entries like this:
> > >
> > > Error: dsync(spokane): I/O has stalled, no activity for 600 
> > > seconds (last sent=mailbox, last recv=mailbox_state)
> > >
> > > Five minutes seems like a long time to sit there waiting with 
> > > nothing happening.
> > > Is there a way to reduce this timeout so that I don't have so many
> > > replicaton connections just sitting around doing nothing?
> > >
> > > (Of course, a way to prevent the I/O stalls would be great too,
> > > but with my limited upload bandwidth, they may be unavoidable.)
> > >
> > > Andy
> > >
> > 
> > ___
> > dovecot mailing list -- dovecot@dovecot.org
> > To unsubscribe send an email to dovecot-le...@dovecot.org
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org