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

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:

https://portal.microfocus.com/s/article/KM000004408

/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 https://portal.microfocus.com/s/article/KM000004408?language=en_US 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/update_v25.sh
   sudo service smg restart

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