Women in Technology

Hear us Roar

  Configuring sendmail on Jaguar
Subject:   What is purpose of 2nd sendmail session?
Date:   2003-01-02 11:56:17
From:   docwalker
In general, sendmail works for me. I am able to send and receive email to external email addresses from my local machine. I've noticed strange errors in the logs though.

In /System/Library/StartupItems/Sendmail/Sendmail, the following lines open two instances of sendmail:

/usr/sbin/sendmail -bd -q1h
/usr/sbin/sendmail -C /etc/mail/submit.cf -q1h

What is the purpose of the second one. I noticed that the 1st one runs as root and the second one runs as smmsp. What's the significance of this?

Also, I keep getting an hourly error in CrashReporter. It used to dump the error in the console.log, but I created the file with the correct permissions in the CrashReport directory. It appears to do with the -q1h settings above since something happens each 1 hour.

Jan 2 13:10:29 xxx crashdump: Couldn't find or create: /etc/mail/Library/Logs/CrashReporter
Jan 2 13:10:29 xxx crashdump: Crash report written to: /Library/Logs/CrashReporter/sendmail.crash.log

Date/Time: 2003-01-02 13:10:29 -0600
OS Version: 10.2.3 (Build 6G30)
Host: xxx

Command: sendmail
PID: 1056

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
#0 0x9007a1f0 in dns_is_local_name
#1 0x9007a4a4 in res_send
#2 0x90079610 in res_query
#3 0x90079b2c in res_querydomain
#4 0x90079980 in res_search
#5 0x0001ff90 in getmxrr
#6 0x0001f918 in hostsignature
#7 0x0004c1a0 in sendtoargv
#8 0x00049f64 in recipient
#9 0x00036da8 in maplocaluser
#10 0x0004a504 in recipient
#11 0x0003ca68 in doworklist
#12 0x0003b6c0 in dowork
#13 0x0004148c in set_def_queueval
#14 0x0003a0c0 in run_work_group
#15 0x000395b8 in runqueue
#16 0x00006394 in main
#17 0x000019a8 in start
#18 0x00001828 in start

I cannot seem to find any info on the thread 'dns_is_local_name'. Is this causing the problem? If so, what's the fix? Is it related to the following mail.log error:

Jan 2 13:10:27 xxx sendmail[1051]: gethostbyaddr( failed: 3


Full Threads Oldest First

Showing messages 1 through 5 of 5.

  • What is purpose of 2nd sendmail session?
    2003-09-19 14:28:06  anonymous2 [View]

    could be related to the permissions on the binary & queue directory - http://www.sendmail.org/compiling.html has a section on correcting it manually for some instances of Mac OS X
  • What is purpose of 2nd sendmail session?
    2003-02-18 09:03:42  info@cilly.com [View]

    The second process is for queueing local submits. This crashdump is produced, if the dir /var/spool/clientmqueue is not empty and cannot be emptied or has items in queue which can't be managed by the daemon anymore, since they are too old.

    First kill all your sendmail-processes, then sudo rm -Rf /var/spool/clientmqueue and finally start sendmail again with /System/Library/StartupItems/Sendmail/Sendmail start hopefully the crashdump will disappear. Also delete sendmail.crash.log since it may have grown to a large crash file. ;-)

    Michael C. Haller
  • What is purpose of 2nd sendmail session?
    2003-02-17 04:09:41  anonymous2 [View]

    I have the same problems, with or without DNS-Server:

    root 467 0.0 0.0 1944 392 ?? Ss 5:41AM 0:01.22 /usr/sbin/sendmail -bd -q15 -L sm-mta
    smmsp 470 0.0 0.0 1944 316 ?? Ss 5:41AM 0:00.06 /usr/sbin/sendmail -Ac -q15 -L sm-msp-queue

    Since -C is for debugging only, I deleted the netinfo entry and use -Ac instead. Also from the manpages:

    -C <file> Use alternate configuration file.
    Sendmail refuses to run as root if an alternate configuration file is specified.
  • What is purpose of 2nd sendmail session?
    2003-02-01 14:08:12  anonymous2 [View]

    I am seeing the same crash report reported by docwalker on multiple OS X machines. Anyone know what the story is?
    • What is purpose of 2nd sendmail session?
      2003-08-11 11:22:04  murphyatgenome [View]

      I get these errors if I am not running sendmail as a server on the box, but something tries to send mail to users on the box. Cron jobs try to do this if the job generates any output, and in my case all these crashes were related to cron jobs. This aspect of the problem can be solved by putting a line like:
      at the top of cron files, where your_real_email_address is what you think it is. If the messages are innocuous and annoying the best way to deal with them is a mail filter rule that is very specific to the innocuous error message - that way, if your cron job ever runs into _real_ trouble, you will notice. This is better than simply redirecting all cron job output to /dev/null, at least for some things.