This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMG Quarantine broken, how to fix?


A few days ago I realized SMG is no longer filtering my mails (MTA scanner). A quick check revealed that the vastorage disk was full, So I downed SMG, expanded the disk, and restarted everything,

Now SMG is working, but the quarantine is inaccessible, which obviously is a problem. Inaccessible means, when I login (as admin) everything's shown empty. I also realize, that attempting to access the quarantine immediately causes high utilization on the SMG appliance. Also, logging out of the quarantine takes a very long time.

Is there any potential procedure to fix this, or if all else fails, reset the quarantine to start from scratch (other than of course to deploy a new appliance)?

  • Access to SMG via 9443 and enter phpgadmin. Try to reorganize quarantine database (vacuum, index, ..)

    Use "Verified Answers" if your problem/issue has been solved!

  • Suggested Answer

    I hade the same problem.

    Use this procedure (recommendation from the Micro Focus support):

    1. Go to the module status page and stop the QMS Module:
     2. Go to the Database Connection Page and get the host, database user and database name for the QMS database:
     3. Go to the QMS Module Manager Page and confirm the Module root path (This is where the mime files and in queue and other QMS directories will be located):
     4. Remove the QMS work directories smg-scanner may still be adding files to the qms in_queue directory.   But with the smg-quarantine process stopped the queued messages will not be getting processed. You can go to the appliance console (where qms resides) and delete or rename the QMS Module root directory.   In my example the module root path was smg-quarantine/data_store.   This is a relative path that equates to /opt/microfocus/smg/smg-quarantine/data_store: I executed: rm -R /opt/microfocus/smg/smg-quarantine/data_store/ That will remove all the working directories (including queue and storage areas) for the QMS module.
     5. Remove the QMS database Go to phpPgAdmin using the <appliance:9443> interface.
     Be careful, if there are multiple database on this server/appliance.   Find the QMS database that you identified in step 2.   In my example it is the default name of "SecureGatewayQuarantine".   In the "Actions" column select the Drop button.   (After confirmation the database will be deleted)
     6. Go back to the Module Status page and start the Quarantine service.   During initialization the database and the datastore directories should get recreated and messages should begin being added to your quarantine. >>>>

  • Thanks for that. It's a drastic sledgehammer approach, but might be useful.

  • But this was the only way how to quickly solve interrupted processing mail messages. Vacuuming and reindexing the quarantine database didn't help. The database was growing permanently till the disk was full.

  • That actually fills the disk even more by producing monstrous amounts of log entries (on the root partition, mind you), risking to run out of space there too if you don't watch closely, but in the end does nothing to actually shrink the postgres database.

  • Which directory are growing? Is it surely root partition? If it would be /vastorage, it could be helpful this TID:

  • /var/opt/novell/postgres fills up rapidly (with logs) when running a vacuumdb

  • FWIW, that didn't really help. It repaired the database and made SMG functional for the moment, but now SMG multiplies every single new mail that is supposed to go into QMS thousands and thousands and thousands of times, until QMS becomes unuseable and completely broken within just a few hours (with several hundredthousands of messages).

    From my short analysis, it doesn't seem to delete the messages in the QMS in_queue directory and instead processes them over and over and over. I can't find a reason for that, it's not rights, Ilet the system recreate the whole queue directory, but as soon as a new mail hits that's supposed to go to QMS, it all starts over.

    I think I declare it dead...

  • If the problem is with the QMS in_queue directory, maybe could help.

  • Massimo,

    did you run this scipt? (Mentioned in update)

    To complete the switchover process manually, login to your appliance terminal as vaadmin, and issue the following commands:

       sudo /vastorage/smg/assets/updater/PostUpdate/update_scripts/
       sudo service smg restart

    As Jiri mentioned, it seems to be a rights problem ...

    Use "Verified Answers" if your problem/issue has been solved!