Why should I not run ipcrm nor amqiclen?

IBM MQ Support occasionally hears that customers are using ipcrm or amqiclen as part of their normal shutdown procedures.

For example, as part of a script that ends a queue manager using endmqm, they have added code after this command to call ipcrm against mqm-owned semaphore sets and shared memory segments.

IBM MQ Support advises that this should NOT be done and these can be run only if it is recommended by the IBM MQ Support team under certain circumstances. 
This document describes some of the reasoning for this advice.


+ Semaphores

It is potentially extremely dangerous for data integrity to remove IBM MQ's semaphores while they might still be referenced by a running part of IBM MQ.

IBM MQ uses the semaphores to manage concurrent access to shared data, and to determine whether another copy of the queue manager is already running.

If the semaphores are removed without first ending the queue manager, then a second queue manager can be started on the same machine at the same time.

This is an extremely serious problem because the second copy of the queue manager, thinking it has exclusive access to its data, begins immediately to reference the same queue and log data as is already being referenced by the original copy of the queue manager.

If this happens, the said queue and log data instantly becomes corrupted beyond repair.

The advice from IBM is, leave all of IBM MQ's semaphores in place, and never run ipcrm to remove them. This prevents the risk described above.


+ Shared memory

It is potentially harmful to remove IBM MQ's shared memory segments while there is any process attached to them.

If no processes are attached then it is not usually harmful. But it still is not needed, so the general advice is still not to do it.

This is a typical scenario. An administrator might end their queue manager and listeners but forget to end one or more of their IBM MQ applications.

A problem can arise if that application is bound to the queue manager using shared memory bindings (which is the norm [1]) and has not made an IBM MQI call for a while. Application processes like this can remain attached to IBM MQ's shared memory segments even though the queue manager has ended.

In this scenario, and supposing the application did not make another IBM MQI call, it will remain attached to the shared memory. The administrator will find that the queue manager later refuses to start, and error messages will be written by the strmqm command. The reason is that, during strmqm, the queue manager startup code detects the presence of those old applications and fails the startup processing.

The error messages from strmqm do state that the application(s) should be ended to allow the queue manager to start. The error messages also mention the process ID (pid) to make it easy to find the process concerned and end it.

Despite this, some system administrators have, in our experience, chosen to remove mqm-owned shared memory segments with ipcrm rather than end the applications, in order to allow strmqm to run. This does allow the queue manager to start, but later the applications can fail with a trap (SIGSEGV or similar), and an FDC file.

The advice from IBM is, leave all of IBM MQ's shared memory segments in place. Follow the instructions given in the error messages from strmqm. End the IBM MQ applications [2] that are still attached to the shared memory, and then strmqm will run successfully.


+ Tool: amqiclen

The amqiclen tool was developed to run as part of the IBM MQ installer. Its purpose is to check that it is safe to proceed with the install. The checks it makes are whether IBM MQ's shared memory segments are in use by any running processes.

The amqiclen tool is potentially just as dangerous to an IBM MQ system as the ipcrm command.

Therefore, for the same reason IBM MQ Support advises not to run ipcrm, we advise also not running amqiclen.

In fact amqiclen was not intended for use by IBM MQ users or administrators directly. When used directly its effects are not supported by IBM MQ Support unless they have specifically advised it while working through a PMR.

For more details see:

https://www.ibm.com/support/pages/node/6591157
IBM MQ - amqiclen failures encountered during the IBM MQ upgrade