I have seen this on a couple different servers. nullmailer is running according to ps, and svstat, but it is not sending, nor processing the queue. triggering a queue scan via: echo 1 > /var/nullmailer/trigger has NO effect. That is to say, the /var/log/nullmailer/current file is no updated, and no mail is processed. This is random, and as such, is not readily repeatable, but I have seen it more than enough times to determine it to be unstable - as have my clients. :( Running svc -t /service/nullmailer successfully restarts the process and mail is once again processed. Please help. I can provide any additional information needed. Thanks! -- Bill Arlofski
OOPS! Forgot the emerge --info: # emerge --info Portage 2.1.2.12 (default-linux/x86/2007.0, gcc-3.4.6, glibc-2.5-r4, 2.6.20-gentoo-r8 i686) ================================================================= System uname: 2.6.20-gentoo-r8 i686 Intel(R) Xeon(TM) CPU 3.00GHz Gentoo Base System release 1.12.9 Timestamp of tree: Wed, 28 Nov 2007 08:00:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17 dev-lang/python: 2.3.5-r3, 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/terminfo" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://www.gtlib.cc.gatech.edu/pub/gentoo" MAKEOPTS="-j8" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/usr/portage_tmpdir" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage_overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl apache2 berkdb cli cracklib crypt cups dri foomaticdb fortran gdbm gpm iconv ipv6 isdnlog ldap logrotate midi mudflap mysql ncurses nls nptl nptlonly openmp pam pcre perl php postgres ppds pppd python qt readline reflection samba session snmp spl ssl tcpd unicode usb x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
can you reproduce this bug in nullmailer-1.04?
Per your request, v1.04 has been installed on this server. Additionally, to be sure that v1.04 is the one running, I have issued the following commands: svc -d /service/nullmailer svd -u /service/nullmailer Also, I have removed the nightly svc -t /service/nullmailer command from that server's crontab, but as I mentioned in my initial bug entry, this is pretty random and not readily reproducible, so we will have to wait and see. Thank you for the help, and I will report any issues I see. -- Bill Arlofski Reverse Polarity, LLC
Yes. I just noticed this similar behavior, but (possibly) for a different reason. I noticed on a server that I had not been getting emails from it for a few days. I checked to find a bunch of files in /var/nullmailer/queue svstat /service/nullmailer showed it up and running echo 1 > /var/nullmailer/trigger had no effect ps axf showed that ONE nullmailer-send process was 'running' supposedly delivering an email to our outbound server. ** additional info ** We have had some issues on this particular site recently where the firewall was spontaneously restarting killing any inbound or outbound connections in their tracks and I suspect that this one nullmailer-send process that was running was a casualty of a firewall reboot. (but that was several days ago and that process should have timed out at some point....) svc -t /service/nullmailer did the trick and all email in the queue was delivered. Thanks, and sorry it took so long to get back on this, but as I said, it is a difficult one to reproduce manually. So, it looks like (while a sort of hack) running svc -t /service/nullmailer once/per day is still a viable band-aide right now since it does seem to do the trick. Of course, I said band-aide as it is obviously not the best solution. :) Please let me know if there is anything else I can provide to help resolve this. -- Bill Arlofski
