Managing queue manager startup and shutdown on Linux with systemd
Arthur Barr 120000QMD4 Comments (2) Visits (13060)
In this blog entry, we'll take a look at how to use systemd to start MQ queue managers at system boot time, and stop them when the system shuts down. systemd has been widely adopted across many Linux distributions, including Red Hat Enterprise Linux V7, Ubuntu 15.04 onwards, SUSE Linux Enterprise Server V12 and many more. systemd can be described as follows:
"systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd... offers on-demand starting of daemons, keeps track of processes using Linux control groups, ...and implements an elaborate transactional dependency-based service control logic."
I don't claim to be a systemd expert, but these instructions came about from a need to run a queue manager at boot time, and seem to work well for me. If you have any feedback, please add a comment to this blog entry.
Creating a simple systemd service
In order to run as a systemd service, you need to create a "unit" file. The following is a simple unit file for running MQ, which should be saved in /etc
[Unit] Description=IBM MQ V8 queue manager qm1 Afte
Update: Added LimitNPROC.
Let's break down the key parts of this file:
In order to try out the service, you first need to tell systemd to reload its configuration, which you can do with the following command:
Assuming you've already created a queue manager called "qm1", you can now start it as follows:
systemctl start qm1
You can then see the status of the systemd service as follows:
systemctl status qm1
This should show something like this:
● qm1.service - IBM MQ V8 queue manager qm1 Loaded: loaded (/et
You can see that systemd has identified `amqzxma0` as the main queue manager process. You will also spot that there is a Linux cont
If you have multiple queue managers, it would be nice to not duplicate the service unit file many times. You can create templated services in systemd to do this. Firstly, stop your qm1 service using the following command:
systemctl stop qm1
Next, rename your unit file to `mq@.service`, and edit the file to replace all instances of the queue manager name with "%I". After doing a daemon-reload again, you can now start your "qm1" queue manager by running the following command:
systemctl start mq@qm1
The full name of the service created will be "firstname.lastname@example.org", and you can use it just as before.
As it stands, you are supplying the name of the queue manager on the command line, so what about system startup? The non-templated version is an active unit, so would get started up automatically, but with the templated version, the trick is to add an "[Install]" section to your unit file, giving the following:
[Unit] Description=IBM MQ V8 queue manager %I Afte
After doing a daemon-reload, you can now "enable" a new service instance with the following command:
systemctl enable mq@qm1
You can, of course, run this many times, once for each of your queue managers. Using the "enable" command causes systemd to create symlinks on the filesystem for your particular service instances. In this case, we've said that the "multi-user" target (kind of like the old "runlevel 3"), should "want" our queue managers to be running. This basically means that when the system boots into a multi-user mode, the start up of our queue managers should be initiated. They will still be subject to the "After" rule we defined earlier.
systemd is a powerful set of tools, and we've really only scratched the surface here. In this blog entry, we've made the first useful step of ensuring that queue managers are hooked correctly into the lifecycle of the server it's running on. Doing this is very important for failure recovery. Using systemd instead of the old-style init.d scripts should help improve your server's boot time, as well as providing additional benefits such as the use of cgroups for finer-grained resource control. It's possible to set up more sophisticated dependencies for your units, if (say) you wanted to ensure your client applications were always started after the queue manager, or you wanted to wait for a mount point to become available. Be careful with adding too many dependencies though, as this could slow down your boot time.
I'm sure there are many of you, dear blog readers, who can recommend further changes or tweaks that helped in your environment. Please share your thoughts in the comments.