Community Discussions and Support
The Mercury32 service terminated unexpectedly

I migrate from version 4.80 on March 19. (Windows Server 2012 R2). No problems occurred during and after the migration.
For one week I get the following error message in the System log :
The Mercury32 service terminated unexpectedy. It has done this 1 time(s). The following corrective action will be taken in 60000 milliseconds: Restart the service.
The Mercury32 service is restarted either directly by the system or by the Zabbix monitoring system.
The problem is that each time Mercury32 is restarted, a new instance of the clamd.exe process is created and each instance takes 1 Gb of memory.
The only information I can find in the log is the Windows Event ID (7031). Does somebody know where I can find some more information to track the problem ?.
Many thanks for your help


I migrate from version 4.80 on March 19. (Windows Server 2012 R2). No problems occurred during and after the migration. For one week I get the following error message in the System log : The Mercury32 service terminated unexpectedy. It has done this 1 time(s). The following corrective action will be taken in 60000 milliseconds: Restart the service. The Mercury32 service is restarted either directly by the system or by the Zabbix monitoring system. The problem is that each time Mercury32 is restarted, a new instance of the clamd.exe process is created and each instance takes 1 Gb of memory. The only information I can find in the log is the Windows Event ID (7031). Does somebody know where I can find some more information to track the problem ?. Many thanks for your help

Hi PHR,
The problem is that not Mercury service is being terminated by OS but only the GUI at the desktop. I know this problem since years. Read my old post in this regard:


Mercury running as a service


Cheers
Joerg


Hi PHR, The problem is that not Mercury service is being terminated by OS but only the GUI at the desktop. I know this problem since years. Read my old post in this regard: [Mercury running as a service](https://community.pmail.com/index.php?u=/topic/10953/aw-aw-aw-control-panel-when-running-as-a-service/1#post-49995) Cheers Joerg

Hello Joerg,


Thanks for your message.
I run Mercury/32 only as a service without any GUI on the server desktop.


The explanation for EventID 7031 is as follows :
Event ID 7031 gets logged when a service crashes. The Service Control Manager logs this event when a service stops unexpectedly. The message says which service failed, how many times it failed and the corrective action that will be taken.
The diagnostic is confirmed by the Zabbix monitoring system that detected that Mercury32 service has stopped.


The problem for me is to find WHY the Mercury32 service crashed to give some troubleshooting informations to David Harris.


Regards,
Philippe


Hello Joerg, Thanks for your message. I run Mercury/32 only as a service without any GUI on the server desktop. The explanation for EventID 7031 is as follows : Event ID 7031 gets logged when a service crashes. The Service Control Manager logs this event when a service stops unexpectedly. The message says which service failed, how many times it failed and the corrective action that will be taken. The diagnostic is confirmed by the Zabbix monitoring system that detected that Mercury32 service has stopped. The problem for me is to find WHY the Mercury32 service crashed to give some troubleshooting informations to David Harris. Regards, Philippe

Apart from entries in Mercury log files at the time of a crash there might have been error dump files created. Please check for files with the .DMP extension in the main Mercury directory or in the DUMPS subdirectory. If there are any, please zip and email to <<address removed>> with a reference to this topic.


Apart from entries in Mercury log files at the time of a crash there might have been error dump files created. Please check for files with the .DMP extension in the main Mercury directory or in the DUMPS subdirectory. If there are any, please zip and email to _&lt;&lt;address removed&gt;&gt;_ with a reference to this topic.
edited Apr 25 at 4:03 pm

@Rolf Lindby : Many thanks for your information ...
No .DMP files in the Mercury main folder and in the dumps subfolder.
Waiting for the next crash ...

@Rolf Lindby : Many thanks for your information ... No .DMP files in the Mercury main folder and in the dumps subfolder. Waiting for the next crash ...

@Rolf Lindby
Hello Rolf,
Mercury/32 crashed again last night. I found in the Mercury folder the file deadlock.job.log with 3 entries corresponding to the dates and times of the crashes. As requested I sent this file to <<address removed>> with a reference to this topic.
Best regards,
Philippe

@Rolf Lindby Hello Rolf, Mercury/32 crashed again last night. I found in the Mercury folder the file deadlock.job.log with 3 entries corresponding to the dates and times of the crashes. As requested I sent this file to _&lt;&lt;address removed&gt;&gt;_ with a reference to this topic. Best regards, Philippe
edited Apr 25 at 4:04 pm

Hi Philippe,
any news from Rolf regarding your issue after providing him with your logs?


Hi Philippe, any news from Rolf regarding your issue after providing him with your logs?

Hi @Joerg

David Harris proposed the following :


The solution in the first case is to exclude the Mercury queue directory
from your anti-virus system's real-time scanner (you can use the Clam-AV
antivirus plugin supplied with Mercury instead, because Mercury interacts
with it predictably, meaning the timeouts won't happen).


ClamAV was already active through the ClamWall interface. So I excluded the Mercury queue directory from the Kasperaky Endpoint Security real-time scanner. For the time being everything runs fine ...


Hi @Joerg David Harris proposed the following : The solution in the first case is to exclude the Mercury queue directory from your anti-virus system&#039;s real-time scanner (you can use the Clam-AV antivirus plugin supplied with Mercury instead, because Mercury interacts with it predictably, meaning the timeouts won&#039;t happen). ClamAV was already active through the ClamWall interface. So I excluded the Mercury queue directory from the Kasperaky Endpoint Security real-time scanner. For the time being everything runs fine ...

Hi Philippe,
Yes, I know the oddities in connection with A/V scanners. But at our server, where Mercury resides, no A/V scanner is activated, also no ClamAV with Mercury. The A/V scan will be carried out 1. at ISP Mail Server and 2. at the Client machines, where finally the mails will be opened and attachments processed.
In past, when we used a separate A/V scanner at our client machines, Pmail often became freezed or slowly, so that we excluded the local mailboxes of our users from scanning. This helped.
In the meantime we are using MS Defender which comes with Windows10 and have no excludes in place. And all is working fine.


Hi Philippe, Yes, I know the oddities in connection with A/V scanners. But at our server, where Mercury resides, no A/V scanner is activated, also no ClamAV with Mercury. The A/V scan will be carried out 1. at ISP Mail Server and 2. at the Client machines, where finally the mails will be opened and attachments processed. In past, when we used a separate A/V scanner at our client machines, Pmail often became freezed or slowly, so that we excluded the local mailboxes of our users from scanning. This helped. In the meantime we are using MS Defender which comes with Windows10 and have no excludes in place. And all is working fine.
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft