How DevOps Teams Start Services on Linux
A step-by-step to how K&C’s DevOps consultants start services on Linux. Scripts of the services to be run in Linux are located in /etc/rc.d/init.d. To make a script start automatically at system launch, a symbolic link to the script should be created and placed in the catalog /etc/rc.d/rcN.d, where N shows the level OR designation of script execution.
Linux Initialization Levels – Designation
0 – system halt — the system will be stopped,
1 – single-user mode — the system initializes minimum services and offers command line to a single user (normally, the superuser) without authentication. This mode is normally used to restore the system,
2 – multiple-user mode — users can work on different terminals, system log-in with authentication,
3 – multiple-user network mode — unlike the level above, network is set up and various networking services are enabled,
4 – has no standard interpretation and is not generally useful;
5 – graphical subsystem start — similar to level 3, X11 graphical subsystem is also started, and system log-in is performed in graphic mode;
6 – system reboot — when this mode is on, all running applications are stopped and the system reboots
When booting, the system most often uses boot level 3 or 5. However, there is a trick in the name of the symbolic link itself, which many keep silent about, and about which I would like to tell.
Init.d
For example, /etc/rc.d/rc0.d/K60crond and /etc/rc.d/rc3.d/S40crond
indicate the same script /etc/init.d/crond of the system log service. The script starting with “K” corresponds to service shutdown, and with “S” to service start. Numbers preceding the service name provide for scripts start order in the directory. For example, script /etc/rc.d/rc3.d/S34syslogd will be started prior to script /etc/rc.d/rc3.d/S40crond, while /etc/rc.d/rc3.d/K60crond will be started prior to /etc/rc.d/rc3.d/K66syslogd. You may notice that the sum of the numbers for a service equals to 100 — this allows for organizing all scripts in the start order being reverse to that of fulfillment. Creation of symbolic links on your own is rather tiresome, so it is better to use a special utility chkconfig.
The syntax of its use is very easy:
chkconfig --list [service name] chkconfig --add <service name> chkconfig --del <service name> chkconfig [--level <level>] <service name> <on|off|reset|resetpriorities>
Where service name is the name of the running script located in /etc/rc.d/init.d
However, there is a trick here as well; the issue is that the start script should have a special format, for instance this:
#!/bin/bash
# liferayd Init script for running Liferay Java portal
# chkconfig: - 92 02
# description: Liferay Portal is the leading open source portal for the enterprise, \
# offering content management, collaboration, and social out-of-the-box.
if [ -f /etc/init.d/functions ] ; then
. /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
. /etc/rc.d/init.d/functions
else
exit 0
fi
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
LRHOMEDIR="/opt/local/portal/"
start(){
printf "Starting Portal\r"
su - user -c "cd ${LRHOMEDIR}; ant start-portal"
if [ $? -eq 0 ] ; then
logger -t liferayd Portal build successfully
else
logger -t liferayd Portal build unsuccessfully
fi
}
stop(){
printf "Stoping Portal\r"
su - liferay -c "cd ${LRHOMEDIR}; ant stop-portal-force"
if [ $? -eq 0 ] ; then
logger -t liferayd Portal closed successfully
else
logger -t liferayd Portal closed unsuccessfully
fi
}
restart(){
printf "Restarting Portal\r"
stop
start
}
case "$1" in
start )
start
;;
stop)
stop
;;
restart)
restart
;;
*) printf "Usage $0 {start|stop|restart}\n"
;;
esac
The script should have at least 3 potential run keys:
- start
- stop
- restart
these are the basic commands that are used to start, stop and restart.
Figures are put at the very beginning of a file; they indicate the start succession:
# chkconfig: — 92 02
where 92 is a number in the start succession, and 02 is a number in the stop succession.
To add a script to the autostart list, you have to:
- Create an executable script following the above template
- Place the executable script in /etc/init.d
- Run command chkconfig —add executable_script
- Run command chkconfig executable_script on
That’s it, our portal will now start automatically with the system launch
Systemd
The configuration consists of the files named units. All units are located at:
/usr/lib/systemd/system/ – units from installed RPM packages
/run/systemd/system/ — units created in runtime
/run/systemd/system/ — units created by system administrator
A unit is a text file:
[Name] variable_name = value
To create a unit, you have to describe three sections: [Unit], [Service], [Install]
In the Unit section, describe:
Unit description:
Description=Liferay
Then there is a block of variables, which have an effect on the service start order:
After=mysql.service
Running mysql is required to start the service:
Requires=mysql.service
Running nginx is desirable to start the service:
Wants=nginx.service
If the service is in Requires but not in After, our service will be started in parallel to the required service
In the Service section, indicate how the service should be started:
Service type:
Type=simple
systemd suggests that the service will be started right away. The process should not be branched.
Type=forking
systemd suggests that the service is started once and the process branches with completion of the parent process.
Also, you have to determine PIDFile= so that systemd can track the main process:
PIDFile=/var/run/liferay.pid
Operation catalog, it becomes current before starting startup commands:
WorkingDirectory=/opt/local/liferay
User and group:
User=liferay Group=liferay
Environment variables:
Environment=SERVER=production
Ban for killing the service because of lack of memory and activation of OOM mechanism:
-1000 total ban, -100 reduced probability.
OOMScoreAdjust=-100
Service start/stop and restart commands
ExecStart=/sbin/ant start-portal ExecStop=/sbin/ant stop-portal-force ExecReload=/sbin/ant stop-portal-force start-portal
We have a nuance here — systemd insists that the command provide the particular executable file. Full path should be given.
Timeout in seconds, indicating how long to wait for the system to fulfill start/stop commands.
TimeoutSec=300
Ask systemd to automatically restart our service if it suddenly crashes.
Control is exercised on the presence of the process from the PID file
Restart=always
In the [Install] section, describe at what run level the service should be started
Run level:
WantedBy=multi-user.target
multi-user.target or runlevel3.target corresponds to our usual runlevel=3
Unit for systemd is ready:
liferay.service
[Unit] Description=Liferay After=mysql.service Requires=mysql.service Wants=nginx.service [Service] Type=forking PIDFile=/var/run/liferay.pid WorkingDirectory=/opt/local/liferay User=liferay Group=liferay Environment=SERVER=production OOMScoreAdjust=-100 ExecStart=/sbin/ant start-portal ExecStop=/sbin/ant stop-portal-force ExecReload=/sbin/ant stop-portal-force start-portal TimeoutSec=300 [Install] WantedBy=multi-user.target
Put this file in catalog /etc/systemd/system/:
systemctl status liferay myunit.service - liferay Loaded: loaded (/etc/systemd/system/liferay.service; disabled) Active: inactive (dead)
systemctl enable liferay systemctl -l status liferay
If everything is OK, the output will be as follows:
myunit.service - liferay Loaded: loaded (/etc/systemd/system/liferay.service; enabled) Active: inactive (dead)
Start service:
systemctl start liferay
See status:
systemctl -l status liferay
Restart systemd daemon:
systemctl daemon-reload
