Re: Error: fts_solr: received invalid uid (John Fawcett)

[John Fawcett]

On 03/01/2022 01:18, oliver.kr...@snoog.ch wrote:

Hi John,

You are right this was not a dovecot solr query. It is really strange 
everything seems to work with Dovecot 2.3.4. E.g. search and  
rebuilding index from scratch using doveadm. As soon as I use version  
2.3.13 things are getting wild: dovecot crashed when I re-scan the 
index using doveadm and search does not work anymore, after re-scan:


Panic: file http-client-request.c: line 1240 
(http_client_request_send_more): assertion failed: (req->payload_input 
!= NULL)
doveadm(kr...@invectrix.ch): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) 
[0x7fc54cace4e2] -> 
/usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7fc54cace5fe] 
-> /usr/lib/dovecot/libdovecot.so.0(+0xfc49b) [0x7fc54cada49b] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xfc4d1) [0x7fc54cada4d1] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x53aee) [0x7fc54ca31aee] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x4aec2) [0x7fc54ca28ec2] -> 
/usr/lib/dovecot/libdovecot.so.0(http_client_connection_output+0xee) 
[0x7fc54ca7ebde] -> /usr/lib/dovecot/libdovecot.so.0(+0x122171) 
[0x7fc54cb00171] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) 
[0x7fc54caeff59] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7fc54caf1592] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7fc54caf] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7fc54caf01c0] -> /usr/lib/dovecot/libdovecot.so.0(+0x9c4cd) 
[0x7fc54ca7a4cd] -> 
/usr/lib/dovecot/libdovecot.so.0(http_client_request_finish_payload+0x2c) 
[0x7fc54ca7a6dc] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xf243) [0x7fc54c0a6243] 
-> /usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_parser_more+0x25) 
[0x7fc54c0a5345] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xbfcf) [0x7fc54c0a2fcf] 
-> /usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_build_mail+0xa27) 
[0x7fc54c0a3a87] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0x11f0b) 
[0x7fc54c0a8f0b] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(mail_precache+0x2e) 
[0x7fc54cbf14ae] -> doveadm(+0x3761f) [0x55d18bdbf61f] -> 
doveadm(+0x31bad) [0x55d18bdb9bad] -> doveadm(+0x32860) 
[0x55d18bdba860] -> 
doveadm(doveadm_cmd_ver2_to_mail_cmd_wrapper+0x22d) [0x55d18bdbb4ad] 
-> doveadm(doveadm_cmd_run_ver2+0x4c8) [0x55d18bdcbb88] -> 
doveadm(doveadm_cmd_try_run_ver2+0x3a) [0x55d18bdcbbda] -> 
doveadm(main+0x1d0) [0x55d18bdaa450] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) 
[0x7fc54c69fd0a] -> doveadm(_start+0x2a) [0x55d18bdaa92a]


and solr:

2022-01-03 00:13:20.829 ERROR (qtp1991278377-21) [   x:dovecot] 
o.a.s.s.HttpSolrCall null:[com.ctc.wstx.exc.WstxLazyException] 
com.ctc.wstx.exc.WstxIOException: Early EOF




Caused by: org.eclipse.jetty.io.EofException: Early EOF
at org.eclipse.jetty.server.HttpInput$3.getError(HttpInput.java:1143)
at 
org.eclipse.jetty.server.HttpInput$3.noContent(HttpInput.java:1131)

at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:318)

Seems like dovecot is sending an empty query?

Oliver 


Hi Oliver

I remember there being some patches to dovecot for using solr that 
addressed errors like this and also an additional patch for using solr 
and tika. You could try looking back in the archives and applying them. 
But a quicker way if it's open is to use a later version. I am sure that 
by 2.3.16 all the fixes were already incorporated by the development team.


However, I'm not sure if this is related to your original issue. The 
response from solr looks strange to me. But you'll need to get a working 
version before progressing that issue (and maybe in doing so you'll find 
it resolved by itself).


John

Re: Error: fts_solr: received invalid uid

[oliver . krone]

Hi John,

You are right this was not a dovecot solr query. It is really strange 
everything seems to work with Dovecot 2.3.4. E.g. search and  rebuilding 
index from scratch using doveadm. As soon as I use version  2.3.13 
things are getting wild: dovecot crashed when I re-scan the index using 
doveadm and search does not work anymore, after re-scan:


Panic: file http-client-request.c: line 1240 
(http_client_request_send_more): assertion failed: (req->payload_input 
!= NULL)
doveadm(kr...@invectrix.ch): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) [0x7fc54cace4e2] 
-> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7fc54cace5fe] 
-> /usr/lib/dovecot/libdovecot.so.0(+0xfc49b) [0x7fc54cada49b] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xfc4d1) [0x7fc54cada4d1] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x53aee) [0x7fc54ca31aee] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x4aec2) [0x7fc54ca28ec2] -> 
/usr/lib/dovecot/libdovecot.so.0(http_client_connection_output+0xee) 
[0x7fc54ca7ebde] -> /usr/lib/dovecot/libdovecot.so.0(+0x122171) 
[0x7fc54cb00171] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7fc54caeff59] 
-> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7fc54caf1592] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7fc54caf] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7fc54caf01c0] -> /usr/lib/dovecot/libdovecot.so.0(+0x9c4cd) 
[0x7fc54ca7a4cd] -> 
/usr/lib/dovecot/libdovecot.so.0(http_client_request_finish_payload+0x2c) 
[0x7fc54ca7a6dc] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xf243) [0x7fc54c0a6243] 
-> /usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_parser_more+0x25) 
[0x7fc54c0a5345] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xbfcf) [0x7fc54c0a2fcf] 
-> /usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_build_mail+0xa27) 
[0x7fc54c0a3a87] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0x11f0b) [0x7fc54c0a8f0b] 
-> /usr/lib/dovecot/libdovecot-storage.so.0(mail_precache+0x2e) 
[0x7fc54cbf14ae] -> doveadm(+0x3761f) [0x55d18bdbf61f] -> 
doveadm(+0x31bad) [0x55d18bdb9bad] -> doveadm(+0x32860) [0x55d18bdba860] 
-> doveadm(doveadm_cmd_ver2_to_mail_cmd_wrapper+0x22d) [0x55d18bdbb4ad] 
-> doveadm(doveadm_cmd_run_ver2+0x4c8) [0x55d18bdcbb88] -> 
doveadm(doveadm_cmd_try_run_ver2+0x3a) [0x55d18bdcbbda] -> 
doveadm(main+0x1d0) [0x55d18bdaa450] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fc54c69fd0a] 
-> doveadm(_start+0x2a) [0x55d18bdaa92a]


and solr:

2022-01-03 00:13:20.829 ERROR (qtp1991278377-21) [   x:dovecot] 
o.a.s.s.HttpSolrCall null:[com.ctc.wstx.exc.WstxLazyException] 
com.ctc.wstx.exc.WstxIOException: Early EOF




Caused by: org.eclipse.jetty.io.EofException: Early EOF
at 
org.eclipse.jetty.server.HttpInput$3.getError(HttpInput.java:1143)
at 
org.eclipse.jetty.server.HttpInput$3.noContent(HttpInput.java:1131)

at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:318)

Seems like dovecot is sending an empty query?

Oliver


Hi Oliver

unless I'm missing something that doesn't look like the type of query
dovecot launches - dovecot sends various parameters including the
request for xml results. The thing that looks odd to me is that the
results fields should be single values not arrays enclosed in [], ie I
would have expected

"uid":21,

instead of

"uid":[21],

I'd be interested to see the equivalent xml output produced by running 
a

query that dovecot sends.

John

Re: Error: fts_solr: received invalid uid (John Fawcett)

[oliver . krone]

Hi John,

You are right this was not a dovecot solr query. It is really strange 
everything seems to work with Dovecot 2.3.4. E.g. search and  rebuilding 
index from scratch using doveadm. As soon as I use version  2.3.13 
things are getting wild: dovecot crashed when I re-scan the index using 
doveadm and search does not work anymore, after re-scan:


Panic: file http-client-request.c: line 1240 
(http_client_request_send_more): assertion failed: (req->payload_input 
!= NULL)
doveadm(kr...@invectrix.ch): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) [0x7fc54cace4e2] 
-> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7fc54cace5fe] 
-> /usr/lib/dovecot/libdovecot.so.0(+0xfc49b) [0x7fc54cada49b] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xfc4d1) [0x7fc54cada4d1] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x53aee) [0x7fc54ca31aee] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x4aec2) [0x7fc54ca28ec2] -> 
/usr/lib/dovecot/libdovecot.so.0(http_client_connection_output+0xee) 
[0x7fc54ca7ebde] -> /usr/lib/dovecot/libdovecot.so.0(+0x122171) 
[0x7fc54cb00171] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7fc54caeff59] 
-> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7fc54caf1592] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7fc54caf] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7fc54caf01c0] -> /usr/lib/dovecot/libdovecot.so.0(+0x9c4cd) 
[0x7fc54ca7a4cd] -> 
/usr/lib/dovecot/libdovecot.so.0(http_client_request_finish_payload+0x2c) 
[0x7fc54ca7a6dc] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xf243) [0x7fc54c0a6243] 
-> /usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_parser_more+0x25) 
[0x7fc54c0a5345] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0xbfcf) [0x7fc54c0a2fcf] 
-> /usr/lib/dovecot/modules/lib20_fts_plugin.so(fts_build_mail+0xa27) 
[0x7fc54c0a3a87] -> 
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0x11f0b) [0x7fc54c0a8f0b] 
-> /usr/lib/dovecot/libdovecot-storage.so.0(mail_precache+0x2e) 
[0x7fc54cbf14ae] -> doveadm(+0x3761f) [0x55d18bdbf61f] -> 
doveadm(+0x31bad) [0x55d18bdb9bad] -> doveadm(+0x32860) [0x55d18bdba860] 
-> doveadm(doveadm_cmd_ver2_to_mail_cmd_wrapper+0x22d) [0x55d18bdbb4ad] 
-> doveadm(doveadm_cmd_run_ver2+0x4c8) [0x55d18bdcbb88] -> 
doveadm(doveadm_cmd_try_run_ver2+0x3a) [0x55d18bdcbbda] -> 
doveadm(main+0x1d0) [0x55d18bdaa450] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fc54c69fd0a] 
-> doveadm(_start+0x2a) [0x55d18bdaa92a]


and solr:

2022-01-03 00:13:20.829 ERROR (qtp1991278377-21) [   x:dovecot] 
o.a.s.s.HttpSolrCall null:[com.ctc.wstx.exc.WstxLazyException] 
com.ctc.wstx.exc.WstxIOException: Early EOF




Caused by: org.eclipse.jetty.io.EofException: Early EOF
at org.eclipse.jetty.server.HttpInput$3.getError(HttpInput.java:1143)
at org.eclipse.jetty.server.HttpInput$3.noContent(HttpInput.java:1131)
at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:318)

Seems like dovecot is sending an empty query?

Oliver



Hi Oliver

unless I'm missing something that doesn't look like the type of query
dovecot launches - dovecot sends various parameters including the
request for xml results. The thing that looks odd to me is that the
results fields should be single values not arrays enclosed in [], ie I
would have expected

"uid":21,

instead of

"uid":[21],

I'd be interested to see the equivalent xml output produced by running 
a

query that dovecot sends.

John

Re: Can't connect to database

[Ken Wright]

On Mon, 2022-01-03 at 00:44 +0200, Aki Tuomi wrote:

> Maybe MySQL is not running, or perhaps something is blocking
> connecting to it? Check dmesg and (if on redhat based system)
> /var/log/audit/audit.log
When I ran systemctl status mysql, it tells me mariadb.service is
active and running.

Re: Can't connect to database

[dovecot]

>> mysql(localhost): Connect failed to database (postfix): Can't connect
>> to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

> Maybe MySQL is not running, or perhaps something is blocking connecting to 
> it? Check dmesg and (if on redhat based system)
> /var/log/audit/audit.log


Environment? Chroot, docker, selinux can prevent sockets from being reachable.
Another area to check... when the socket has rwx for others, if one of the 
parent directories is blocking access for others then programs will be denied 
access.

Re: Can't connect to database

[Aki Tuomi]

> On 02/01/2022 22:36 Ken Wright  wrote:
> 
>  
> Dovecot has been giving me problems for the past week or so.  Today the
> error log showed me this:
> 
> Jan  2 13:33:39 grace dovecot: auth-worker(3250): Error:
> mysql(localhost): Connect failed to database (postfix): Can't connect
> to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
> - waiting for 5 seconds before retry
> 
> The socket is there, showing full permissions (rwx for owner, group,
> and rest of the universe) so I can't understand why dovecot can't
> connect.
> 
> Is there anyone who can help?
> 
> Ken

Maybe MySQL is not running, or perhaps something is blocking connecting to it? 
Check dmesg and (if on redhat based system) /var/log/audit/audit.log

Aki

Re: Error: fts_solr: received invalid uid

[John Fawcett]

On 02/01/2022 12:13, oliver.kr...@snoog.ch wrote:
Here is what solr sends to dovecot, the offending uid in this exmaple 
is '21'

{
  "responseHeader":{
    "status":0,
    "QTime":1,
    "params":{
  "q":"body:Zeitserver"}},
  "response":{"numFound":1,"start":0,"numFoundExact":true,"docs":[
  {
    "uid":[21],
    "box":["2e60f3054059c95fbf580600eb1947e0"],
    "user":["oliver.kr...@snoog.ch"],
"id":"21/2e60f3054059c95fbf580600eb1947e0/oliver.kr...@snoog.ch",
    "body":[" ... "],
    "hdr":[" ... "],
    "from":["..."],
    "subject":["..."],
    "to":["..."],
    "_version_":1720682332306800640}]
  }}

Oliver 


Hi Oliver

unless I'm missing something that doesn't look like the type of query 
dovecot launches - dovecot sends various parameters including the 
request for xml results. The thing that looks odd to me is that the 
results fields should be single values not arrays enclosed in [], ie I 
would have expected


"uid":21,

instead of

"uid":[21],

I'd be interested to see the equivalent xml output produced by running a 
query that dovecot sends.


John

Re: master: service(imap): child xxxx killed with signal 11

[WJCarpenter]

Thank you, Lukas Matasovsky, for isolating this. I've had dovecot pinned 
to the .16 version since I started getting that crash in the .17 
version. But I've been too slack to do more than scan the mailing list 
for fixes. Your investigation provided the solution that also worked for 
me. Once again, my laziness pays off. Thanks again.


On 1/2/22 6:07 AM, Lukas Matasovsky wrote:
I have isolated the issue: after removing fts_squat dovecot seems to 
be back to normal.
See also: https://doc.dovecot.org/configuration_manual/fts/squat/ 

Can't connect to database

[Ken Wright]

Dovecot has been giving me problems for the past week or so.  Today the
error log showed me this:

Jan  2 13:33:39 grace dovecot: auth-worker(3250): Error:
mysql(localhost): Connect failed to database (postfix): Can't connect
to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
- waiting for 5 seconds before retry

The socket is there, showing full permissions (rwx for owner, group,
and rest of the universe) so I can't understand why dovecot can't
connect.

Is there anyone who can help?

Ken

Re: Dovecot Docker Image Volumes

[Aki Tuomi]

Hi Thomas,

> On 02/01/2022 17:20 Thomas Bellebaum  wrote:
> 
>  
> Hello there and happy new year,
> 
> I have a question/request regarding the Docker Image hosted at 
> https://hub.docker.com/r/dovecot/dovecot.
> The Dockerfile itself declares two volumes:
> 
> - `/etc/dovecot` for configuration data
> - `/srv/mail` for mail storage
> 
> It seems inconvenient in some cases to have the image create these volumes, 
> especially in case of the former.
> 
> Consider a minimal Dockerfile like the following:
> 
> ```
> FROM dovecot/dovecot:latest
> COPY dovecot.conf /etc/dovecot/dovecot.conf
> ```
> 
> This creates a new image building on top of the official one,
> which has statically configured configuration, and thus does not need to save 
> its config in a volume.
> Yet currently, since the base image exports volumes, a config volume is 
> created.
> 

Why is it undesirable to have a config volume in docker? What's the impact?

> A user might also choose to save mail in a different directory or even in a 
> remote SQL database, rendering the second volume unnecessary.
> 

This is not how docker works. You can use whatever directory outside docker to 
persist the mail data.

Also, you can't store mail without any local persistence volume with dovecot, 
so this point is rather without merit. 

There is no way to store mails in SQL with dovecot.

> I would like to know a bit about the reasons for declaring the volumes,
> and suggest removing the line, should this be an option.
> 
> Some impact considerations:
> 
> - Removing the volumes for future image versions will not impact existing 
> deployments building on tags other than `latest`.
> - As the default (example) configuration is not very useful for 
> non-test-setups, most people have probably assigned the config volume 
> explicitly, e.g. using docker's `-v` option. These people will also not be 
> affected.
> - The description explicitly states to mount `/srv/mail/`, but some people 
> might rely on the the automatic volume creation nonetheless.
> - Some obscure proprietary scripts may rely on the current behavior.
> 
> In any case, if the volumes are no longer declared, the image description 
> should mention that the mail storage location (the default being `/var/mail`) 
> must be saved e.g. by using volumes, and probably also that the configuration 
> is expected at `/etc/dovecot/dovecot.conf`.
> 

/var/mail is for per-user mail data in a system where each system user has a 
mailbox. 

> Stay healthy and have a nice day,
> 
> -- 
> Thomas Bellebaum 

I don't see much reason here to remove either volume, as most people will 
anyways need to use them. You can only do so much static config file. If you 
want to use SSL or any user database/password database you'll need more config 
files.

Aki

Dovecot Docker Image Volumes

[Thomas Bellebaum]

Hello there and happy new year,

I have a question/request regarding the Docker Image hosted at 
https://hub.docker.com/r/dovecot/dovecot.
The Dockerfile itself declares two volumes:

- `/etc/dovecot` for configuration data
- `/srv/mail` for mail storage

It seems inconvenient in some cases to have the image create these volumes, 
especially in case of the former.

Consider a minimal Dockerfile like the following:

```
FROM dovecot/dovecot:latest
COPY dovecot.conf /etc/dovecot/dovecot.conf
```

This creates a new image building on top of the official one,
which has statically configured configuration, and thus does not need to save 
its config in a volume.
Yet currently, since the base image exports volumes, a config volume is created.

A user might also choose to save mail in a different directory or even in a 
remote SQL database, rendering the second volume unnecessary.

I would like to know a bit about the reasons for declaring the volumes,
and suggest removing the line, should this be an option.

Some impact considerations:

- Removing the volumes for future image versions will not impact existing 
deployments building on tags other than `latest`.
- As the default (example) configuration is not very useful for 
non-test-setups, most people have probably assigned the config volume 
explicitly, e.g. using docker's `-v` option. These people will also not be 
affected.
- The description explicitly states to mount `/srv/mail/`, but some people 
might rely on the the automatic volume creation nonetheless.
- Some obscure proprietary scripts may rely on the current behavior.

In any case, if the volumes are no longer declared, the image description 
should mention that the mail storage location (the default being `/var/mail`) 
must be saved e.g. by using volumes, and probably also that the configuration 
is expected at `/etc/dovecot/dovecot.conf`.

Stay healthy and have a nice day,

-- 
Thomas Bellebaum 


pgpDsW2Vj41jQ.pgp
Description: PGP signature

Re: master: service(imap): child xxxx killed with signal 11

[Lukas Matasovsky]

Hi,

I have isolated the issue: after removing fts_squat dovecot seems to be
back to normal.

See also: https://doc.dovecot.org/configuration_manual/fts/squat/

Thank you for your support! You may close the issue. Cheers, Lukas

On Sun, Jan 2, 2022 at 12:03 PM Lukas Matasovsky 
wrote:

> Hi,
>
> I am just investigating on another server Debian, directly after upgrading
> to dovecot .17:
>
> Jan  2 11:55:10 judy dovecot: auth: Debug: auth client connected
> (pid=8682)
> Jan  2 11:55:10 judy dovecot: auth: Debug: client in:
> AUTH#0111#011PLAIN#011service=imap#011session=aL3mPJfUmpXAqAIy#011lip=192.168.2.1#011rip=192.168.2.50#011lport=143#011rport=38298
>
> Jan  2 11:55:10 judy dovecot: auth: Debug: client passdb out:
> CONT#0111#011
> Jan  2 11:55:10 judy dovecot: auth: Debug: client in: CONT
> Jan  2 11:55:10 judy dovecot: auth: Debug:
> pam(lukasm,192.168.2.50,): Performing passdb lookup
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<197>: Handling PASSV
> request
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
> pam(lukasm,192.168.2.50,): Performing passdb lookup
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
> pam(lukasm,192.168.2.50,): lookup service=dovecot
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
> pam(lukasm,192.168.2.50,): #1/1 style=1 msg=Password
> :
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
> pam(lukasm,192.168.2.50,): Finished passdb lookup
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<197>: Finished
> Jan  2 11:55:10 judy dovecot: auth: Debug:
> pam(lukasm,192.168.2.50,): Finished passdb lookup
> Jan  2 11:55:10 judy dovecot: auth: Debug:
> auth(lukasm,192.168.2.50,): Auth request finished
> Jan  2 11:55:10 judy dovecot: auth: Debug: client passdb out:
> OK#0111#011user=lukasm#011
> Jan  2 11:55:10 judy dovecot: auth: Debug: master in:
> REQUEST#0112975727617#0118682#0111#011c681c4159deed081b164a458bfa5ffcb#011session_pid=8683#011request_auth_token
>
> Jan  2 11:55:10 judy dovecot: auth: Debug:
> passwd(lukasm,192.168.2.50,): Performing userdb lookup
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<198>: Handling USER
> request
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<198>:
> passwd(lukasm,192.168.2.50,): Performing userdb look
> up
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<198>:
> passwd(lukasm,192.168.2.50,): lookup
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<198>:
> passwd(lukasm,192.168.2.50,): Finished userdb lookup
> Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
> unix:auth-worker (pid=8004,uid=120): auth-worker<198>: Finished
> Jan  2 11:55:10 judy dovecot: auth: Debug:
> passwd(lukasm,192.168.2.50,): Finished userdb lookup
> Jan  2 11:55:10 judy dovecot: auth: Debug: master userdb out:
> USER#0112975727617#011lukasm#011system_groups_user=lukasm#011uid=1000#011gid=1000#011home=/home/lukasm#011auth_mech=PLAIN#01
> 1auth_token=d4309d087613af647782c4f47f50ab8ffc47a25c
> Jan  2 11:55:10 judy dovecot: imap-login: Login: user=,
> method=PLAIN, rip=192.168.2.50, lip=192.168.2.1, mpid=8683,
> session=
> Jan  2 11:55:10 judy dovecot: imap(monica)<8680>: Fatal:
> master: service(imap): child 8680 killed with signal 11 (core dumps
> disabled - https://dovecot.org/bugreport.ht
> ml#coredumps)
>
> Would you like to have a coredump as well?
>
> Thank you & cheers, Lukas
>
>
> On Sun, Jan 2, 2022 at 2:06 AM Lukas Matasovsky <
> lukas.matasov...@gmail.com> wrote:
>
>> Dear Maintainer,
>>
>> I have several dovecot installations, all of them stopped working with
>> the upgrade from .16 to .17. Maybe I am missing something, or it's a bug.
>> All I can see is a signal 11 after each login attempt.
>>
>> Attached you can find a sysreport plus a core dump, both from different
>> states of configuration (I reverted the core-dump settings later on) of the
>> same server, but the effect has been the same ever since upgrading.
>> I have other servers that use pam (not mariadb) and local maildirs that
>> show the same behavior.
>>
>> For now, I have downgraded all servers, if needed I could run some more
>> tests.
>>
>> Thank you for checking & cheers, Lukas
>>
>

Re: master: service(imap): child xxxx killed with signal 11

[Lukas Matasovsky]

Hi,

I am just investigating on another server Debian, directly after upgrading
to dovecot .17:

Jan  2 11:55:10 judy dovecot: auth: Debug: auth client connected (pid=8682)
Jan  2 11:55:10 judy dovecot: auth: Debug: client in:
AUTH#0111#011PLAIN#011service=imap#011session=aL3mPJfUmpXAqAIy#011lip=192.168.2.1#011rip=192.168.2.50#011lport=143#011rport=38298

Jan  2 11:55:10 judy dovecot: auth: Debug: client passdb out: CONT#0111#011
Jan  2 11:55:10 judy dovecot: auth: Debug: client in: CONT
Jan  2 11:55:10 judy dovecot: auth: Debug:
pam(lukasm,192.168.2.50,): Performing passdb lookup
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<197>: Handling PASSV
request
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
pam(lukasm,192.168.2.50,): Performing passdb lookup
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
pam(lukasm,192.168.2.50,): lookup service=dovecot
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
pam(lukasm,192.168.2.50,): #1/1 style=1 msg=Password
:
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<197>:
pam(lukasm,192.168.2.50,): Finished passdb lookup
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<197>: Finished
Jan  2 11:55:10 judy dovecot: auth: Debug:
pam(lukasm,192.168.2.50,): Finished passdb lookup
Jan  2 11:55:10 judy dovecot: auth: Debug:
auth(lukasm,192.168.2.50,): Auth request finished
Jan  2 11:55:10 judy dovecot: auth: Debug: client passdb out:
OK#0111#011user=lukasm#011
Jan  2 11:55:10 judy dovecot: auth: Debug: master in:
REQUEST#0112975727617#0118682#0111#011c681c4159deed081b164a458bfa5ffcb#011session_pid=8683#011request_auth_token

Jan  2 11:55:10 judy dovecot: auth: Debug:
passwd(lukasm,192.168.2.50,): Performing userdb lookup
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<198>: Handling USER
request
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<198>:
passwd(lukasm,192.168.2.50,): Performing userdb look
up
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<198>:
passwd(lukasm,192.168.2.50,): lookup
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<198>:
passwd(lukasm,192.168.2.50,): Finished userdb lookup
Jan  2 11:55:10 judy dovecot: auth-worker(8349): Debug: conn
unix:auth-worker (pid=8004,uid=120): auth-worker<198>: Finished
Jan  2 11:55:10 judy dovecot: auth: Debug:
passwd(lukasm,192.168.2.50,): Finished userdb lookup
Jan  2 11:55:10 judy dovecot: auth: Debug: master userdb out:
USER#0112975727617#011lukasm#011system_groups_user=lukasm#011uid=1000#011gid=1000#011home=/home/lukasm#011auth_mech=PLAIN#01
1auth_token=d4309d087613af647782c4f47f50ab8ffc47a25c
Jan  2 11:55:10 judy dovecot: imap-login: Login: user=,
method=PLAIN, rip=192.168.2.50, lip=192.168.2.1, mpid=8683,
session=
Jan  2 11:55:10 judy dovecot: imap(monica)<8680>: Fatal:
master: service(imap): child 8680 killed with signal 11 (core dumps
disabled - https://dovecot.org/bugreport.ht
ml#coredumps)

Would you like to have a coredump as well?

Thank you & cheers, Lukas


On Sun, Jan 2, 2022 at 2:06 AM Lukas Matasovsky 
wrote:

> Dear Maintainer,
>
> I have several dovecot installations, all of them stopped working with the
> upgrade from .16 to .17. Maybe I am missing something, or it's a bug. All I
> can see is a signal 11 after each login attempt.
>
> Attached you can find a sysreport plus a core dump, both from different
> states of configuration (I reverted the core-dump settings later on) of the
> same server, but the effect has been the same ever since upgrading.
> I have other servers that use pam (not mariadb) and local maildirs that
> show the same behavior.
>
> For now, I have downgraded all servers, if needed I could run some more
> tests.
>
> Thank you for checking & cheers, Lukas
>


dovecot-sysreport-judy.lumat.at-1641120919.tar.gz
Description: application/gzip

Re: Error: fts_solr: received invalid uid

[oliver . krone]

Here is what solr sends to dovecot, the offending uid in this exmaple is 
'21'

{
  "responseHeader":{
"status":0,
"QTime":1,
"params":{
  "q":"body:Zeitserver"}},
  "response":{"numFound":1,"start":0,"numFoundExact":true,"docs":[
  {
"uid":[21],
"box":["2e60f3054059c95fbf580600eb1947e0"],
"user":["oliver.kr...@snoog.ch"],

"id":"21/2e60f3054059c95fbf580600eb1947e0/oliver.kr...@snoog.ch",

"body":[" ... "],
"hdr":[" ... "],
"from":["..."],
"subject":["..."],
"to":["..."],
"_version_":1720682332306800640}]
  }}

Oliver


I'm using dovecot 2.3.13,? solr 8.x. and roundcube 1.5.1. However when
I do a search I get the the Error: fts_solr: received invalid uid,
search results are ok.

Thanks

Presumably one of the uid returned from solr could not be decoded (i.e.
converted to an int). The offending uid should have been printed as 
part

of the message. If you need to get more info you could investigate what
is being returned by solr running the exact same query from a browser 
if

you're able to retrieve it from the solr log.

Alternatively you could set rawlog_dir in the fts_solr dovecot settings
and then look at what is being sent back from solr in the .in file that
is logged.

https://doc.dovecot.org/settings/plugin/fts-solr-plugin/?highlight=fts%20dovecot%20plugin

John