old files

UserPreferences

Daemons on each SyncFep continually search for files in various directories that have been sitting there "too long". Sometimes this is normal and can be ignored; other times it is a symptom that message processing is not proceeding correctly and some action is required.

There are several different "old files" situations, and each is handled differently.

1. lineNN.N has old files
2. /usr/mail/account has old files
3. /mail/junkmail or /mail/adm/dead has old files
4. /usr/account/msgq has old files
5. /usr/account/sendq has old files
6. /no05000/mime/in has old files

lineNN.N has old files

Message files on SyncFep boxes come in pairs; the actual message, and an associated TAG, which is a sort of index file. If a message is not received in its entirety, the TAG will not be properly created.

1. The command lsline NN.N will do an ls -l in /usr/lineNN.N/backup and /usr/spool/lineNN.N/output and will delete any files in those directories smaller than 200 characters. (Files that are zero length or so small they contain no useful data may be deleted.)
2. If the file seems to have significant data, it should be moved out of the way so that processing may continue. Customer service will notify the client.
1. Examine the file to determine what client is involved. Most files are EBCDIC format, so use the EBCDIC-ASCII converter gaf:

gaf -ux filename | pg

2. If /usr/accountname/savefiles/status exists, move the file there; otherwise, move it to /usr/atspud1/savefiles/status
• You may use the command /usr/bin/sast filename account to do the file move. Note that you must (1) be in the output or backup directory, and (2) must only do one file at a time.
3. Open a ticket (CTI GMS-Daily Maintainance-Moved Files) notifying of the files moved.

It would be nice if someone implemented OldFileMover.

echo "mv \$1 /usr/\$2/savefiles/status 
CURDIR=\`pwd\` 
echo "On" \`uname\` \"moved \$1 from \$CURDIR to /usr/\$2/savefiles/status\"" > /usr/bin/sast 
chmod u+x /usr/bin/sast 
cat > /usr/bin/lsline 
#!/bin/sh 
find /usr/line$1/backup -type f -size -200c -exec rm {} \; 
find /usr/spool/line$1/output -type f -size -200c -exec rm {} \; 
echo "files in /usr/line$1/backup" 
ls -l /usr/line$1/backup 
echo " === " 
echo "files in /usr/spool/line$1/output" 
ls -l /usr/spool/line$1/output 

/usr/mail/account has old files

If we do not initiate sessions to the client, this is not a problem. In general, /usr/mail/account file are NOT sent out actively -- they are only pulled by the client.

/mail/junkmail or /mail/adm/dead has old files

Zero length files may be mercilessly deleted, either by hand or using the .rm0len script.

Messages which were not processed correctly on the first try may be retried with dlsend filename. You will be placed into vi with your cursor positioned on the first offending line.

1. Edit the message, correcting any errors in the header.
2. Check (ls) to see if the message has been sent (i.e., it's no longer there); if not, try dlsend again and correct further errors.

Quaker: The client quaker often sends invalid headers. The following script will take a message filename as its argument and convert that message file in-place to a nondelivery message:

FROMLINE=`grep "^From: " $1` 
FROMLINE=`echo $FROMLINE | sed 's/From: //'` 
echo "Message-Version: 2 
To:" $FROMLINE "  
From: !attmail (Junkmail Admin ) 
Date:" `date` " 
Subject: Undeliverable ATT-Mail 
End-of-Protocol: 
 
        The attached message was rejected by ATTMAIL. Invalid address specified. 
                                                                                 
     ============================================================== 
 
" > /tmp/$1.tmp 
cat $1 | sed 's/^From: />From: /' | sed 's/^Received: />Received: /' | sed 's/^To: />To: /' >> /tmp/$1.tmp 
mv /tmp/$1.tmp $1 

/usr/account/msgq has old files

a-* files (mail bag acknowledgements) may be removed if several hours old.

azyu_root-> date 
Mon Nov  4 14:59:55 GMT 1996 
 
azyu_root-> ls -al /usr/advanet/msgq 
total 18 
drwxrwxrwx   2 advanet  other       3936 Nov  4 14:52 . 
drwxrwxrwx  13 advanet  other       2032 Nov  4 14:50 .. 
-rw-r--r--   1 root     other         15 Nov  4 14:52 K18258340 
-rw-r--r--   1 root     other          0 Nov  4 14:52 K18258340.TAG 
-rw-r--r--   1 root     other        145 Nov  4 14:47 TMPMSG 
-rw-r--r--   1 root     other         15 Nov  4 14:46 U18258009 
-rw-r--r--   1 root     other          0 Nov  4 14:46 U18258009.TAG 
-rw-r--r--   1 root     other         97 Nov  4 07:24 a-327d9a4a 
-rw-r--r--   1 root     other         15 Nov  4 14:49 e18258159 
-rw-r--r--   1 root     other          0 Nov  4 14:49 e18258159.TAG 
-rw-r--r--   1 root     other         15 Nov  4 14:50 y18258248 
-rw-r--r--   1 root     other          0 Nov  4 14:50 y18258248.TAG 
 
azyu_root-> rm a-327d9a4a 

If other files do not go out, and there is a file in the schedq w/account name and a byte count (not 0) then either rm or 0 out.

/usr/account/sendq has old files

1. Check for old files in /usr/account/sendq. If old files are found, check to see if the account is using a dedicated line:

> grep DED /usr/account/config 
DEDICATED_PORT=no                               

• If not, see if we initiate and if they have an ACTIVE session:

> cat /usr/account/AC* 
line10.0 
> cd line10.0 

2. Check if they are sending:

> cat sending 
/usr/account/sendq/M-31b077aa 2745 

3. See if the file being sent is large:

> ls -al /usr/account/sendq/M-31b077aa 
-rw-r--r--   2 root     other      18737 Jun  1 17:02 /usr/account/sendq/M-31b077 

4. Watch the large file being sent:

> tail -f /usr/line10.0/logs/c* 
19:35:58 Sending 7000th Block to HOST 
19:42:35 Sending 8000th Block to HOST 
19:49:16 Sending 9000th Block to HOST 

/no05000/mime/in has old files

NOAU and SIAU are SMTP gateways. When this error occurs, it usually means that there's one or more bad files holding up the entire queue. Try moving the first message file in the directory (usually, but not always, the oldest) out of the way -- the rest should be processed and disappear quickly.

It's sometimes/often the case that the bad message is SPAM. If so, there might be a few dozen nearly-identical files, each of which is going to halt processing. It might be a good idea, at your discretion, to remove all of these SPAM files (grep for a unique phrase):

• grep -li phrase_in_spam_mail | xargs rm

Again, use this at your discretion.