MQ

Hi All,

I would like to setup my MFT Agents to start at System Startup on a RHEL 7 server. 
My 1st thought was to set this up as recommended in the MFT documentation by adding a startup script to the inittab.
However it seems that method has been deprecated since RHEL 7 and it is suggested you set this up as a service in systemd.
This method also has some benefits, such as restarting the agents if they fail automatically. So I tried and thus far it's not working.
The agent is failing to start with not much in the way of details. There are some limitations with systemd, so before I spend more time debugging if anyone has successfully used this method or if it's even supported.  I understand there are some limitations, one to do with logging. Anyway, any alternative recommendations would also be appreciated.

Thanks,
Guy

------------------------------
Guy Petty
------------------------------

Have you looked at the suggestion here https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.tro.doc/missing_agent_process.htm?

------------------------------
Shashikanth Rao Thambrahalli
IBM
------------------------------

Original Message:
Sent: Sun February 21, 2021 05:26 PM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi All,

I would like to setup my MFT Agents to start at System Startup on a RHEL 7 server. 
My 1st thought was to set this up as recommended in the MFT documentation by adding a startup script to the inittab.
However it seems that method has been deprecated since RHEL 7 and it is suggested you set this up as a service in systemd.
This method also has some benefits, such as restarting the agents if they fail automatically. So I tried and thus far it's not working.
The agent is failing to start with not much in the way of details. There are some limitations with systemd, so before I spend more time debugging if anyone has successfully used this method or if it's even supported.  I understand there are some limitations, one to do with logging. Anyway, any alternative recommendations would also be appreciated.

Thanks,
Guy

------------------------------
Guy Petty
------------------------------

Thank you Shashikanth, 
I did take a look at this and gave it a shot. 
Unfortunately there was no change.

Regards,
Guy

------------------------------
Guy Petty
------------------------------

Original Message:
Sent: Mon February 22, 2021 09:26 PM
From: Shashikanth Rao Thambrahalli
Subject: Start MFT Agent at System Startup on RHEL 7

Have you looked at the suggestion here https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.tro.doc/missing_agent_process.htm?

------------------------------
Shashikanth Rao Thambrahalli
IBM

Original Message:
Sent: Sun February 21, 2021 05:26 PM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi All,

I would like to setup my MFT Agents to start at System Startup on a RHEL 7 server. 
My 1st thought was to set this up as recommended in the MFT documentation by adding a startup script to the inittab.
However it seems that method has been deprecated since RHEL 7 and it is suggested you set this up as a service in systemd.
This method also has some benefits, such as restarting the agents if they fail automatically. So I tried and thus far it's not working.
The agent is failing to start with not much in the way of details. There are some limitations with systemd, so before I spend more time debugging if anyone has successfully used this method or if it's even supported.  I understand there are some limitations, one to do with logging. Anyway, any alternative recommendations would also be appreciated.

Thanks,
Guy

------------------------------
Guy Petty
------------------------------

Hello Guy

From the perspective of systemd, an MFT AGENT can be either a long running process (use smiple or exec as the service unit Type and the -F parameter on fteStartAgent), or it could fork off and then you probably need to wrap a script around the startup so that you can capture the correct PID and create a PIDfile so that systemd can tell that your AGENT is still running.

I created and tested the following simple service unit file to test this out. The unit Type is exec, which means that startup is delayed slightly until the binary has completed the exec, so you might wish to change this to Type=simple instead. I used the -F parameter to make the MFT agent stay in foreground, which makes it simpler for systemd to track it.

I named the file mftagent@.service, and put it in /usr/lib/systemd/system. There are other directories which could be used too.

By suffixing the service definition file with "@" you can control multiple agents on the system with the same script. The agent name is provided after the @ symbol when running systemctl. Inside the file, the %i insert will substitute whatever appears after the @ symbol in the systemctl command.

Example:
  - Agent name: MFTAGENT1
 ​ - Start command (by root): systemctl start mftagent@MFTAGENT1
​ ​ - Stop command (by root): systemctl stop mftagent@MFTAGENT1
​ ​ - Status command (by root): systemctl status mftagent@MFTAGENT1
​  - Enable auto startup (by root): systemctl enable mftagent@MFTAGENT1​

The service unit description file is attached as mftagent@.service.txt: - this system restricts what file suffixes can be used on uploaded files.

As you will see, this unit file always run the agent as the mqm account. This might not be suitable for you. You can just change the User= value.

You could also create the file as MFTAGENT1.service instead of mftagent@.service. You would replace the %i values in the file with the actual agent name (MFTAGENT1) and create a separate service unit per agent. This is more flexible but also more effort to set up, especially if you want to build a delivery mechanism (like an RPM or deb) to delivery the systemd configuration to the server.

The command to control the agent would then be:
  systemctl start MFTAGENT1 
  systemctl stop MFTAGENT1
    etc

I should also point out that if you want your user (mqm in my case) to be able to control the agent and also maintain the service property of automatic restart on failure, you need to do 2 things:
  1. Provide your account with permission to perform systemctl start MFTAGENT1 as root via sudo (and also any other command option stop, status, enable, disable etc)
  2. Train your users to always use "sudo systemctl start MFTAGENT1" instead of "fteStartAgent MFTAGENT1.

If they just run mftStopAgent and mftStartAgent instead of using systemctl as root, the automatic restart on failure of the agent which is overseen by systemd would be lost.

Because of difficulty in training uses to use sudo, and difficulty in sudo security configuration, I often write wrapper scripts which will perform the systemctl command. The user then just has to remember to use the wrapper script (mftStartAgent) instead of the IBM delivered program (fteStartAgent). I make the wrapper script executable as root and grant sudo access to it. If the script is designed to use the mftagent@.service form, then it can be designed to prepend this to the actual agent name, which simpifies things for the user.

Note: when writing scripts that will be executed as root, you need to be very careful about ensuring that they cannot be edited, and that they perform very strict parameter checking to ensure that they cannot be exploited.

If MQ is running locally, you can add a Requires= and After= so that your MFT agent will not be started unless MQ is already running (providing MQ is also managed by systemctl). If you are client connecting to the agent queue manager, this doesn't apply, since there's no easy way to tell whether the queue manager is up and running before starting the agent.

Regards,

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
+61 (0) 414 615 334
------------------------------

Original Message:
Sent: Sun February 21, 2021 05:26 PM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi All,

I would like to setup my MFT Agents to start at System Startup on a RHEL 7 server. 
My 1st thought was to set this up as recommended in the MFT documentation by adding a startup script to the inittab.
However it seems that method has been deprecated since RHEL 7 and it is suggested you set this up as a service in systemd.
This method also has some benefits, such as restarting the agents if they fail automatically. So I tried and thus far it's not working.
The agent is failing to start with not much in the way of details. There are some limitations with systemd, so before I spend more time debugging if anyone has successfully used this method or if it's even supported.  I understand there are some limitations, one to do with logging. Anyway, any alternative recommendations would also be appreciated.

Thanks,
Guy

------------------------------
Guy Petty
------------------------------

Hi Neil, thank you very much for the elaborate post. Your time and effort is much appreciated!

I gave this a go and it works great, however I did need to an environment variable below for the agent to start though.
I do have a couple of follow up questions for you.
1) is the ExecStop required, what is its purpose?
2) IN RHEL 7, would you say this is the preferred method of ensuring the Agents are always up?

[Service]
Environment="BFG_DATA=/mftdata path"

Thanks,
Guy

------------------------------
Guy Petty
------------------------------

Original Message:
Sent: Thu February 25, 2021 10:05 PM
From: Neil Casey
Subject: Start MFT Agent at System Startup on RHEL 7

Hello Guy

From the perspective of systemd, an MFT AGENT can be either a long running process (use smiple or exec as the service unit Type and the -F parameter on fteStartAgent), or it could fork off and then you probably need to wrap a script around the startup so that you can capture the correct PID and create a PIDfile so that systemd can tell that your AGENT is still running.

I created and tested the following simple service unit file to test this out. The unit Type is exec, which means that startup is delayed slightly until the binary has completed the exec, so you might wish to change this to Type=simple instead. I used the -F parameter to make the MFT agent stay in foreground, which makes it simpler for systemd to track it.

I named the file mftagent@.service, and put it in /usr/lib/systemd/system. There are other directories which could be used too.

By suffixing the service definition file with "@" you can control multiple agents on the system with the same script. The agent name is provided after the @ symbol when running systemctl. Inside the file, the %i insert will substitute whatever appears after the @ symbol in the systemctl command.

Example:
  - Agent name: MFTAGENT1
 ​ - Start command (by root): systemctl start mftagent@MFTAGENT1
​ ​ - Stop command (by root): systemctl stop mftagent@MFTAGENT1
​ ​ - Status command (by root): systemctl status mftagent@MFTAGENT1
​  - Enable auto startup (by root): systemctl enable mftagent@MFTAGENT1​

The service unit description file is attached as mftagent@.service.txt: - this system restricts what file suffixes can be used on uploaded files.

As you will see, this unit file always run the agent as the mqm account. This might not be suitable for you. You can just change the User= value.

You could also create the file as MFTAGENT1.service instead of mftagent@.service. You would replace the %i values in the file with the actual agent name (MFTAGENT1) and create a separate service unit per agent. This is more flexible but also more effort to set up, especially if you want to build a delivery mechanism (like an RPM or deb) to delivery the systemd configuration to the server.

The command to control the agent would then be:
  systemctl start MFTAGENT1 
  systemctl stop MFTAGENT1
    etc

I should also point out that if you want your user (mqm in my case) to be able to control the agent and also maintain the service property of automatic restart on failure, you need to do 2 things:
  1. Provide your account with permission to perform systemctl start MFTAGENT1 as root via sudo (and also any other command option stop, status, enable, disable etc)
  2. Train your users to always use "sudo systemctl start MFTAGENT1" instead of "fteStartAgent MFTAGENT1.

If they just run mftStopAgent and mftStartAgent instead of using systemctl as root, the automatic restart on failure of the agent which is overseen by systemd would be lost.

Because of difficulty in training uses to use sudo, and difficulty in sudo security configuration, I often write wrapper scripts which will perform the systemctl command. The user then just has to remember to use the wrapper script (mftStartAgent) instead of the IBM delivered program (fteStartAgent). I make the wrapper script executable as root and grant sudo access to it. If the script is designed to use the mftagent@.service form, then it can be designed to prepend this to the actual agent name, which simpifies things for the user.

Note: when writing scripts that will be executed as root, you need to be very careful about ensuring that they cannot be edited, and that they perform very strict parameter checking to ensure that they cannot be exploited.

If MQ is running locally, you can add a Requires= and After= so that your MFT agent will not be started unless MQ is already running (providing MQ is also managed by systemctl). If you are client connecting to the agent queue manager, this doesn't apply, since there's no easy way to tell whether the queue manager is up and running before starting the agent.

Regards,

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
+61 (0) 414 615 334

Original Message:
Sent: Sun February 21, 2021 05:26 PM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi All,

I would like to setup my MFT Agents to start at System Startup on a RHEL 7 server. 
My 1st thought was to set this up as recommended in the MFT documentation by adding a startup script to the inittab.
However it seems that method has been deprecated since RHEL 7 and it is suggested you set this up as a service in systemd.
This method also has some benefits, such as restarting the agents if they fail automatically. So I tried and thus far it's not working.
The agent is failing to start with not much in the way of details. There are some limitations with systemd, so before I spend more time debugging if anyone has successfully used this method or if it's even supported.  I understand there are some limitations, one to do with logging. Anyway, any alternative recommendations would also be appreciated.

Thanks,
Guy

------------------------------
Guy Petty
------------------------------

Hello Guy,

you are very welcome.

ExecStop tells systemd how to stop the service. This is used when you explicitly ask it to stop (systemctl stop MFTAGENT1) or restart, and also when the server is shutting down. systemd will attempt to shut things down cleanly before killing them if the shutdown doesn't finish promptly.

In RHEL 7 and other systemd based distributions, my preference is certainly to use service units rather than init.d scripts.

While init.d still functions via a compatibility layer, it doesn't provide the failure detection and service restart that is available with systemd service units. Service units also provide much better control of startup sequence as they can control whether a service just has to be kicked off before the next in line starts, or whether it has to be completely initialised and functional.

I don't know that all Linux admins agree with me on this, but my personal view is that systemd is a great advance over System V initd, so I use it natively on systems that I manage.

Regards,

 

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
+61 (0) 414 615 334
------------------------------

Original Message:
Sent: Wed March 03, 2021 10:52 AM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi Neil, thank you very much for the elaborate post. Your time and effort is much appreciated!

I gave this a go and it works great, however I did need to an environment variable below for the agent to start though.
I do have a couple of follow up questions for you.
1) is the ExecStop required, what is its purpose?
2) IN RHEL 7, would you say this is the preferred method of ensuring the Agents are always up?

[Service]
Environment="BFG_DATA=/mftdata path"

Thanks,
Guy

------------------------------
Guy Petty

Original Message:
Sent: Thu February 25, 2021 10:05 PM
From: Neil Casey
Subject: Start MFT Agent at System Startup on RHEL 7

Hello Guy

From the perspective of systemd, an MFT AGENT can be either a long running process (use smiple or exec as the service unit Type and the -F parameter on fteStartAgent), or it could fork off and then you probably need to wrap a script around the startup so that you can capture the correct PID and create a PIDfile so that systemd can tell that your AGENT is still running.

I created and tested the following simple service unit file to test this out. The unit Type is exec, which means that startup is delayed slightly until the binary has completed the exec, so you might wish to change this to Type=simple instead. I used the -F parameter to make the MFT agent stay in foreground, which makes it simpler for systemd to track it.

I named the file mftagent@.service, and put it in /usr/lib/systemd/system. There are other directories which could be used too.

By suffixing the service definition file with "@" you can control multiple agents on the system with the same script. The agent name is provided after the @ symbol when running systemctl. Inside the file, the %i insert will substitute whatever appears after the @ symbol in the systemctl command.

Example:
  - Agent name: MFTAGENT1
 ​ - Start command (by root): systemctl start mftagent@MFTAGENT1
​ ​ - Stop command (by root): systemctl stop mftagent@MFTAGENT1
​ ​ - Status command (by root): systemctl status mftagent@MFTAGENT1
​  - Enable auto startup (by root): systemctl enable mftagent@MFTAGENT1​

The service unit description file is attached as mftagent@.service.txt: - this system restricts what file suffixes can be used on uploaded files.

As you will see, this unit file always run the agent as the mqm account. This might not be suitable for you. You can just change the User= value.

You could also create the file as MFTAGENT1.service instead of mftagent@.service. You would replace the %i values in the file with the actual agent name (MFTAGENT1) and create a separate service unit per agent. This is more flexible but also more effort to set up, especially if you want to build a delivery mechanism (like an RPM or deb) to delivery the systemd configuration to the server.

The command to control the agent would then be:
  systemctl start MFTAGENT1 
  systemctl stop MFTAGENT1
    etc

I should also point out that if you want your user (mqm in my case) to be able to control the agent and also maintain the service property of automatic restart on failure, you need to do 2 things:
  1. Provide your account with permission to perform systemctl start MFTAGENT1 as root via sudo (and also any other command option stop, status, enable, disable etc)
  2. Train your users to always use "sudo systemctl start MFTAGENT1" instead of "fteStartAgent MFTAGENT1.

If they just run mftStopAgent and mftStartAgent instead of using systemctl as root, the automatic restart on failure of the agent which is overseen by systemd would be lost.

Because of difficulty in training uses to use sudo, and difficulty in sudo security configuration, I often write wrapper scripts which will perform the systemctl command. The user then just has to remember to use the wrapper script (mftStartAgent) instead of the IBM delivered program (fteStartAgent). I make the wrapper script executable as root and grant sudo access to it. If the script is designed to use the mftagent@.service form, then it can be designed to prepend this to the actual agent name, which simpifies things for the user.

Note: when writing scripts that will be executed as root, you need to be very careful about ensuring that they cannot be edited, and that they perform very strict parameter checking to ensure that they cannot be exploited.

If MQ is running locally, you can add a Requires= and After= so that your MFT agent will not be started unless MQ is already running (providing MQ is also managed by systemctl). If you are client connecting to the agent queue manager, this doesn't apply, since there's no easy way to tell whether the queue manager is up and running before starting the agent.

Regards,

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
+61 (0) 414 615 334

Original Message:
Sent: Sun February 21, 2021 05:26 PM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi All,

I would like to setup my MFT Agents to start at System Startup on a RHEL 7 server. 
My 1st thought was to set this up as recommended in the MFT documentation by adding a startup script to the inittab.
However it seems that method has been deprecated since RHEL 7 and it is suggested you set this up as a service in systemd.
This method also has some benefits, such as restarting the agents if they fail automatically. So I tried and thus far it's not working.
The agent is failing to start with not much in the way of details. There are some limitations with systemd, so before I spend more time debugging if anyone has successfully used this method or if it's even supported.  I understand there are some limitations, one to do with logging. Anyway, any alternative recommendations would also be appreciated.

Thanks,
Guy

------------------------------
Guy Petty
------------------------------

Original Message:
Sent: 3/4/2021 1:12:00 AM
From: Neil Casey
Subject: RE: Start MFT Agent at System Startup on RHEL 7

Hello Guy,

you are very welcome.

ExecStop tells systemd how to stop the service. This is used when you explicitly ask it to stop (systemctl stop MFTAGENT1) or restart, and also when the server is shutting down. systemd will attempt to shut things down cleanly before killing them if the shutdown doesn't finish promptly.

In RHEL 7 and other systemd based distributions, my preference is certainly to use service units rather than init.d scripts.

While init.d still functions via a compatibility layer, it doesn't provide the failure detection and service restart that is available with systemd service units. Service units also provide much better control of startup sequence as they can control whether a service just has to be kicked off before the next in line starts, or whether it has to be completely initialised and functional.

I don't know that all Linux admins agree with me on this, but my personal view is that systemd is a great advance over System V initd, so I use it natively on systems that I manage.

Regards,

 

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
+61 (0) 414 615 334
------------------------------

Original Message:
Sent: Wed March 03, 2021 10:52 AM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi Neil, thank you very much for the elaborate post. Your time and effort is much appreciated!

I gave this a go and it works great, however I did need to an environment variable below for the agent to start though.
I do have a couple of follow up questions for you.
1) is the ExecStop required, what is its purpose?
2) IN RHEL 7, would you say this is the preferred method of ensuring the Agents are always up?

[Service]
Environment="BFG_DATA=/mftdata path"

Thanks,
Guy

------------------------------
Guy Petty

Original Message:
Sent: Thu February 25, 2021 10:05 PM
From: Neil Casey
Subject: Start MFT Agent at System Startup on RHEL 7

Hello Guy

From the perspective of systemd, an MFT AGENT can be either a long running process (use smiple or exec as the service unit Type and the -F parameter on fteStartAgent), or it could fork off and then you probably need to wrap a script around the startup so that you can capture the correct PID and create a PIDfile so that systemd can tell that your AGENT is still running.

I created and tested the following simple service unit file to test this out. The unit Type is exec, which means that startup is delayed slightly until the binary has completed the exec, so you might wish to change this to Type=simple instead. I used the -F parameter to make the MFT agent stay in foreground, which makes it simpler for systemd to track it.

I named the file mftagent@.service, and put it in /usr/lib/systemd/system. There are other directories which could be used too.

By suffixing the service definition file with "@" you can control multiple agents on the system with the same script. The agent name is provided after the @ symbol when running systemctl. Inside the file, the %i insert will substitute whatever appears after the @ symbol in the systemctl command.

Example:
  - Agent name: MFTAGENT1
 ​ - Start command (by root): systemctl start mftagent@MFTAGENT1
​ ​ - Stop command (by root): systemctl stop mftagent@MFTAGENT1
​ ​ - Status command (by root): systemctl status mftagent@MFTAGENT1
​  - Enable auto startup (by root): systemctl enable mftagent@MFTAGENT1​

The service unit description file is attached as mftagent@.service.txt: - this system restricts what file suffixes can be used on uploaded files.

As you will see, this unit file always run the agent as the mqm account. This might not be suitable for you. You can just change the User= value.

You could also create the file as MFTAGENT1.service instead of mftagent@.service. You would replace the %i values in the file with the actual agent name (MFTAGENT1) and create a separate service unit per agent. This is more flexible but also more effort to set up, especially if you want to build a delivery mechanism (like an RPM or deb) to delivery the systemd configuration to the server.

The command to control the agent would then be:
  systemctl start MFTAGENT1 
  systemctl stop MFTAGENT1
    etc

I should also point out that if you want your user (mqm in my case) to be able to control the agent and also maintain the service property of automatic restart on failure, you need to do 2 things:
  1. Provide your account with permission to perform systemctl start MFTAGENT1 as root via sudo (and also any other command option stop, status, enable, disable etc)
  2. Train your users to always use "sudo systemctl start MFTAGENT1" instead of "fteStartAgent MFTAGENT1.

If they just run mftStopAgent and mftStartAgent instead of using systemctl as root, the automatic restart on failure of the agent which is overseen by systemd would be lost.

Because of difficulty in training uses to use sudo, and difficulty in sudo security configuration, I often write wrapper scripts which will perform the systemctl command. The user then just has to remember to use the wrapper script (mftStartAgent) instead of the IBM delivered program (fteStartAgent). I make the wrapper script executable as root and grant sudo access to it. If the script is designed to use the mftagent@.service form, then it can be designed to prepend this to the actual agent name, which simpifies things for the user.

Note: when writing scripts that will be executed as root, you need to be very careful about ensuring that they cannot be edited, and that they perform very strict parameter checking to ensure that they cannot be exploited.

If MQ is running locally, you can add a Requires= and After= so that your MFT agent will not be started unless MQ is already running (providing MQ is also managed by systemctl). If you are client connecting to the agent queue manager, this doesn't apply, since there's no easy way to tell whether the queue manager is up and running before starting the agent.

Regards,

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
+61 (0) 414 615 334

Original Message:
Sent: Sun February 21, 2021 05:26 PM
From: Guy Petty
Subject: Start MFT Agent at System Startup on RHEL 7

Hi All,

I would like to setup my MFT Agents to start at System Startup on a RHEL 7 server. 
My 1st thought was to set this up as recommended in the MFT documentation by adding a startup script to the inittab.
However it seems that method has been deprecated since RHEL 7 and it is suggested you set this up as a service in systemd.
This method also has some benefits, such as restarting the agents if they fail automatically. So I tried and thus far it's not working.
The agent is failing to start with not much in the way of details. There are some limitations with systemd, so before I spend more time debugging if anyone has successfully used this method or if it's even supported.  I understand there are some limitations, one to do with logging. Anyway, any alternative recommendations would also be appreciated.

Thanks,
Guy

------------------------------
Guy Petty
------------------------------