similar to: another suggestion

We are configuring location= running a bash-script during imap-postlogin setting $MAIL in $USERDB_KEYS, as described in wiki/PostLoginScripting.txt This works fine. However, running a command like 'dovadm index [-u user] folder' only works for users with settings that match the default in mail_location= Would it be possible to make the location available for doveadm in a similar way,

On Tue, Sep 15, 2015 at 12:31:25PM +0900, Timo Sirainen wrote: > On 12 Sep 2015, at 04:45, Bradley Giesbrecht <pixilla at macports.org> wrote: > > > > Is the Dovecot Object Storage plugin still available for purchase? > > > > It's available, but at least for now we're only selling it to big customers. Well how big? Would a univeristy with 25.000 users

We turned off SSLv3 support on our pop/imap running dovecot on Oct 16th, we did check that all users where using TLSv1 and there have been no complaints (except one old windows-phone). But at 13:00 UTC today, suddenly strange entries is seen in the logfile: Error: SSL: Stacked error: error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message: SSL alert number 10 Followed

On Tue, Nov 04, 2014 at 12:38:02PM +0100, Matthias Egger wrote: > Has someone of you just found any kind of solution to this problem? We have been running some days with patches 31262a892ba7 and 80ed82a93c1a from http://hg.dovecot.org/dovecot-2.2/ They are working fine, handling the previously paniced situations smoothly. Thanks again to the folks at dovecot.org! hmk

Following version and content of .conf file ---------------------------------------------------------------------------------------- root at ABCD:/CavE/download/delete_to_trash# dovecot --version 2.2.9 root at ABCD:/CavE/download/delete_to_trash# dovecot -n # 2.2.9: /etc/dovecot/dovecot.conf # OS: Linux 3.13.0-32-generic x86_64 Ubuntu 14.04.1 LTS auth_mechanisms = plain login log_path =

https://bugzilla.redhat.com/show_bug.cgi?id=619334 This is a slightly unsatisfactory patch which allows coredumps to be captured when they occur inside the appliance. You can capture coredumps by doing: export LIBGUESTFS_COREDUMP=/sysroot/core.%t.%p.%e or equivalently: g.set_coredump ("/sysroot/core.%t.%p.%e") or variations thereof, see the manual page. When a coredump occurs,

Hi Daniel, here are any informations. A little bit strange, coredumpctl showthe libvirtd. coredumpctl dump libvirt and info libvirt  no information. Best regards Holger -------------------------------------------------------------------------- etcsvms5:/var/adm # coredumpctl TIME                            PID   UID   GID SIG PRESENT EXE Tue 2017-11-07 16:22:57 CET     485     0     0  11

Hi. I use dovecot-2.0.11-1.fc14.i686 on linux,redhat fedora 14. Using alpine 2.02 and Kmail 1.13.5 i have one IMAP connection to the dovecot server and one IMAP connection to a MS exchange server. After i moved a few messages from the exchange server i cannot open the folders where i placed the moved mails. instead dovecot crashes, all other directories and emails work fine. here is what i see

Hi everybody, sometimes we have an Asterisk-crash, but no clue why this is happening, so I'm trying to make a coredump to analyse it. I compiled Asterisk 1.4.20.1 on CentOS 5.4 i386 with "DEBUG_THREADS" and "DONT_OPTIMIZE", then I start it with: # /bin/bash /usr/sbin/safe_asterisk This should do an "ulimit -c unlimited", but I entered it in the terminal again.

[spstarr@coredump]# smbclient //coredump/ -U spstarr added interface ip=192.168.10.2 bcast=192.168.10.255 nmask=255.255.255.0 Password: Domain=[SH0N.NET] OS=[Unix] Server=[Samba 2.2.5] tree connect failed: NT_STATUS_BAD_NETWORK_NAME Yet, if I do smbclient -L coredump -U spstarr, it displays the list of shares! I've never seen this before and I'm not sure why this is occuring, When

Hi, we are getting some core dumps with signal 6 in ltmp on a dovecot director proxy server, like this: Dec 5 14:31:51 sproxy1 dovecot: lmtp(29999): Panic: file lmtp-proxy.c: line 376 (lmtp_proxy_output_timeout): assertion failed: (proxy->data_input->eof) Dec 5 14:31:51 sproxy1 dovecot: lmtp(29999): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0() [0x363323d99a] ->

2015-05-28 12:04 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>: > On 28.05.2015 09:29, NoxDaFox wrote: > > Greetings, > > > > I am dumping a guest VM memory for inspection using the command > > "virDomainCoreDumpWithFormat" and the created files appear to belong to > > root (both user and group). > > > > I have searched around but

On Tue, Feb 14, 2017 at 2:51 PM, George Joseph <gjoseph at digium.com> wrote: > > > On Tue, Feb 14, 2017 at 10:21 AM, Olivier <oza.4h07 at gmail.com> wrote: > >> Hello, >> >> I've got a 13.13.1 system using PJSIP stack on debian Jessie. >> It runs from 50 to 100 simultaneous calls (so 100 to 200 PJSIP channels) >> all day long. >>

Hello, I've got a 13.13.1 system using PJSIP stack on debian Jessie. It runs from 50 to 100 simultaneous calls (so 100 to 200 PJSIP channels) all day long. >From time to time, roughly meaning once a month, it segfaults with lines (from dmesg -T output) like this: asterisk[1160]: segfault at 7efffffe ip 00000000005881d6 sp 00007fec95c33910 error 4 in asterisk[400000+2a2000] Debug level

I am unable to locate systemd-coredump service on CentOS 7.5. It is not listed under "systemctl -a" and also I'm unable to locate the associated unit file (folder /usr/lib/systemd/system/ ). Am I missing any package which installs this service?

It might not be a fault in dovecot, as the user is accessing the folder locally with alpine while also running imap-sessions. However it would have been nice with a more graceful action than panic? The panic is preceeded by Error: Next message unexpectedly corrupted in mbox file PATH Panic: file mbox-sync.c: line 152 (mbox_sync_read_next_mail): assertion failed:

On 13/2/19 12:28 am, Tomasz Chmielewski wrote: > On 2019-02-12 22:12, Håvard Rabbe wrote: >> Hi >> Im running tinc 1.1pre17. My problem is that my tinc nodes >> occasionally crashes. When it crashes the tinc node is not running >> anymore. Time between failure can be sometimes days or weeks. >> >> Do anyone here have a proposal for how to debug and get this

On Thu, Jun 13, 2019 at 16:01:18 +0200, Lentes, Bernd wrote: > > ----- On Jun 13, 2019, at 1:08 PM, Bernd Lentes bernd.lentes@helmholtz-muenchen.de wrote: > > I found further information in /var/log/messages for both occurrences: > > 2019-06-01T03:05:31.620725+02:00 ha-idg-2 systemd-coredump[14253]: Core Dumping has been disabled for process 30590 (qemu-system-x86). >

OK, got it (my fault, as always, put the LimitCORE in the wrong line). Here is the stack trace: > On 14. Jan 2019, at 10:33, Joan Moreau via dovecot <dovecot at dovecot.org> wrote: > > Difficult to figure out without a coredump + gdb > > > > I have also battled quite a lot to make sure dovecot can core dump on my Archlinux servers. > > I remember that the

I start asterisk 13.7.2 and it dies before I can rasterisk into it. I've tried getting a coredump, but it doesn't coredump. I know there are a lot of errors in the log below, but most of those just say it'll not load a module, and no big deal. When launching from commandline (not service script) here is what happens. http://pastebin.com/3GFe6fG9 Travis Ryan Director of