Loading

Starting Mule as a Daemon/Service on Linux

Date de publication: Aug 1, 2025
Tâche

GOAL

The goal of this document is to allow a standalone Mule to be started/stopped as Linux Daemon. One of the benefit of doing so is that Mule will automatically launch on system startup.
 
Étapes
Mule is packed with the Java Service Wrapper, which can automatically install the service for you, just by running a single command. This is the recommended process.

Please review this following documentation page to know how to do so:

Start Mule as a Linux/Unix Daemon

Note: If you want to customize the user running the wrapper process (and in consequence Mule -the Java process-), before running those steps, you can edit the $MULE_HOME/bin/mule file as follows: 
RUN_AS_USER=muleuser
Once the service is installed you will be able to start Mule as service using your OS service management tool (like Systemd, Init.d, Upstart, Launchd, rc.d, etc.) and as well through the mule command.

E.g.: 
$ $MULE_HOME/bin/mule start
or: 
$ systemctl start mule_ee

Both commands will run Mule as a Daemon, using your service management tool.

In case you want to still manually install Mule as a Service (not recommend), you can follow these steps, making sure that the service was not previously installed by the previous method or by any other method.

FOR LINUX 6 SYSTEMS:

1) Copy the attached mule service file to the /etc/init.d directory on your linux box. Change file permissions to 755 and owner to root.
Name or rename the file to "mule", so the absolute path should be /etc/init.d/mule.
 
2) Execute the following command logged as root: 
chkconfig --add mule
chkconfig --levels 345 mule on
 
3) Edit the /etc/init.d/mule file, by replacing the content below as indicated:
LineContentReplace by
17WORKDIR=/opt/mule/mule-enterprise-standalone-3.8.1/binReplace by the corresponding location of your mule instance BIN directory
20AMC_PORT=7777Replace the value with the listening port of your mule instance agent
23MULE_USER=muleReplace the value with the linux mule user's name
4) Create the following directory with owner mule: 
/var/log/mule
 
5) Start the service by executing the following command: 
service mule start
This script starts the mule instance exactly like a linux daemon does, so the mule instance remains running in background with the defined process priorities.
If you experience any issue, check the logs at the /var/log/mule/mule.log file, and your mule server logs.
You can download the mulectl script from the link under the "Attachments" section.

FOR LINUX 7 SYSTEMS:

On linux 7 systems, the old service configuration does not work anymore, and service configuration is now managed by systemd.
Please proceed as follows:

1) Have the mulectl script downloaded and configured as explained on the step 1 for the Linux 6 section. Do not rename the file.

2) Log in to your linux box using the superuser account (root), navigate under /usr/lib/systemd/system and create a file named "mule.service" and give permissions 644. Then, paste the following content, taking care of having replaced <scripts folder> with the current directory where your mulectl script lives, and User with the current linux username.
Note that we're passing the MULE_ENV, INITMEMORY and MAXMEMORY environment variables to the process. They are just mentioned as an example, you can remove them and add your own set of variables to be passed. You can also change here the user and group that will run Mule. 
[Unit]
Description=MuleSoft Mule ESB Application Container
After=network.target syslog.target network-online.target remote-fs.target
[Service]
Environment="MULE_ENV=prod"
Environment="INITMEMORY=1024"
Environment="MAXMEMORY=5020"
Type=forking
ExecStart=/opt/mule/mule-enterprise-standalone-3.8.1/bin/mule start
ExecStop=/opt/mule/mule-enterprise-standalone-3.8.1/bin/mule stop
User=mule
Group=mule
LimitNOFILE=102400
[Install]
WantedBy=multi-user.target
Once done, run the following commands as root to refresh the systemd daemon: 
systemctl daemon-reload
 
Check if you can manually stop-start the service by means of using systemctl facility via stop/start commands: 
systemctl start mule -> to start the instance
systemctl stop mule -> to stop the instance

Once you have checked that the service is able to stop/start, enable the service by executing: 
systemctl enable mule

This last command will enable the service on the RC scripts, so it will be loaded automatically on the next system reboot.

POSSIBLE ISSUES:

  • You may get the following error when the systemctl script starts by itself during startup or restart for RHEL 7 systems:  
    Mar 28 13:37:00 nyxsvlalb431 systemd[1]: Starting MuleSoft Mule ESB Application Container...
Mar 28 13:37:00 nyxsvlalb431 systemd[8119]: Failed at step USER spawning /opt/mule-enterprise-standalone/bin/mule: No such file or directory
Mar 28 13:37:00 nyxsvlalb431 systemd[1]: mule_ee.service: control process exited, code=exited status=217
Mar 28 13:37:00 nyxsvlalb431 systemd[1]: Failed to start MuleSoft Mule ESB Application Container.
Mar 28 13:37:00 nyxsvlalb431 systemd[1]: Unit mule_ee.service entered failed state.
Mar 28 13:37:00 nyxsvlalb431 systemd[1]: mule_ee.service failed.
    However, you noticed that you are able to start this script manually after the system has finished booting:  
    systemctl status mule_ee.service
    This may be due to the fact the mule file or directory has not been mounted by the startup scripts yet. Please try forcing the mule startup script (mule.service) to load at the end of startup by changing line 8 of the script above from: 
    Type=forking
    to:  
    Type=idle
    Then, refresh the systemd daemon: 
    systemctl daemon-reload
  • You may get the following error during RHEL 7 system startup or reboot, but the service can be manually started with 'systemctl start' command. 
    Jul 25 14:01:16 vernon12s systemd[1]: Starting MuleSoft Mule 4.2 ESB Application Container...
Jul 25 14:01:17 vernon12s mule[10262]: MULE_HOME is set to /home/api/mulesoft/mule-enterprise-standalone-4.2.0
Jul 25 14:01:17 vernon12s mule[10262]: MULE_BASE is set to /home/api/mulesoft/mule-enterprise-standalone-4.2.0
Jul 25 14:01:27 vernon12s mule[10262]: Starting Mule Enterprise Edition...
Jul 25 14:02:46 vernon12s systemd[1]: mule42.service start operation timed out. Terminating.
Jul 25 14:02:46 vernon12s systemd[1]: Failed to start MuleSoft Mule 4.2 ESB Application Container.
Jul 25 14:02:46 vernon12s systemd[1]: Unit mule42.service entered failed state.
Jul 25 14:02:46 vernon12s systemd[1]: mule42.service failed.
    This is due to the fact that the mule service takes longer to start up on certain slow or busy machines.
    To resolve the problem, first confirm the current service startup timeout setting, for example: 
    systemctl show mule42 | grep -i timeoutstart
TimeoutStartUSec=1min 30s
    Introduce a larger timeout setting in mule service script [Service] section, for example: 
    TimeoutStartSec=5min
    Then, refresh the systemd daemon: 
    systemctl daemon-reload
    Confirm the change is up to date before rebooting machine, for example: 
    systemctl show mule42 -p TimeoutStartUSec
TimeoutStartUSec=5min
  • You may get the following error when starting the service using systemctl start mule.service in RHEL 7
Nov 01 23:39:28 0aaeb244 systemd[1]: Starting MuleSoft Mule ESB Application Container...
Nov 01 23:39:28 0aaeb244 systemd[1]: mule.service: control process exited, code=exited status=216
Nov 01 23:39:28 0aaeb244 systemd[1]: Failed to start MuleSoft Mule ESB Application Container.
Nov 01 23:39:28 0aaeb244 systemd[1]: Unit mule.service entered failed state.
Nov 01 23:39:28 0aaeb244 systemd[1]: mule.service failed.
     This is due to the fact that there is something wrong with the group name value in mule.service file created in /usr/lib/systemd/system path.
     To resolve the issue, please make sure you have the exact group name defined in the mule.service file that matches with the group name of the mule file in <mule_home>/bin folder.
     Please make sure not to have quotes while defining a group name that has space in between words.
     
To find more verbose information in case of startup failure, the following entry can be enabled in {MULE HOME}/conf/wrapper.conf: 
#********************************************************************
# Wrapper Properties
#********************************************************************
# Uncomment this line in the case of startup failure.
wrapper.debug=true

To find out more information about Unit files and systemd, please check the official RedHat documentation.

Disclaimer: This article involves products and technologies which do not form part of the MuleSoft product set. Technical assistance for such products is limited to this article.
Disclaimer: This solution provides a suggestion that should be considered in conjunction with your specific use-case and requirements and does not represent a complete solution for all circumstances.
Ressources supplémentaires
MuleCTL Script File
Numéro d’article de la base de connaissances

001114850

 
Chargement
Salesforce Help | Article