similar to: tcpwrap: Fatal: master: service(tcpwrap): child $PID killed with signal 11

Hi Timo, some imap processes seems to have some problems. Regards, Pascal -------------- next part -------------- Core was generated by `dovecot/imap'. Program terminated with signal 6, Aborted. #0 0x00007fbf87b25475 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x00007fbf87b25475 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1

> On 21/08/2020 08:48 Peter <peter at pajamian.dhs.org> wrote: > > > On 20/08/20 11:02 pm, Thomas Scheunemann wrote: > > Using the Repo http://repo.dovecot.org/ce-2.3-latest after upgrading from > > 2.3.10.1-3 to 2.3.11.3-3 we get numerous error messages like: > > > > dovecot: imap-login: Error: connect(tcpwrap) failed: No such file or directory >

On 20/08/20 11:02 pm, Thomas Scheunemann wrote: > Using the Repo http://repo.dovecot.org/ce-2.3-latest after upgrading from > 2.3.10.1-3 to 2.3.11.3-3 we get numerous error messages like: > > dovecot: imap-login: Error: connect(tcpwrap) failed: No such file or directory > > We use tcpwrap support in dovecot, which worked flawlessly in the older version. > I can see that the

Using the Repo http://repo.dovecot.org/ce-2.3-latest after upgrading from 2.3.10.1-3 to 2.3.11.3-3 we get numerous error messages like: dovecot: imap-login: Error: connect(tcpwrap) failed: No such file or directory We use tcpwrap support in dovecot, which worked flawlessly in the older version. I can see that the socket /var/run/dovecot/login/tcpwrap is not created anymore. And comparing with

On Fri, Aug 21, 2020 at 06:02:49PM +1200, Peter wrote: > On 21/08/20 5:55 pm, Aki Tuomi wrote: > > > At a guess it was removed from the spec for el8 (which does not support > > > tcpwrap) and somehow got removed from el7 by accident. The ghettoforge > > > dovecot23 packages have tcpwrap support for el7: So is el8 truly incompatible with tcpwrap? Or is it just too

>>>> At a guess it was removed from the spec for el8 (which does not support >>>> tcpwrap) and somehow got removed from el7 by accident. The ghettoforge >>>> dovecot23 packages have tcpwrap support for el7: > > So is el8 truly incompatible with tcpwrap? Or is it just too much > effort to continue suport for every feature that was ever in the system?

On 21/08/20 5:55 pm, Aki Tuomi wrote: >> At a guess it was removed from the spec for el8 (which does not support >> tcpwrap) and somehow got removed from el7 by accident. The ghettoforge >> dovecot23 packages have tcpwrap support for el7: > > We are looking into this, it was indeed removed from el7 by accident. RPM macros can be quite tricky sometimes. I have: %if

Hi, I am a long-time dovecot user/admin for my family mail server, but I had ventured into configuring replication only recently and I am not sure about how it should work and what are the good practices. My intent for replication was to have another instance to switch to in a short time if something fails. I have daily backups, but it will take much more time to rebuild and restore than just to

> > With todays nightly: > > > > dsync(wsunpriv at iai.uni-bonn.de): Panic: file imapc-list.c: line 199 (imapc_list_get_vname): assertion failed: (strncmp(prefix, storage_name, prefix_len) == 0 && storage_name[prefix_len] == list->sep) > > Oh, and this would be good to solve too. What does it say with gdb: > > gdb dsync core > fr 5 > p prefix >

Hi all! I am a long-time dovecot user/admin on my home server, but only recently tried to configure replication. Everything seems to work except sieve scripts replication. When I upload new one on the server A, it does not replicate to server B, even if it seemingly tries to, according to debug logs. The log antry says: Replication requested by 'sieve_storage_sync_transaction_begin',

Hi all! I am a long-time dovecot user/admin on my home server, but only recently tried to configure replication. Everything seems to work except sieve scripts replication. When I upload new one on the server A, it does not replicate to server B, even if it seemingly tries to, according to debug logs. The log antry says: Replication requested by 'sieve_storage_sync_transaction_begin',

Hello, Using the TCP Wrapper Dovecot could control access to IMAP and POP3 servers. Is it also possible to controll access to an LMTP Server listening on Port 24? Andreas

It works ! It was THAT easy ! Can you suggest how to replace the hair I pulled out ? :-) On 2016-12-29 5:27 PM, Larry Rosenman wrote: > login_access_sockets = tcpwrap > > service tcpwrap { > unix_listener login/tcpwrap { > group = $default_login_user > mode = 0600 > user = $default_login_user > } > } > > > > On Thu, Dec 29, 2016 at

I have Dovecot2 auth setup to run as user = doveauth group = dovecot configured in, vi conf.d/10-master.conf ... service auth { unix_listener /var/spool/postfix/private/auth { user = postfix group = postfix mode = 0660 } user = doveauth group = dovecot } service auth-worker { user = doveauth group = dovecot } ... When I start Dovecot, ls -al

# Space separated list of login access check sockets (e.g. tcpwrap) #login_access_sockets = login_access_sockets = tcpwrap service tcpwrap { unix_listener login/tcpwrap { group = $default_login_user mode = 0600 user = $default_login_user } } I believe that's all. I had placed it all in /usr/local/etc/dovecot/dovecot.conf. On Mon, Nov 14, 2016 at 11:45 AM, Jim Pazarena

I have compiled dovecot2 for FreeBSD with the tcpwrap option. A tcpwrap binary gets built and resides in the FreeBSD directory /usr/local/libexec/dovecot an examination of the compiled options (using the FreeBSD pkg install dovecot2) confirms: LIBWRAP : on yet, when I adjust dovecot.conf with: login_access_sockets = tcpwrap I get the following logged error message: 20161229 17:02:49

Hello, It seems dovecot 2.0 beta4 still behave strangely without tcpwrap. I still get the errors: 2010-03-25_17:26:59.33848 Fatal: service(tcpwrap) access(/opt/dovecot/libexec/dovecot/tcpwrap) failed: No such file or directory 2010-03-25_17:27:00.36108 Fatal: service(tcpwrap) access(/opt/dovecot/libexec/dovecot/tcpwrap) failed: Permission denied It's easy to solve by touching and

I'm trying to kickstart 2.0b3 on my NetBSD system (where 1.2.x works great!), and keep hitting: Fatal: service(tcpwrap) access(/software/dovecot-2.0beta3/libexec/dovecot/tcpwrap) failed: No such file or directory Indeed, that file doesn't exist...but I don't have nor want libwrap. It appears that doveconf includes tcpwrap... service tcpwrap { chroot = client_limit = 1

Dovecot with libwrap doesn't work on FreeBSD for some reason or another. I have these lines in my /etc/hosts.allow: ALL: LOCAL 127.0.0.1: allow pop3: ALL: allow ALL: ALL: deny Yet when you try to telnet to localhost, port 110 this is what happens: Aug 29 22:48:38 dodo dovecot: pop3-login: Error: connect(tcpwrap) failed: Permission denied I also tried auth_debug=yes to see what's wrong

hi everybody having I believe sort of plain-vanilla config with section in 10-tcpwrapper.conf as per docs login_access_sockets = tcpwrap service tcpwrap { unix_listener login/tcpwrap { group = $default_login_user mode = 0600 user = $default_login_user } } /etc/hosts.deny contains: ALL: given_host and yet dovecot logins IMAP client in whereas other tcpwrapper aware