Len,
1. You can 'kill' (need to use kill.exe from NT Resource kit) any SMTP32
process, if you wish. Just means that the files that are open, will not get
renamed as they normally would. You can still see them in the Queue, with
the ~ in the name. These can still be delivered, automatically or using the
Send One button. When IMail is finished it will close the SMTP32 processes,
so with no mail to send, there are no SMTP32 processes. Note: no need to
stop SMTPD service to 'kill' SMTP32 processes.
2. Tough one! The only suggestion I can offer is to stop/start each
process/service to see if memory is released. If this helps, then the
process you just stopped, is the most likely culprit. Could be related to
the SMTP32 problem. Kill them and see if memory is released.
3. Sounds like on process has not been able to release the lock on the
mailbox, so other processes cannot use the mailbox. It is possible that the
SMTP32 processes that are 'left over' could be keeping the lock. Kill them
and see if that helps. Yes, a restart will clear this condition, as will
stopping/starting any/all IMail service that could hold the lock (SMTP,
POP3, IMAP4, Web MSG and SMTP32).
I've not found the exact reason for SMTP32s not going away, except those
that are attempting to send to a group alias, which has more than the 50
address limit (most likely!). Also an alias which calls another alias, that
causes the total number of addresses to exceed the 50 limit, can have the
same effect as a single alias with more than 50 addresses.
As for KB articles, we will see what can be done, but this issue is not so
clear cut that it can always be resolved with a few simple steps and just a
few minutes work.
I have used this technique when encountering the situation on my server:
Restart or kill all SMTP32 processes, Start Task Manager and sort by name
(look for SMTP32).
Go to the Queue and use the Send One button to force delivery of messages
with 0 or 1 try (most likely to go, may not have been tried yet, if 0).
Observe TM for SMTP32 and PID number. Observer that SMTP32 closes when
message is delivered.
Once all those messages are delivered, begin same proces on other message in
Queue (note: if queue has large number of files, it can be to your advantage
to move all Q & D files to another directory, then move a single pair back
into \imail\spool as Queue gets empty).
If one of the Send One attempts does not close the SMTP32 process, the
message you last tried is the most likely cause of the problem. Check the TO
and From Addresses and make sure all is well with those
accounts/aliases/lists.
This process can take a good amount of time, but if one is persistant, it
does work.
Sometimes, it can also be helpful to observe the 'Number of tries' for each
of the Q files. If that never increases with your Send One (or the automatic
attempts), then IMail is having problems with that file (and the D of the
same name) and it is the culprit.
This process is best attempted when the users are not likely to be sending
messages (new ones can arrive in Queue and show a SMTP32 process for each
new message).
If this problem has only just started with the addition of the new domain,
that too, could be a clue as to the orgin of the problem. May be something
about that domain and its Aliases.
Daniel Donnelly
Ipswitch Technical Support
________________________________________________________
See our Knowledge Base at http://support.ipswitch.com/kb
----- Original Message -----
From: "Len Conrad" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 28, 2000 8:32 AM
Subject: [IMail Forum] SMTP processes with 0 K + etc
> Imail 5.09 (nope, missed my upgrade to 6.03 window last weekend, maybe
next
> w.e.)
>
> 1. In task mgr, are any SMTP processes with 0 K memory used killable?
>
> or are they just instanced/primed and ready to get to work and I should
> leave them alone.
>
>
> 2. I've noticed an extremely slow, over at least a couple of weeks,
> increase in total memory consumption, with no particular task(s) being the
> evident culprit. no slow, no failure, just increased memory. how to find
> the culprit?
>
> 3. We begun mail hosting a new company and they got a couple of real
> superstar users who manage to hang their mailbox so know local deliveries
> are possible, Imail log says:
>
> ERR domain.com open append fail ....................\main.mbx
>
> This is not like the intermittant error when one POP3 has main open and
> SMTP client tries to deliver. These "open append fail" errors
> persist. obviously some hung process has a mailbox open. I cleared 3
> boxes like this yesterday by rebooting. Do you think my SMTP-with-O-K-ram
> are "usual suspects"?
>
> And what causes and SMTP process to hang? Shouldn't such a process be
> designed with a timeout so that it eventually terminates itself?
>
> ipswitch: I think there should be an article in the KB for "open append
> fail" and for Imail process with 0 K memory.
>
> Len
>
> Please visit http://www.ipswitch.com/support/mailing-lists.html
> to be removed from this list.
>
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
