1

I'm using linux:

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic

I noticed a few weeks ago that there is a file in my home directory: dead.letter. The file is updating at the first second of every minute with the same number of log line.

I have been searching for the process that cause this over a week for now and still can't find it.

I've tried https://www.baeldung.com/linux/find-process-file-is-busy + auditctl, killing and uninstalling docker, verifying multiple location where cron jobs may be. Disabling the cron process.

+ mail sendmail and mailx commands are not recognized.

I can't find the process that causes this.

Please help.

Roy
  • 31
  • Maybe this will help: https://unix.stackexchange.com/questions/3259/what-does-dead-letter-files-do – QuartzCristal Sep 22 '22 at 05:19
  • Or this: https://askubuntu.com/questions/851629/what-does-this-dead-letter-file-talking-about-a-smart-warning-mean – QuartzCristal Sep 22 '22 at 05:20
  • do you have a cronjob that runs every minute? What does cron -l show? cron will attempt to mail on behalf of the user if there is stdout or stderr. If you add > /dev/null 2> /dev/null to a cronjob it will not have any output to attempt to mail. – toppk Sep 22 '22 at 05:31
  • @toppk I have one job but it is not the job that generates the files. Even when commenting it out and even shutting down the cron service the file still getts updating. – Roy Sep 23 '22 at 17:29
  • @QuartzCristal I already looked at both these threads. Sadly I still haven't to resolve the issue. – Roy Sep 23 '22 at 17:30
  • If there are more than one user (at minimum: root and you), you should check the cron entries for all those users. In specific, there is a /etc/crontab with root privileges and (at least) one crontab file per user inside /var/spool/cron/crontabs. Do not edit this files directly, use crontab -l while logged in as an user to see the crontab of that user and execute sudo crontab -u root -l to list root crontab (or crontab -l while logged in as root). – QuartzCristal Sep 24 '22 at 03:50

2 Answers2

2

Found the problem: We use nfs mounts in our organization. We also use AWS.

We created a new instance from an ec2 instance I was working on. The template instance had a cron job, that kept running on the new instance, and writing data to the shared directory.

Roy
  • 31
0

you can give it what it wants, by installing mailx/sendmail, or just create a simple fake in /usr/bin/mailx

#!/bin/bash
echo "$@" > /tmp/mailx.$$.args
pstree $$ > /tmp/mailx.$$.pstree
env > /tmp/mailx.$$.env
cat > /tmp/mailx.$$.cat

hopefully it will fall for the trick and you can see whats in /tmp/mailx.* maybe that will help discover the source. The other option is to use something like bcc/bpftrace but getting that to work on old ubuntu may be too difficult.

Another trick would just to put a sleep 20 inside the /bin/mailx script and use that time to do a pstree and find the calling process.

toppk
  • 657