# systemctl --type=service
# systemctl [ status | start | stop ] servei.service # systemctl enable servei.service
# systemctl isolate [ multi-user.target | graphical.target ] # systemctl get-default
# systemctl set-default [ multi-user.target | graphical.target ]
# systemctl [ poweroff | reboot ]
systemctl: is a systemd utility which is responsible for Controlling the systemd system and service manager.
Systemd is a collection of system management daemons, utilities and libraries which serves as a replacement of System V init daemon. Systemd functions as central management and configuration platform for UNIX like system.
Systemctl accepts services (.service), mount point (.mount), sockets (.socket) and devices (.device) as units.
Types:
Service units:
A unit configuration file whose name ends in .service encodes information about a process controlled and supervised by systemd.
systemd service units are the units that actually executes and keeps track of programs and daemon, and dependencies are used to make sure that services are started in the right order. They are the most commonly used type of units.
Socket units:
A unit configuration file whose name ends in ".socket"
encodes information about an IPC or network socket or a file system FIFO controlled and supervised by systemd, for
socket-based activation.
socket units on the other hand don't actually start daemons on their own, instead they just sit there and listen on an ip and a port, or a UNIX domain socket, and when something connects to it the daemon that the socket is for is started and the connection is handed to it.
This is useful for making sure that big daemons that take up a lot of resources but is used rarely aren't running and taking up resources all the time, but instead are only started when needed.
Target units:
A unit configuration file whose name ends in ".target"
encodes information about a target unit of systemd, which is used for grouping units and as well-known synchronization points during start-up.
This project (2015-1-ES01-KA202-015858) has been funded with support from the European Commission. This publication reflects the views only of the author, and the Commission cannot be held responsible for any use which may be made of the information contained therein. “Creative Commons Attribution-ShareAlike 4.0 International” (https://creativecommons.org/licenses/by-sa/4.0/).
Targets are used for grouping and ordering units. They are somewhat of a rough equivalent to runlevels in that at different targets different services, sockets, and other units are started. Unlike runlevels they are much more free-form and you can easily make your own targets for ordering units, and targets have dependencies among themselves.
For instance, multi-user.target is what most daemons are grouped under, and it requires basic.target
to already be activated, which means that all services grouped under basic.target will be started before the ones in multi-user.target.
Status:
To check the status of a service on your system, you can use the status command:
systemctl status application.service
This will provide you with the service state, the cgroup hierarchy, and the first few log lines.
For instance, when checking the status of an Nginx server, you may see output like this:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor pre Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server an Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and This gives you a nice overview of the current status of the application, notifying you of any problems and any actions that may be required.
Checking services:
Here are also methods for checking for specific states. For instance, to check to see if a unit is currently active (running), you can use the is-active command:
systemctl is-active application.service
This will return the current unit state, which is usually active or inactive. The exit code will be "0" if it is active, making the result simpler to parse programatically.
To see if the unit is enabled, you can use the is-enabled command:
systemctl is-enabled application.service
This will output whether the service is enabled or disabled and will again set the exit code to "0" or
"1" depending on the answer to the command question.
Isolating Targets:
It is possible to start all of the units associated with a target and stop all units that are not part of the dependency tree. The command that we need to do this is called, appropriately, isolate. This is similar to changing the runlevel in other init systems.
For instance, if you are operating in a graphical environment with graphical.target active, you can shut down the graphical system and put the system into a multi-user command line state by isolating the multi-user.target. Since graphical.target depends on multi-user.target but not the other way around, all of the graphical units will be stopped.
Getting and Setting the Default Target This project (2015-1-ES01-KA202-015858) has been funded with support from the European Commission. This publication reflects the views only of the author, and the Commission cannot be held responsible for any use which may be made of the information contained therein. “Creative Commons Attribution-ShareAlike 4.0 International” (https://creativecommons.org/licenses/by-sa/4.0/).
The systemd process has a default target that it uses when booting the system. Satisfying the cascade of dependencies from that single target will bring the system into the desired state. To find the default target for your system, type:
systemctl get-default multi-user.target
If you wish to set a different default target, you can use the set-default. For instance, if you have a graphical desktop installed and you wish for the system to boot into that by default, you can change your default target accordingly:
sudo systemctl set-default graphical.target
Shut down system or Reboot:
To initiate a full shutdown, you can use the poweroff command:
sudo systemctl poweroff
A restart can be started with the reboot command:
sudo systemctl reboot
Main folders
/usr/lib/systemd/system/
/etc/systemd/system/
Unit files in the earlier directories override later ones. This is a useful scheme, because it lets you make changes in the /etc directory, where configuration is expected. You should avoid making changes in /usr. Your system installs package data there that’s not expected to change.
systemd can also run in a user context, and manage resources per user in addition to system-side. Unit files for user units are stored similarly in /etc/systemd/user,
/run/systemd/user, and /usr/lib/systemd/user. The order of precedence works similarly.
References:
http://unix.stackexchange.com/questions/159462/what-is-systemds-target-service-and-socket https://fedoramagazine.org/systemd-getting-a-grip-on-units/
This project (2015-1-ES01-KA202-015858) has been funded with support from the European Commission. This publication reflects the views only of the author, and the Commission cannot be held responsible for any use which may be made of the information contained therein. “Creative Commons Attribution-ShareAlike 4.0 International” (https://creativecommons.org/licenses/by-sa/4.0/).
Laboratory
Service management and target changing
[ root@server ] # yum install httpd -y // Instaling Apache web server [ root@server ] # ls /usr/lib/systemd/system/ | grep httpd // Looking for httpd service
[ root@server ] # systemctl status httpd.service
[ root@server ] # ss -tlp | grep http // Looking for httpd process, its missing
[ root@server ] # systemctl start httpd.service [ root@server ] # systemctl status httpd.service
[ root@server ] # ss -tlp | grep http // Now can see the httpd process [ root@server ] # systemctl status httpd.service [ root@server ] # ss -tlp | grep http
This project (2015-1-ES01-KA202-015858) has been funded with support from the European Commission. This publication reflects the views only of the author, and the Commission cannot be held responsible for any use which may be made of the information contained therein. “Creative Commons Attribution-ShareAlike 4.0 International” (https://creativecommons.org/licenses/by-sa/4.0/).