How to start services on Linux

How to start services on Linux

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:

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:

The script should have at least 3 potential run keys:

 

1. start

2. stop

3. 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:

 

1. Create an executable script following the above template

2. Place the executable script in /etc/init.d

3. Run command chkconfig —add executable_script

4. 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:

To create a unit, you have to describe three sections: [Unit], [Service], [Install]

 

In the Unit section, describe:

 

Unit description:

Then there is a block of variables, which have an effect on the service start order:

Running mysql is required to start the service:

Running nginx is desirable to start the 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:

systemd suggests that the service will be started right away. The process should not be branched.

 

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:

Operation catalog, it becomes current before starting startup commands:

User and group:

Environment variables:

Ban for killing the service because of lack of memory and activation of OOM mechanism:

-1000 total ban, -100 reduced probability.

Service start/stop and restart commands

 

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.

Ask systemd to automatically restart our service if it suddenly crashes.

Control is exercised on the presence of the process from the PID file

In the [Install] section, describe at what run level the service should be started

Run level:

multi-user.target or runlevel3.target corresponds to our usual runlevel=3

Unit for systemd is ready:

liferay.service

Put this file in catalog /etc/systemd/system/:

If everything is OK, the output will be as follows:

Start service:

See status:

Restart systemd daemon:

Add comment

E-mail is already registered on the site. Please use the Login form or enter another.

You entered an incorrect username or password

Sorry that something went wrong, repeat again!
Contact us