The difference between Init,service and Systemctl

Reference http://www.ruanyifeng.com/blog/2016/03/systemd-tutorial-commands.html

1, service is a script command, Analysis service is to/ETC/INIT.D directory to execute the relevant procedures. Service and Chkconfig are used in combination.
Service Profile Storage Directory/etc/init.d/

For example

# Start sshd service
sshd start
# set up sshd service boot
chkconfig sshd start

2, Systemd
In the CENTOS7 version, the SYSTEMD,SYSTEMD compatible service is used, and the corresponding command is SYSTEMCTL
SYSTEMD is the newest initialization system (INIT) in Linux system, its main design goal is to overcome sysvinit inherent disadvantage, improve system start-up speed
The goal of using SYSTEMD is to get faster boot speeds, and to reduce system startup time, the Systemdde target is
Start fewer processes as much as possible
Start as many concurrent processes as possible
can go to see the system process PID,INITD PID is 0 if the SYSTEMD system supports SYSTEMD process PID of 1

Systemd the different resources as the unit
Each unit has a configuration file that tells Systemd how to start this unit
Storage directory:/etc/systemd/system and/usr/lib/systemd/system

For tasks that have a dependent relationship

Systemctl Fusion service and Chkconfig functions

Use of Systemctl for example

# Open Service
systemctl start Sshd.service
# set boot up
systemctl enable Sshd.service
# is essentially creating a soft link ln-s/usr/lib/ Systemd/system/sshd.service/etc/systemd/system/multi-user.target.wants/sshd.service

Reproduced from
http://www.ibm.com/developerworks/cn/linux/1407_liuming_init3/
The use of SYSTEMD
The following are a few of the different roles for technicians to simply introduce the use of SYSTEMD. This article only intends to give a simple description, so that you have a general understanding of the use of SYSTEMD. The details are too many, that is, can not write in a short article, I do not have the ability to be so powerful. Readers are also required to consult the SYSTEMD documentation themselves.
System software Development Staff
Developers need to know more about SYSTEMD. For example, if you plan to develop a new system service, you must understand how to make the service managed by SYSTEMD. This requires your attention to the following points:
The background service process code does not need to perform two derivations to implement Daemon daemons, just the main loop of the service itself.
Do not call Setsid () and give systemd processing
You no longer need to maintain the PID file.
SYSTEMD provides logging, and the service process only needs to be output to stderr without using syslog.
Processing signal sigterm, the only correct function of this signal is to stop the current service, do not do other things.
The function of the SIGHUP signal is to restart the service.
Require socket service, do not create sockets yourself, let systemd incoming sockets.
Use the Sd_notify () function to notify SYSTEMD to service their own state changes. Generally, it can be invoked when the service initialization is complete and the service ready state is entered.
Preparation of Unit files
For developers, the most important part of the workload should be to write a hive file that defines the required units.
For example, a developer develops a new service program, such as HTTPD, to write a hive file for it so that the service can be systemd managed, similar to the upstart job profile. In this file, you define the command-line syntax for service initiation, as well as dependencies on other services, and so on.
In addition, we have already learned that Systemd has a wide range of functions, not only to manage services, but also to manage mount points, define timed tasks, and so on. The work is done by editing the corresponding hive file. I'll give you examples of several hive files here.
The following is the configuration unit file for the SSH service, and the service hive file has a. Service as the filename suffix.
#cat/etc/system/system/sshd.service
[Unit]
Description=openssh Server Daemon
[Service]
Environmentfile=/etc/sysconfig/sshd
Execstartpre=/usr/sbin/sshd-keygen
Execstart=/usrsbin/sshd–d $OPTIONS
Execreload=/bin/kill–hup $MAINPID
Killmode=process
Restart=on-failure
Restartsec=42s
[Install]
Wantedby=multi-user.target
The file is divided into three sections. The first one is the [unit] section, where there is only one descriptive message. The second section is the service definition, where Execstartpre defines the commands that should be run before the service is started; Execstart defines the specific command-line syntax for starting the service. The third part is [install],wangtedby indicates that this service is required in multi-user mode.
Then let's take a look at the Multi-user.target:
#cat Multi-user.target
[Unit]
Description=multi-user System
Documentation=man.systemd.special (7)
Requires=basic.target
Conflicts=rescue.service Rescure.target
After=basic.target Rescue.service Rescue.target
Allowisolate=yes
[Install]
Alias=default.target
The Requires definition in the first section indicates that the Basic.target must also be started when the Multi-user.target is started, and Multi-user.target must stop when the Basic.target is stopped. If you continue to view the Basic.target file, you will find that it specifies that other units such as Sysinit.target must be started. The same sysinit.target will also contain other units. With such layers of link structure, eventually all component services that need to support multiuser mode will be initialized to start up.
There is an alias definition in the [Install] section that defines the alias of this unit so that you can use this alias to refer to this unit when you run SYSTEMCTL. The alias here is Default.target, simpler than multi-user.target ...
In addition, you can see directories such as *.wants in the/etc/systemd/system directory, and the hive files placed in that directory are equivalent to the wants keyword in the [Unit] section, which is also required to start when this cell starts. For example, you can simply put your own Foo.service file into the multi-user.target.wants directory, so that each time will be started by default.
Finally, let's look at the Sys-kernel-debug.mout file, which defines a file mount point:

#cat Sys-kernel-debug.mount
[Unit]
Description=debug File Syste
Defaultdependencies=no
Conditionpathexists=/sys/kernel/debug
Before=sysinit.target
[Mount]
What=debugfs
Where=/sys/kernel/debug
Type=debugfs
This hive file defines a mount point. The Mount configuration unit file has a [Mount] configuration section with What,where and Type three data items configured. This is required for the Mount command, and the configuration in the example is equivalent to the following Mount command:
Mount–t Debugfs/sys/kernel/debug Debugfs
The configuration unit file writing needs a lot of learning, must refer to systemd with the man and other documents for in-depth study. I hope that through the above several small examples, we have learned about the role of the configuration unit file and the general wording.

My summary: The SYSTEMD feature is more powerful and is a new system tool for some Linux distributions to replace the system boot init and service, while not losing compatibility with Init.