Unable To Deliver Mail

[Angela L. Shepherd]

I recently removed a user from one of my systems. I keep receiving the following messages in my /var/adm/syslog/mail file:

sendmail[14174]: PAB14174: PAC14174: return to sender: Unable to deliver mail

-- Start of included mail.
Return-Path:
Date: Wed, 11 Jul 2001 15:40:00 -0400 (EDT)
X-Authentication-Warning: machinename.day.disa.mil: Unknown UID 214 set sender to (username) using -f

Cron: can't change directory to your home directory.
Your commands will not be executed.

-- End of included mail.


I think the user was running a job that sent him mail. I
deleted the users directory and I can't find any cron job.

What else can I check?????

[Patrick Wallek · Accepted solution]

Have you checked all crontab files? If you are logged in as root go to /var/spool/cron/crontabs and do and do a 'grep username *' to see if there is something in one of the other users crontab files.

[James R. Ferguson]

Hi Angela:

See if you have a file in /var/spool/cron/crontabs with the uid=214.

...JRF...

[Joseph C. Denman]

Was this user in the cron.allow file? Check for cronfiles in /var/spool/cron/crontabs/

...jcd...

[Angela L. Shepherd]

I checked my crontab files, no UID=214 and the user not in the cron.allow file.

[Joseph C. Denman]

Do you have any cron entries for root? The user may have modified some of the scripts to email him/her of errors.

Just a thought.

...jcd...

[Satish Y]

Hi Angela,

You can solve this in 2 ways.

1) remove perticular user's file from /var/spool/cron/crontabs directory and stp/start cron

2) enter that user in cron.deny file.
Remember cron.deny will be checked only if cron.allow is not present, otherwise it is ignored. U can remove cron.allow if there are no users in it and create cron.deny with that perticular user.

Cheers...
Satish.

[Satish Y]

one more thing is u check that any of scripts sending mail to the user u removed. If yes, then stop sending mail to user.

Cheers...
Satish.

[MANOJ SRIVASTAVA]

Hi Angela

The user should have a file with the same name as that of the user in /var/mail directory with (660 ) permissions .

Try create a cron entry for that user , you should be able to do , if not then fix that and you are set to go

Manoj Srivastava

[James R. Ferguson]

Hi Angela:

Try stopping and restarting 'cron':

# /sbin/init.d/cron stop
# /sbin/init.d/cron start

Does the problem disappear?

Remember that you can look at /var/adm/cron/log. This file shows the cron tasks run -- the times and commands or scripts.

...JRF...

[Angela L. Shepherd]

Please close this issue. I stopped and restarted cron.
Thank you very much. You guys are great.

[Jack Werner]

From the information contained in this dialogue it is unclear how this problem was resolved. Simply recycling the cron process will have no effect unless a crontab has been changed manually. (ie by root) If the crontab command is used to create or modify an existing crontab, cron is signalled and will refresh its internal representation of the crontab being created/modified. Unless Angela found which crontab was scheduling the script that was issuing sendmail and modified the crontab itself, I repeat, recycling the cron process would make no difference. Even if the script was changed, there would be no need to recycle cron. Am I missing something?

[Angela L. Shepherd]

Yes, I found the job in cron. However, I was still receiving messages. I stopped/restarted cron and didn't receive messages anymore.