Re: dma: could not pick up queue file

On Sun, Nov 3, 2024, at 3:32 AM, Daniel Tameling wrote:
> On Fri, Nov 01, 2024 at 06:37:24PM -0400, Dan Langille wrote:
>> There is something I'm not following.
>> 
>> [22:35 wikis dvl ~] % sudo /usr/libexec/dma -q
>> [22:35 wikis dvl ~] % sudo ps auwx | grep dma      
>> dvl    42469  0.0  0.1 12808  2376  2  S+J  22:35   0:00.00 grep dma
>> 
>> This tells me the daemon doesn't stick around. It starts, does stuff, goes away.
>> 
>> That does not match what we're seeing in the logs below.
>> 
>> If it is the daemon from the top of the hour, it's been sitting around for nearly 6 minutes.
>
> Maybe there is some periodic script that starts another dma?

Daniel, I think you've got it. What I found is also entirely consistent with what John was saying at well.

I'll show what I checked on my way to figuring out what it was, based on your clue.

I checked cron, and I'm sure it's not cron:

[13:25 wikis dvl ~] % sudo grep -r dma /var/cron/tabs
[13:25 wikis dvl ~] % sudo grep -r dma /etc/crontab
[13:27 wikis dvl ~] % sudo grep dma /var/log/cron  | egrep -ve ':00:|:30:'  
[13:27 wikis dvl ~] % 

The log grep checks for anything not starting on the hour or half hour.


Let's check periodic. Your idea turns out to be a likely suspect.

[13:27 wikis dvl ~] % grep -r dma /usr/local/etc/periodic 
[13:29 wikis dvl ~] % grep -r dma /etc/periodic          
/etc/periodic/daily/500.queuerun:	if [ ! -x /usr/sbin/sendmail ]
/etc/periodic/daily/500.queuerun:	    echo '$daily_queuerun_enable is set but /usr/sbin/sendmail' \
/etc/periodic/daily/500.queuerun:	    /usr/sbin/sendmail -q >/dev/null 2>&1 &
/etc/periodic/daily/500.queuerun:		    /usr/sbin/sendmail -q -Ac >/dev/null 2>&1 &
/etc/periodic/daily/150.clean-hoststat:	    echo "Removing stale entries from sendmail host status cache:"
/etc/periodic/monthly/200.accounting:oldmask=$(umask)
/etc/periodic/monthly/200.accounting:umask $oldmask

I think you're onto something.

Let's look at the enable variable for the first two scripts listed above (the third one is not relevant).

[13:32 wikis dvl ~] % grep enable /etc/periodic/daily/500.queuerun /etc/periodic/daily/150.clean-hoststat      
/etc/periodic/daily/500.queuerun:case "$daily_queuerun_enable" in
/etc/periodic/daily/500.queuerun:	    echo '$daily_queuerun_enable is set but /usr/sbin/sendmail' \
/etc/periodic/daily/150.clean-hoststat:case "$daily_clean_hoststat_enable" in


[13:33 wikis dvl ~] % grep daily_queuerun_enable /etc/periodic.conf /etc/defaults/periodic.conf 
/etc/defaults/periodic.conf:daily_queuerun_enable="YES"				# Run mail queue

That one runs by default.

[13:34 wikis dvl ~] % grep daily_clean_hoststat_enable  /etc/periodic.conf /etc/defaults/periodic.conf
/etc/periodic.conf:daily_clean_hoststat_enable="NO"
/etc/defaults/periodic.conf:daily_clean_hoststat_enable="YES"			# Purge sendmail host

That one is enabled by default, but disabled on this host.

Looking to see when daily periodic runs:

[13:35 wikis dvl ~] % grep daily /etc/crontab 
# Perform daily/weekly/monthly maintenance.
1	3	*	*	*	root	periodic daily


Given that each script in periodic runs in series (one after another), it is entirely possible that this may be the cause.  

Pasting the logs from the original post:

>>>  Nov  1 03:05:42 wikis dma[46d60][90243]: new mail from user=root uid=26 envelope_from=<root@wikis.[redacted]>
>>>  Nov  1 03:05:42 wikis dma[dma][90258]: could not pick up queue file: `/var/spool/dma/Q46d60.432a50848050'/`/var/spool/dma/M46d60.432a50848050': No such file or directory
>>>  Nov  1 03:05:42 wikis dma[46d60][90243]: mail to=<dan@example.org> queued as 46d60.432a50848050

It's entirely possible that process 90258 above relates to /etc/periodic/daily/500.queuerun

For the record, this is my mail configuration:

[13:54 wikis dvl ~] % cat /etc/mail/mailer.conf
sendmail      /usr/libexec/dma
mailq         /usr/libexec/dma
newaliases    /usr/libexec/dma
rmail         /usr/libexec/dma


Based on that, I'll add this to /etc/periodic.conf:

# disable queuerun_enable to avoid conflict with dma
daily_queuerun_enable="NO"

That comment is just to remind me what it's for.

Now it's just a matter of time. If there are no more incidents, I say you've solved it. Let's give it a few weeks.

Thank you. Good job. :)

-- 
  Dan Langille
  dan@langille.org