On Tue, 2009-03-03 at 12:36 -0800, Mark Hedges wrote:
> > It should have logged something different though? Like
> > appending "(core not dumped - is the home dir ok?)"
>
> Ah yes.
>
> Mar 3 12:34:14 anubis dovecot: child 27262 (pop3) killed
> with signal 11 (core not dumped - is home dir set?)
On Tue, 3 Mar 2009, Timo Sirainen wrote:
> > > http://hg.dovecot.org/dovecot-1.1/rev/6e9ca7f7e2a1
> >
> > Nope. Applied this to a pristine source. Still nothing.
>
> It should have logged something different though? Like
> appending "(core not dumped - is the home dir ok?)"
Ah yes.
Mar 3 12:3
On Tue, 2009-03-03 at 08:34 -0800, Mark Hedges wrote:
> > Done, also improved logging:
> >
> > http://hg.dovecot.org/dovecot-1.1/rev/6e9ca7f7e2a1
>
> Nope. Applied this to a pristine source. Still nothing.
It should have logged something different though? Like appending "(core
not dumped - is t
On Mon, 2 Mar 2009, Timo Sirainen wrote:
> > I tried using a pristine 1.1.11 source build with a
> > core_pattern directory that was owned by root, or by
> > dovecot, or by the user, but I still didn't see a core
> > there.
>
> In my setups it core dumps to the user's home directory
> just fine.
On Mon, Mar 02, 2009 at 01:25:43PM -0800, Mark Hedges wrote:
> On Fri, 27 Feb 2009, Timo Sirainen wrote:
> > Ah, this explains everything. Fixed both your problem and
> > the segfault: f831d12187d1
>
> Yes, this patch fixed the problem when applied to pristine
> 1.1.11 source.
>
> Will there be a
On Mar 2, 2009, at 8:22 PM, Timo Sirainen wrote:
On Mar 2, 2009, at 7:32 PM, Mark Hedges wrote:
On Mon, 2 Mar 2009, Timo Sirainen wrote:
I was rather thinking that maybe the kernel doesn't want
to write core files to directories that are writable by
everyone.
Could it be that dovecot uses
On Mar 2, 2009, at 7:32 PM, Mark Hedges wrote:
On Mon, 2 Mar 2009, Timo Sirainen wrote:
I was rather thinking that maybe the kernel doesn't want
to write core files to directories that are writable by
everyone.
Could it be that dovecot uses setuid to change permissions?
Application would nee
On Mon, 2 Mar 2009, Timo Sirainen wrote:
> I was rather thinking that maybe the kernel doesn't want
> to write core files to directories that are writable by
> everyone.
Could it be that dovecot uses setuid to change permissions?
Application would need 'prctl(PR_SET_DUMPABLE, 1);'
according to ht
On Mon, 2009-03-02 at 13:25 -0800, Mark Hedges wrote:
> On Fri, 27 Feb 2009, Timo Sirainen wrote:
> > core dumping functionality is there, but I guess the
> > problem has more to do with directory owner/permissions
> > where it's writing the core file.
>
> I was never able to get the cores to work
On Fri, 27 Feb 2009, Scott Silva wrote:
> > On Thu, 26 Feb 2009, Scott Silva wrote:
> >> http://kbase.redhat.com/faq/docs/DOC-4897 shows how ...
> >
> > Thanks for trying to help, I tried this too, but as I
> > reported earlier, I had tried according to the ...
> >
> Did you do it like that kb art
Words by Jose Celestino [Sat, Feb 28, 2009 at 12:17:24AM +]:
> Words by Timo Sirainen [Fri, Feb 27, 2009 at 05:41:39PM -0500]:
> >
> > core dumping functionality is there, but I guess the problem has more to
> > do with directory owner/permissions where it's writing the core file.
> >
>
> ec
Words by Timo Sirainen [Fri, Feb 27, 2009 at 05:41:39PM -0500]:
> On Fri, 2009-02-27 at 14:28 -0800, Mark Hedges wrote:
> > > b) Kernel doesn't want to write the core to /tmp/core or
> > > before changing that it didn't want to write it to user's
> > > home directory.
> >
> > [r...@anubis etc]# gr
On Feb 27, 2009, at 6:31 PM, Scott Silva wrote:
When Dovecot starts up, it logs a line:
Info: Dovecot v1.1.11 starting up
Do you see it, or do you see:
Info: Dovecot v1.1.11 starting up (core dumps disabled)
..
Did you do it like that kb article said, or did you just try;
ulimit -c unlimite
on 2-27-2009 1:40 PM Mark Hedges spake the following:
>
> On Thu, 26 Feb 2009, Timo Sirainen wrote:
>
>> On Thu, 2009-02-26 at 15:04 -0800, Mark Hedges wrote:
>>> On Thu, 26 Feb 2009, Timo Sirainen wrote:
>>>
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
> Feb 26 14:14:06 anubis
Mark Hedges wrote:
>
> On Fri, 27 Feb 2009, Timo Sirainen wrote:
>> OK, so core dumps are enabled, but for some reason they
>> don't get written. There are really only two possibilities
>> then:
>>
>> a) You don't really have mail_drop_priv_before_exec=yes.
>> You could verify this with dovecot -n
On Fri, 2009-02-27 at 14:28 -0800, Mark Hedges wrote:
> > b) Kernel doesn't want to write the core to /tmp/core or
> > before changing that it didn't want to write it to user's
> > home directory.
>
> [r...@anubis etc]# grep -i core
> /boot/config-2.6.18-92.1.22.el5
> CONFIG_ELF_CORE=y
> # Core Ne
On Fri, 27 Feb 2009, Timo Sirainen wrote:
> OK, so core dumps are enabled, but for some reason they
> don't get written. There are really only two possibilities
> then:
>
> a) You don't really have mail_drop_priv_before_exec=yes.
> You could verify this with dovecot -n.
[r...@anubis etc]# /usr/l
On Fri, 2009-02-27 at 13:40 -0800, Mark Hedges wrote:
> > > > It shouldn't be crashing. Could you get a gdb backtrace from this?
> > > > http://dovecot.org/bugreport.html
> > >
> > > I set mail_drop_priv_before_exec = yes, and I did `ulimit -c
> > > unlimited` and `echo "/tmp/core" >
> > > /proc/sy
On Thu, 26 Feb 2009, Timo Sirainen wrote:
> On Thu, 2009-02-26 at 15:04 -0800, Mark Hedges wrote:
> >
> > On Thu, 26 Feb 2009, Timo Sirainen wrote:
> >
> > > On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
> > > > Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
> >
on 2-26-2009 3:29 PM Mark Hedges spake the following:
>
> On Thu, 26 Feb 2009, Scott Silva wrote:
>
>>> On Thu, 26 Feb 2009, Timo Sirainen wrote:
>>>
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
> Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
It s
On Thu, 2009-02-26 at 15:04 -0800, Mark Hedges wrote:
>
> On Thu, 26 Feb 2009, Timo Sirainen wrote:
>
> > On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
> > > Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
> >
> > It shouldn't be crashing. Could you get a gdb back
On Thu, 26 Feb 2009, Scott Silva wrote:
> > On Thu, 26 Feb 2009, Timo Sirainen wrote:
> >
> >> On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
> >>> Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
> >> It shouldn't be crashing. Could you get a gdb backtrace from th
on 2-26-2009 3:25 PM Scott Silva spake the following:
> on 2-26-2009 3:04 PM Mark Hedges spake the following:
>> On Thu, 26 Feb 2009, Timo Sirainen wrote:
>>
>>> On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
>>> I
on 2-26-2009 3:04 PM Mark Hedges spake the following:
>
> On Thu, 26 Feb 2009, Timo Sirainen wrote:
>
>> On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
>>> Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
>> It shouldn't be crashing. Could you get a gdb backtrace fr
On Thu, 26 Feb 2009, Timo Sirainen wrote:
> On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
> > Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
>
> It shouldn't be crashing. Could you get a gdb backtrace from this?
> http://dovecot.org/bugreport.html
I set mail_dr
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
> Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
It shouldn't be crashing. Could you get a gdb backtrace from this?
http://dovecot.org/bugreport.html
> Feb 26 14:14:06 anubis dovecot: POP3(despam_test_anubis):
> file
On Thu, 26 Feb 2009, Mark Hedges wrote:
>
> On Thu, 26 Feb 2009, Timo Sirainen wrote:
>
> > On Thu, 2009-02-26 at 12:59 -0800, Mark Hedges wrote:
> >
> > > Right, mail_privileged_group does not work. Setting
> > > mail_access_groups = mail does work.
> > >
> > > The problem is the same in v1.1.1
On Thu, 26 Feb 2009, Timo Sirainen wrote:
> On Thu, 2009-02-26 at 12:59 -0800, Mark Hedges wrote:
>
> > Right, mail_privileged_group does not work. Setting
> > mail_access_groups = mail does work.
> >
> > The problem is the same in v1.1.11, which is the latest
> > stable version from the atrpms
On Thu, 2009-02-26 at 12:59 -0800, Mark Hedges wrote:
> Right, mail_privileged_group does not work. Setting
> mail_access_groups = mail does work.
>
> The problem is the same in v1.1.11, which is the latest
> stable version from the atrpms site linked from dovecot.org
> download for binary packa
On Thu, 26 Feb 2009, Timo Sirainen wrote:
> > Setting mail_access_groups works, but the documentation
> > says this is what the mail_privileged_group setting was
> > for:
>
> Oh, right, that's what I meant.
>
> > Is it possible that dovecot internally forgets that
> > creating the dotlock file is
on 2-25-2009 5:55 PM Mark Hedges spake the following:
> I have to make dotlock work because this openwebmail thing
> only supports one of dotlock or flock, but procmail delivery
> does dotlock and fcntl. procmail correctly creates a
> dotlock file in /var/spool/mail/username.lock when
> delivering
On Thu, 2009-02-26 at 10:01 -0800, Mark Hedges wrote:
> > Or you could set mail_access_groups (or perhaps it's still
> > called mail_extra_groups in your version) to "mail",
> > assuming /var/spool/mail was owned by group mail and was
> > group-writable.
>
> Setting mail_access_groups works, but t
On Thu, 26 Feb 2009, Timo Sirainen wrote:
> On Feb 25, 2009, at 8:55 PM, Mark Hedges wrote:
>
> > I tried making all of the binaries root:mail with g+s,
> > same as /usr/bin/lockfile, but this was no help.
>
> It doesn't, because Dovecot starts them as root and then
> changes the privileges.
>
>
On Feb 25, 2009, at 8:55 PM, Mark Hedges wrote:
I tried making all of the binaries root:mail with g+s, same
as /usr/bin/lockfile, but this was no help.
It doesn't, because Dovecot starts them as root and then changes the
privileges.
It also does not help to chmod +t /var/spool/mail.
May
I have to make dotlock work because this openwebmail thing
only supports one of dotlock or flock, but procmail delivery
does dotlock and fcntl. procmail correctly creates a
dotlock file in /var/spool/mail/username.lock when
delivering, I can watch this with `while :; do ls -la | grep
lock; done`.
35 matches
Mail list logo
