Re: stats-writer error is back
I do believe that imap reader processes write stats as the *USER*. On Sat, Apr 20, 2019 at 3:41 PM @lbutlr via dovecot wrote: > On 20 Apr 2019, at 14:21, Larry Rosenman via dovecot > wrote: > > Then figure out what user/group needs the access and set the perms. > > Well, stats-write has an owner and group of dovecot, as I showed. > > dovecot dovecot 0 Apr 20 04:34 /var/run/dovecot/stats-writer > > > -- > 'I thought dwarfs didn't believe in devils and demons and stuff like > that.' 'That's true, but... we're not sure if they know.' > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larry...@gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: stats-writer error is back
On 20 Apr 2019, at 14:21, Larry Rosenman via dovecot wrote: > Then figure out what user/group needs the access and set the perms. Well, stats-write has an owner and group of dovecot, as I showed. dovecot dovecot 0 Apr 20 04:34 /var/run/dovecot/stats-writer -- 'I thought dwarfs didn't believe in devils and demons and stuff like that.' 'That's true, but... we're not sure if they know.'
Re: stats-writer error is back
Then figure out what user/group needs the access and set the perms. I can't help you other than what I've shown you. (my box doesn't have foreign users on it, so this was the most espedient route for me). On Sat, Apr 20, 2019 at 3:16 PM @lbutlr via dovecot wrote: > On 20 Apr 2019, at 14:05, Larry Rosenman via dovecot > wrote: > > service stats { > > unix_listener stats-reader { > > group = mail > > Why would I change the group from the group the socket is using? > > > mode = 0666 > > That cannot possibly be best practice. > > I'm not opening up any part of my mail stack to all processes. > > >> # ls -ls /var/run/dovecot/stats-writer > >> 0 srw-rw 1 dovecot dovecot 0 Apr 20 04:34 > /var/run/dovecot/stats-writer > > > -- > Please to meet you, Rose. Now run for your life! > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larry...@gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: stats-writer error is back
On 20 Apr 2019, at 14:05, Larry Rosenman via dovecot wrote: > service stats { > unix_listener stats-reader { > group = mail Why would I change the group from the group the socket is using? > mode = 0666 That cannot possibly be best practice. I'm not opening up any part of my mail stack to all processes. >> # ls -ls /var/run/dovecot/stats-writer >> 0 srw-rw 1 dovecot dovecot 0 Apr 20 04:34 >> /var/run/dovecot/stats-writer -- Please to meet you, Rose. Now run for your life!
Re: stats-writer error is back
service stats { unix_listener stats-reader { group = mail mode = 0666 user = } unix_listener stats-writer { group = mail mode = 0666 user = } } service anvil { unix_listener anvil { group = mail mode = 0666 } } in my local.conf. Maybe a resend (sorry for the dupe if it is) On Sat, Apr 20, 2019 at 2:46 PM @lbutlr via dovecot wrote: > Afer a reboot (and installation of postfix-3.4.5) I am getting the > stat-writer permission denied error again. > > from doveconf -n > > service stats { > unix_listener stats-reader { >user = dovecot > } > unix_listener stats-writer { >user = dovecot > } > } > > # ls -ls /var/run/dovecot/stats-writer > 0 srw-rw 1 dovecot dovecot 0 Apr 20 04:34 > /var/run/dovecot/stats-writer > > Apr 20 04:45:00 mail postfix/pipe[80136]: 44mTxm3Mblzc3Td: to=, > relay=dovecot, delay=0.06, delays=0.02/0.02/0/0.02, dsn=2.0.0, status=sent > (delivered via dovecot service (lda(,munged,)Error: > net_connect_unix(/var/run/dovecot/stats-writer) failed: Permiss)) > > > -- > W is for WINNIE embedded in ice > X is for XERXES devoured by mice > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larry...@gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: stats-writer error is back
service stats { unix_listener stats-reader { group = mail mode = 0666 user = } unix_listener stats-writer { group = mail mode = 0666 user = } } service anvil { unix_listener anvil { group = mail mode = 0666 } } in my local.conf. On Sat, Apr 20, 2019 at 2:46 PM @lbutlr via dovecot wrote: > Afer a reboot (and installation of postfix-3.4.5) I am getting the > stat-writer permission denied error again. > > from doveconf -n > > service stats { > unix_listener stats-reader { >user = dovecot > } > unix_listener stats-writer { >user = dovecot > } > } > > # ls -ls /var/run/dovecot/stats-writer > 0 srw-rw 1 dovecot dovecot 0 Apr 20 04:34 > /var/run/dovecot/stats-writer > > Apr 20 04:45:00 mail postfix/pipe[80136]: 44mTxm3Mblzc3Td: to=, > relay=dovecot, delay=0.06, delays=0.02/0.02/0/0.02, dsn=2.0.0, status=sent > (delivered via dovecot service (lda(,munged,)Error: > net_connect_unix(/var/run/dovecot/stats-writer) failed: Permiss)) > > > -- > W is for WINNIE embedded in ice > X is for XERXES devoured by mice > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larry...@gmail.com US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
stats-writer error is back
Afer a reboot (and installation of postfix-3.4.5) I am getting the stat-writer permission denied error again. from doveconf -n service stats { unix_listener stats-reader { user = dovecot } unix_listener stats-writer { user = dovecot } } # ls -ls /var/run/dovecot/stats-writer 0 srw-rw 1 dovecot dovecot 0 Apr 20 04:34 /var/run/dovecot/stats-writer Apr 20 04:45:00 mail postfix/pipe[80136]: 44mTxm3Mblzc3Td: to=, relay=dovecot, delay=0.06, delays=0.02/0.02/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service (lda(,munged,)Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permiss)) -- W is for WINNIE embedded in ice X is for XERXES devoured by mice
Re: FTS delays
I have no idea how to use git-bitsec On 2019-04-15 15:31, Josef 'Jeff' Sipek wrote: On Sun, Apr 14, 2019 at 21:09:54 +0800, Joan Moreau wrote: ... THe "loop" part seems the most urgent : It breaks everything (search timeout 100% of the time) Any luck with git-bisect? Jeff. On 2019-04-06 09:56, Joan Moreau via dovecot wrote: For the point 1, this is not "suboptimal", it is plain wrong (results are damn wrong ! and this is not related to the backend, but the FTS logic in Dovecot core) For the point 2 , this has been discussed already numerous times but without action. The dovecot core shall be the one re-submitting the emails to scan, not the backend to try to figure out where and which are the emails to be re-scaned For the point 3, I will do a bit of research in the existing code and will get back to you For the point 4, this is random. FTS backend (xapian, lucene, solr, whatever..) returns X, then dovecot core choose to select only Y emails. THis is a clear bug. On 2019-04-05 20:08, Josef 'Jeff' Sipek via dovecot wrote: On Fri, Apr 05, 2019 at 19:33:57 +0800, Joan Moreau via dovecot wrote: Hi If you plan to fix the FTS part of Dovecot, I will be very gratefull. I'm trying to figure out what is causing the 3rd issue you listed, so we can decide how severe it is and therefore how quickly it needs to be fixed. At the moment we are unable to reproduce it, and therefore we cannot fix it. Not sure this is related to any specific commit but rahter the overall design Ok. The list of bugs so far 1 - Double call to fts plugins with inconsistent parameter (first call diferent from second call for the same request) Understood. It is my understanding that this is simply suboptimal rather than causing crashes/etc. 2 - "Rescan" features for now consists of deleting indexes. SHall be resending emails to rescan to the fts plugin instead I'm not sure I follow. The rescan operation is invoked on the fts backend and it is up to the implementation to somehow ensure that after it is done the fts index is up to date. The easiest way to implement it is to simply delete the fts index and re-index all the mails. That is what currently happens in the solr backend. The lucene fts backend does a more complicated matching of the fts index with the emails. Finally, the deprecated squat backend seem to ignore the rescan requests (its rescan vfunc is NULL). 3 - the loop when body search (just do a "doveadm search -u user@domain mailbox inbox text whatevertexte") Refer to my email to Timo on 2019-04-03 18:30 on the same thread for bug details (especially the loop) This seems to be the most important of the 4 issues you listed, so I'd like to focus on this one for now. As I mentioned, we cannot reproduce this ourselves. So, we need your help to narrow things down. Therefore, can you give us the commit hashes of revisions that you know are good and which are bad? You can use git-bisect to narrow the range down. 4 - Most notably, I notice that header search usually does not care about fts plugin (even with fts_enforced) and rely on some internal search , which si total non-sense You're right, that doesn't seem to make sense. Can you provide a test case? Jeff. Let me know how can I help on thos 4 points On 2019-04-05 18:37, Josef 'Jeff' Sipek wrote: On Fri, Apr 05, 2019 at 17:45:36 +0800, Joan Moreau wrote: I am on master (very latest) No clue exactly when this problem appears, but 1 - the "request twice the fts plugin instead of once" issue has always been there (since my first RC release of fts-xapian) Ok, good to know. 2 - the body/text loop has appeared recently (maybe during the month of March) Our testing doesn't seem to be able to reproduce this. Can you try to git-bisect this to find which commit broke it? Thanks, Jeff. On 2019-04-05 16:36, Josef 'Jeff' Sipek via dovecot wrote: On Wed, Apr 03, 2019 at 19:02:52 +0800, Joan Moreau via dovecot wrote: issue seems in the Git version : Which git revision? Before you updated to the broken revision, which revision/version were you running? Can you try it with 5f6e39c50ec79ba8847b2fdb571a9152c71cd1b6 (the commit just before the fts_enforced=body introduction)? That's the only recent fts change. Thanks, Jeff. On 2019-04-03 18:58, @lbutlr via dovecot wrote: On 3 Apr 2019, at 04:30, Joan Moreau via dovecot wrote: doveadm search -u j...@grosjo.net mailbox inbox text milan Did that search over my list mail and got 83 results, not able to duplicate your issue. What version of dovecot and have you tried to reindex? dovecot-2.3.5.1 here.