[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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 () Tue Apr 15 1997 23: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.R | Title | User | Personal Name | Date | Lines |
---|
3171.1 | Answer to 2 | FORTY2::KNOWLES | Per ardua ad nauseam | Wed Apr 16 1997 17:20 | 9 |
| 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.
|