This is a *very* belated bug report. I suspect that the issue exists on all platforms but I have only been using nmh on amd64. It appears that nmh is not one of gentoo's best selling packages. :-) The following are my notes from when I was tracking down the problem. I will attach the ebuild patch which I have been using daily without incident for 2+ years. I never did persue the dotfilelocking approach mostly because I was unwilling to deleve deep enough into all the possible interactions of locking policies in all possible combinations of mail processing programs. But maybe adding net-libs/liblockfile to the nmh dependency list would also provide a solution to the problem. ===================Notes=================== man mh-tailor gives clues about mts interface customization. /etc/nmh/mts.conf mts:smtp mts:sendmail are options sendmail:/path/to/sendmail is an option too set mts.conf mts:sendmail no change int time to send took out postproc:spost from mh_profile post could not contact server - something is not working as expected. spost, mts:sendmail, servers:smtp.nbnet.nb.ca => What now? whom Fcc: outgoing -bv is meaningless to sSMTP post, mts:sendmail, servers:smtp.nbnet.nb.ca => What now? whom -- Network Recipients -- fellows at unb.ca still not quite right still 25 sec delay put spost back in, timed sending a message - no cpu time spent ps during the waiting period showed spost process at end a "send-mail -m -t -i -v" command modified spost and ebuilt send still waits 30 sec. modified push.c same way - same result the idiom for (i = 0; (child_id = vfork()) == NOTOK && i < 5; i++) sleep (5); switch (child_id) { is usedd in many other routines. Who knows which one is the culprit? (if any). what i did <code> ebuild nmh-1.1.ebuild clean unpack cd /var/tmp/portage/nmh-1.1/work/nmh sed -i -s -e "s/sleep (5)/sleep (0)/" mts/smtp/*.c sbr/*.c uip/*.c sed -i -s -e "s/sleep(5)/sleep (0)/" mts/smtp/*.c sbr/*.c uip/*.c grep sleep mts/smtp/*.c sbr/*.c uip/*. #to check cd /usr/portage/mail-client/nmh ebuild nmh-1.1.ebuild compile |tee comp.out ebuild nmh-1.1.ebuild install qmerge </code> I think this caught all the instances of the code idiom and at least set the delay to a small #. send -verbose -watch now does its thing without delay Tried rebuilding with -O1 and no optimization during compile : the delays are still there. 2004-09-11 made 2 sets of patches - 1 for all the fork sleeps and one for file locking sleeps. Applied separately. fork sleeps are NOT the problem! File locking sleeps are. Dug into problem in sbr/lock_file.c procmail used (all of) lockf flock fcntl file locking. nmh default file locking is dotfilelocking which seems to be a debianisn There is a gentoo package but it is not installed. I think this is the source of the delays (trying to interpret the ifdefs in sbr/lock_file.c. Anyway I decided that lockf (Posix) would be a better choice and compatible with procmail. Added --with-locking=lockf to the .configure parameters in the .ebuild Rebuilt (with no patches). success! ================================================ Current emerge --info. It was somewhat different in 2004! $ emerge --info Portage 2.1.1-r1 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r7 x86_64) ================================================================= System uname: 2.6.17-gentoo-r7 x86_64 AMD Opteron(tm) Processor 246 Gentoo Base System version 1.12.5 Last Sync: Fri, 27 Oct 2006 10:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://adelie.polymtl.ca/ http://gentoo.mirrored.ca/ http://gentoo.osuosl.org/ " MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa berkdb bitmap-fonts cli cracklib crypt cups dbus dlloader doc dri eds elibc_glibc emboss encode foomaticdb fortran gcj gif gnome gpm gstreamer gtk gtk2 guile imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog java jpeg kde kernel_linux lzw lzw-tiff mp3 mpeg ncurses nls nptl nptlonly nsplugin opengl pam pcre perl png pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userland_GNU video_cards_fbdev video_cards_nv video_cards_radeon video_cards_vesa video_cards_vga xorg xpm xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 101062 [details, diff] patch to add file locking to nmh
Does 1.3 fix this bug too?
(In reply to comment #2) > Does 1.3 fix this bug too? > Yes. But see bug # 250340. The delays are gone. I don't know that mutual exclusion is necessarily performed correctly.
Well, we shall wait for nmh-1.3 to get stabled instead of fixing this one.(In reply to comment #1) > Created an attachment (id=101062) [edit] > patch to add file locking to nmh > Ok, 1.3 fixes this issue (I think). But I applied your file locking patch to configure call anyway. (w/o a revision bump). Thanks for working on this. (and sorry for the extreme delay)
