Expand all | Collapse all

Start MFT Agent at System Startup on RHEL 7

  • 1.  Start MFT Agent at System Startup on RHEL 7

    Posted 5 days ago
    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.


    Guy Petty

  • 2.  RE: Start MFT Agent at System Startup on RHEL 7

    Posted 4 days ago
    Have you looked at the suggestion here

    Shashikanth Rao Thambrahalli

  • 3.  RE: Start MFT Agent at System Startup on RHEL 7

    Posted 2 days ago
      |   view attached
    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.

      - 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

    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.


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


    mftagent@.service.txt   591 B 1 version