[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference forty2::mailbus_400

Title:MAILBUS 400 User Forum
Notice:kits 100-109 - Infocenter //www.digital.com/info/messaging
Moderator:IOSG::MARSHALL
Created:Thu Jun 11 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3210
Total number of notes:9174

3171.0. "Large temp files accumulating in /volatile area (filling up disk)" by KOALA::PAWELKO () Wed Apr 16 1997 02:13

Hello,

     A large MailWorks/UNIX customer has reported a problem where large 
temp files are piling up in the /var/mta/workspace/volatile directory.   
Apparently, MW/UNIX was retrying to post a very large message to MB400.  
The retries continued to fail.   But for each retry, another large temp 
file was created in /volatile, and these files were only deleted when the 
MTA was restarted.

I have 2 questions:

1) I believe the MTA was reporting back an "insufficient memory" error.
   If so, is this correct behavior for these temp files to accumulate
   in the /volatile directory?   Note 2396.1 implies that the MTA might
   leave files here if it fails to finish processing a message.

2) If someone reading this is familiar with the XAPI interface,
   which objects created via om_create() will cause temporary files to 
   be created in the /var/mta/workspace/volatile directory?   Is it determined 
   by the type of object (i.e. all MH_C_MESSAGE objects) or is it determined 
   by size (i.e. all objects bigger than n bytes)?  

   I discovered that MW/UNIX is not properly deleting bodypart objects when
   it receives an error from the MTA, and I'm wondering if the temp files
   building up in /volatile correspond to these bodypart objects, and if
   these temp files would be deleted if MW/UNIX made the proper om_delete()
   calls on these bodypart objects.



Thanks for any help,

    Mary Pawelko 
    (MW/UNIX Engineering)



P.S.  What customer saw in /volatile area:

-rw-rw----   1 root     system   13416448 Jan 24 01:44
00A3F226B575D011801E0000F840DA1C
-rw-rw----   1 root     system   13416448 Jan 24 08:29
1600B0C2ED75D011801E0000F840DA1C
-rw-rw----   1 root     system   13416448 Jan 24 06:05
188DCDA2D975D011801E0000F840DA1C
-rw-rw----   1 root     system   13416448 Jan 24 06:44
1AF43D1EDF75D011801E0000F840DA1C
-rw-rw----   1 root     system   13416448 Jan 24 03:24
20B87D35C375D011801E0000F840DA1C
-rw-rw----   1 root     system   13416448 Jan 24 06:25
2470D562DC75D011801E0000F840DA1C
-rw-rw----   1 root     system   13416448 Jan 24 07:44
26913183E775D011801E0000F840DA1C
-rw-rw----   1 root     system   13416448 Jan 24 03:44
2E9EFCECC575D011801E0000F840DA1C

etc...

T.RTitleUserPersonal
Name
DateLines
3171.1Answer to 2FORTY2::KNOWLESPer ardua ad nauseamWed Apr 16 1997 20:209
    It's a long time since I did any work on the doc for MB400 API, but I
    can answer your second question (with a bit of help from a learned
    friend who is keeping his head down in a parallel universe): any long
    string gets created as a volatile container - a file in the volatile
    workspace: /var/mta/workspace/volatile. A bodypart is a good example of
    a long string.
    
    If no one deletes objects containing long strings, the files stay there
    until the MTA is restarted.