I did a portupgrade from vpopmail 5.4.27 to 5.4.28 and the next day in my security reports I was seeing multiple core dumps of vdelivermail like so: cw-melb-02.siz.com.au kernel log messages: +++ /tmp/security.vxyq3ILQ 2009-12-06 03:04:44.000000000 +1100 +pid 86745 (vdelivermail), uid 1003: exited on signal 11 (core dumped) +pid 86776 (vdelivermail), uid 1003: exited on signal 11 (core dumped) +pid 86810 (vdelivermail), uid 1003: exited on signal 11 (core dumped) +pid 86835 (vdelivermail), uid 1003: exited on signal 11 (core dumped) The same thing continues on and on within the report. I did some minor troubleshooting and when investigating the qmail-send logs I would see this multiple times: 2009-12-05 18:57:49.800479500 delivery 161995: deferral: client_connect:_warning:_config_begin_failed/Segmentation_fault_(core_dumped)/ I uninstalled and reinstalled vpopmail with the following commands: # cd /usr/ports/mail/vpopmail # make CONFIGURE_ARGS="--enable-logging=p --enable-onchange-script" # make install clean and I was still getting the error. I tried it without the --enable-onchange-script and even just a plain make install clean on the vpopmail port. I did about an hours worth of troubleshooting and decided to portdowngrade to 5.4.27. Once I did this, My mail deliveries started working again and my queue was dropping. Fix: I could not fix it. I had to downgrade to vpopmail 5.4.27 until this fix is addressed. How-To-Repeat: Install vpopmail accoring to this guide: http://freebsdrocks.net/index.php?option=com_content&task=view&id=74&Itemid=25 Or if you don't have qmail installed, you would need to start at the beginning of the guide: http://freebsdrocks.net/index.php?option=com_content&task=view&id=19&Itemid=25
Responsible Changed From-To: freebsd-i386->freebsd-ports-bugs This is something ports-ish
Responsible Changed From-To: freebsd-ports-bugs->roam Assign to maintainer
State Changed From-To: open->analyzed I am looking into this.
Still crashing on 7.2-RELEASE amd64 with vpopmail 5.4.30. downgraded to 5.4.27 everithing goes fine
State Changed From-To: analyzed->feedback Can you check if this is still the case with the upstream fix in vpopmail-5.4.30_1 that I just committed?
On Mon, Jan 11, 2010 at 05:10:04PM +0000, Cristiano Deana wrote: > Still crashing on 7.2-RELEASE amd64 with vpopmail 5.4.30. > downgraded to 5.4.27 everithing goes fine Can you check if this is still the case with the upstream fix in vpopmail-5.4.30_1 that I just committed? G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am jealous of the first word in this sentence.
State Changed From-To: feedback->analyzed The PR submitter reports success, but Cristiano Deana is still having some trouble. I'll look into it a bit deeper.
roam 2010-02-09 13:19:41 UTC FreeBSD ports repository Modified files: mail/vpopmail Makefile pkg-plist mail/vpopmail/files patch-Makefile.in Added files: mail/vpopmail/files patch-vusagec.conf Log: Another attempt at fixing the vpopmail-5.4.30 local delivery problem: fix the upstream Makefile's logic and actually install vusage.conf, while disabling the vusagec/vusaged check since we don't even install vusaged on FreeBSD. Pointed out by: garga PR: 141251 (hopefully for real this time!) Revision Changes Path 1.81 +1 -1 ports/mail/vpopmail/Makefile 1.10 +4 -2 ports/mail/vpopmail/files/patch-Makefile.in 1.1 +17 -0 ports/mail/vpopmail/files/patch-vusagec.conf (new) 1.19 +3 -0 ports/mail/vpopmail/pkg-plist _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
On Tue, Feb 09, 2010 at 03:25:18PM +0200, Peter Pentchev wrote: > On Thu, Jan 14, 2010 at 12:06:20PM +0100, Cristiano Deana wrote: > > On 1/14/10 10:41 AM, Peter Pentchev wrote: > > > On Mon, Jan 11, 2010 at 05:10:04PM +0000, Cristiano Deana wrote: > > >> Still crashing on 7.2-RELEASE amd64 with vpopmail 5.4.30. > > >> downgraded to 5.4.27 everithing goes fine > > > > > > Can you check if this is still the case with the upstream fix in > > > vpopmail-5.4.30_1 that I just committed? > > > > Still not working. Now i have: > [snip] > > client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ > > Can you check again with the just-committed vpopmail-5.4.30_2? > > Thanks a lot for your patience in tracking this down! :( Oops, sorry, it's bug-followup@, not bugs-followup@. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If you think this sentence is confusing, then change one pig.
On 2/9/10 2:29 PM, Peter Pentchev wrote: >>>> Can you check if this is still the case with the upstream fix in >>>> vpopmail-5.4.30_1 that I just committed? >>> >>> Still not working. Now i have: >> [snip] >>> client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ >> >> Can you check again with the just-committed vpopmail-5.4.30_2? still the same: new msg 47610 info msg 47610: bytes 10664 from <xxxxx@xxxxxx> qp 31707 uid 89 starting delivery 149708: msg 47610 to local yyyyyyyyy-xxxxxx@yyyyyyyyy status: local 1/10 remote 1/100 new msg 47613 info msg 47613: bytes 10664 from <xxxxx@xxxxxx> qp 31708 uid 89 starting delivery 149709: msg 47613 to local yyyyyyyyy-xxxxxx@yyyyyyyyy status: local 2/10 remote 1/100 delivery 149709: success: client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ status: local 1/10 remote 1/100 end msg 47613 delivery 149708: success: client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ status: local 0/10 remote 1/100 end msg 47610
On Wed, Feb 10, 2010 at 10:12:51AM +0100, Cristiano Deana wrote: > On 2/9/10 2:29 PM, Peter Pentchev wrote: > > >>>> Can you check if this is still the case with the upstream fix in > >>>> vpopmail-5.4.30_1 that I just committed? > >>> > >>> Still not working. Now i have: > >> [snip] > >>> client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ > >> > >> Can you check again with the just-committed vpopmail-5.4.30_2? > > still the same: [snip] > client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ Hm, that's interesting. Can you please verify that you have a /usr/local/vpopmail/etc/vusagec.conf file, and that is has the (uncommented) "Server:" and "Disable = true;" lines? G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 Thit sentence is not self-referential because "thit" is not a word.
On 2/16/10 9:47 AM, Peter Pentchev wrote: Hi Peter, >> still the same: > [snip] >> client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ > > Hm, that's interesting. Can you please verify that you have > a /usr/local/vpopmail/etc/vusagec.conf file, and that is has > the (uncommented) "Server:" and "Disable = true;" lines? that's the problem. freebsd ports install a vusagec.conf-dist and not the vusagec.conf. cp vusagec.conf-dist vusagec.conf and it's all right. thanks for your waste of time Cris -- Cristiano Deana - FreeCRIS "Ho iniziato a usare FreeBSD perche' m$ usava me. ed e' spiacevole"
roam 2010-02-16 15:54:43 UTC FreeBSD ports repository Modified files: mail/vpopmail Makefile Log: Arrrrrgh. Really copy the vusagec.conf-dist file to vusagec.conf if the latter does not exist. The pkg-plist @exec commands are not, repeat not, executed at *port* install time! PR: 141251 (for REAL this time, honest!) Reported by: Cristiano Deana <cris@gufi.org> Feature safe: yes Revision Changes Path 1.82 +4 -1 ports/mail/vpopmail/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
On Tue, Feb 16, 2010 at 11:31:33AM +0100, Cristiano Deana wrote: > On 2/16/10 9:47 AM, Peter Pentchev wrote: > > Hi Peter, > > >> still the same: > > [snip] > >> client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/client_connect:_connect_failed:_47/did_0+0+1/ > > > > Hm, that's interesting. Can you please verify that you have > > a /usr/local/vpopmail/etc/vusagec.conf file, and that is has > > the (uncommented) "Server:" and "Disable = true;" lines? > > that's the problem. > freebsd ports install a vusagec.conf-dist and not the vusagec.conf. > cp vusagec.conf-dist vusagec.conf > and it's all right. > > thanks for your waste of time Ooooooooooops... No, thanks for YOUR wasted time! This was actually the whole point of the vpopmail-5.4.30_2 update - to install vusagec.conf as a disabled file. Unfortunately, I forgot that merely adding it to the packing list with an @exec copy command would not let it be installed for people who do "make install" for the port :) Not quite sure how this fix slipped by in my testing :( It should be fine now, in vpopmail-5.4.30_3. You could test it by removing the /usr/local/vpopmail/etc/vusagec.conf file and installing vpopmail-5.4.30_3 - it should copy the .dist file now. Alternatively, you might not do it, since it's exactly what you have done already :) Once again, thanks for bearing with me on this, and sorry for all the time it took to fix! G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 No language can express every thought unambiguously, least of all this one.
State Changed From-To: analyzed->closed It seems this is indeed fixed for everyone involved. Thanks to all of you for reporting the problem and for the patience!