{"id":803,"date":"2014-10-09T10:44:57","date_gmt":"2014-10-09T13:44:57","guid":{"rendered":"http:\/\/blog.abratel.com.br\/?p=803"},"modified":"2014-10-09T11:15:04","modified_gmt":"2014-10-09T14:15:04","slug":"restarting-services-in-red-hat-7-or-centos-7-using-systemctl","status":"publish","type":"post","link":"https:\/\/blog.abratel.com.br\/?p=803","title":{"rendered":"Restarting Services in Red Hat 7 or CentOS 7 using systemctl (init.d –> systemctl)"},"content":{"rendered":"

# systemctl -t service <\/p>\n

Para parar um servi\u00e7o em execu\u00e7\u00e3o no sistema: <\/p>\n

# systemctl stop iptables.service <\/p>\n

Para iniciar um servi\u00e7o no sistema: <\/p>\n

# systemctl start httpd.service <\/p>\n

Para desativar um servi\u00e7o no sistema: <\/p>\n

# systemctl disable sendmail.service <\/p>\n

Para ativar um servi\u00e7o no sistema: <\/p>\n

# systemctl enable crond.service <\/p>\n

Conferir se servi\u00e7os est\u00e3o ativos ou n\u00e3o: <\/p>\n

# systemctl is-enabled iptables.service <\/p>\n

Qualquer d\u00favida: <\/p>\n

# man systemctl <\/p>\n

——————————————————————————–<\/p>\n

Q: I just recently installed CentOS 7 and am so confused. How do I restart services like sshd and crond?<\/p>\n

A: Red Hat 7 and CentOS 7 have now moved to systemd as their default system management daemon. Systemd is different from the old default init system in too many ways to describe here. But let’s get to the meat of your question.<\/p>\n

The new way to control system daemons is with the systemctl command. If you are used to the old init scripts (e.x. \/etc\/init.d\/sshd) the new syntax can be slightly confusing. For example, this is how we used to restart SSHD with the old upstart init scripts:<\/p>\n

\r\n\/etc\/init.d\/sshd restart \r\n<\/pre>\n
or<\/p>\n
\r\nservice sshd restart\r\n<\/pre>\n
In systemd (Fedora 18 or above, RHEL 7, and CentOS 7) we need to use the systemctl command, like so:<\/p>\n
\r\nsystemctl restart sshd.service\r\n<\/pre>\n
To stop the sshd service, you would use:<\/p>\n
\r\nsystemctl stop sshd.service\r\n<\/pre>\n
To start the sshd service, you would use:<\/p>\n
\r\nsystemctl start sshd.service\r\n<\/pre>\n
To see the status of the sshd service, you would use:<\/p>\n
systemctl status sshd.service<\/pre>\n
The old \/etc\/init.d\/ scripts are still available for some services for legacy support and backward compatibility.  But you should get into the habit of using the new systemctl command because they can be removed in future updates or releases.<\/p>\n
NOTE: You will have to be root to perform all of the commands listed on this page.  If you prefer you can prepend sudo in front of the commands to use sudo instead of directly accessing the root account. This works in Fedora 18 and above, Red Hat 7 and CentOS 7.<\/p>\n
———————————————————————————————–<\/p>\n
One of the major changes in RHEL  \/ CentOS 7.0 is the swtich to systemd, a system and service manager, that replaces SysV and Upstart used in previous releases of Red Hat Enterprise Linux. systemd is compatible with SysV and Linux Standard Base init scripts.<\/p>\n
Systemd is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, support for system state snapshots, or dependency-based service control logic.<\/p>\n
Previous versions of Red Hat Enterprise Linux, which were distributed with SysV init or Upstart, used init scripts written in bash located in the \/etc\/rc.d\/init.d\/ directory. In RHEL 7 \/ CentOS 7, these init scripts have been replaced with service units. Service units end with the .service file extension and serve a similar purpose as init scripts. To view, start, stop, restart, enable, or disable system services you will use the systemctl instead of the old service command.
\nNote: for backwards compatibility the old service command is still available in CentOS 7 and it will redirect any command to the new systemctl utility.
\nStart\/Stop\/Restart Services with systemctl<\/p>\n
To start a service with systemctl you will need to use the command like this:<\/p>\n
    # systemctl start httpd.service <\/pre>\n
This will start the httpd service, in our case Apache HTTP Server.<\/p>\n
To stop it use this command as root:<\/p>\n
  \r\n    # systemctl stop httpd.service <\/pre>\n
To restart you can use either the restart options, it will restart the service if it’s running or start it if it’s not running. You can also use the try-restart option that will restart the service only if it’s already running. Also you have the reload option that will reload the configuration files.<\/p>\n
  \r\n    # systemctl restart httpd.service\r\n    # systemctl try-restart httpd.service\r\n    # systemctl reload httpd.service\r\n<\/pre>\n
The commands in our example look like this:<\/p>\n
\"systemctl-enable\"<\/a>
\nChecking the status of a service<\/p>\n
To check the status of a service you can use the status option like this:<\/p>\n
  \r\n    # systemctl status httpd.service <\/pre>\n
And the output should look like this:
\n\"systemctl-status\"<\/a><\/p>\n
Informing you of various aspects of the running service.
\nEnable \/ Disable services to run at boot time<\/p>\n
You can also use the enable \/ disable options to make a service run at boot time, using the command like this:<\/p>\n
  \r\n    # systemctl enable httpd.service\r\n    # systemctl disable httpd.service\r\n<\/pre>\n
Although the adoption of systemd has been very controversial in the last few years, slowly most of the major Linux distributions have either adopted or are planning to have it in the next point release, so it’s a useful tool to get used to.
\n– See more at: http:\/\/linoxide.com\/linux-command\/start-stop-services-systemd\/#sthash.qiGQNlM4.dpuf<\/p>\n
———————————————————————————————-<\/p>\n
Say hello to systemctl command<\/p>\n
Use this command to control the systemd system and act as a service manager.
\nCentOS 7 \/ RHEL 7 get status of network service<\/p>\n
\r\nsudo systemctl status network.service <\/pre>\n
OR<\/p>\n
\r\nsudo systemctl status network <\/pre>\n
Sample outputs:
\nFig.01: CentOS \/ RHEL 7 Networking Service Status Command<\/p>\n
Fig.01: CentOS \/ RHEL 7 Networking Service Status Command<\/p>\n
CentOS 7 \/ RHEL 7 restart network service<\/p>\n
\r\nsudo systemctl restart network.service\r\n<\/pre>\n
OR<\/p>\n
 sudo systemctl restart network <\/pre>\n
CentOS 7 \/ RHEL 7 start network service<\/p>\n
 sudo systemctl start network.service <\/pre>\n
OR<\/p>\n
 sudo systemctl start network <\/pre>\n
CentOS 7 \/ RHEL 7 stop network service<\/p>\n
\r\nsudo systemctl stop network.service\r\n<\/pre>\n
OR<\/p>\n
\r\nsudo systemctl stop network <\/pre>\n
——————————————————————————————————————-<\/p>\n
With Red Hat Enterprise Linux 7 released and CentOS version 7 newly unveiled, now is a good time to cover systemd, the replacement for legacy System V (SysV) startup scripts and runlevels. Red Hat-based distributions are migrating to systemd because it provides more efficient ways of managing services and quicker startup times. With systemd there are fewer files to edit, and all the services are compartmentalized and stand separate from each other. This means that should you screw up one config file, it won’t automatically take out other services.<\/p>\n
Systemd has been the default system and services manager in Red Hat Fedora since the release of Fedora 15, so it is extensively field-tested. It provides more consistency and troubleshooting ability than SysV \u2013 for instance, it will report if a service has failed, is suspended, or is in error. Perhaps the biggest reason for the move to systemd is that it allows multiple services to start up at the same time, in parallel, making machine boot times quicker than they would be with legacy runlevels.<\/p>\n
Under systemd, services are now defined in what are termed unit files, which are text files that contain all the configuration information a service needs to start, including its dependencies. Service files are located in \/usr\/lib\/systemd\/system\/. Many but not all files in that directory will end in .service; systemd also manages sockets and devices.<\/p>\n
No longer do you directly modify scripts to configure runlevels. Within systemd, runlevels have been replaced by the concept of states. States can be described as “best efforts” to get a host into a desired configuration, whether it be single-user mode, networking non-graphical mode, or something else. Systemd has some predefined states created to coincide with legacy runlevels. They are essentially aliases, designed to mimic runlevels by using systemd.<\/p>\n
States require additional components above and beyond services. Therefore, systemd uses unit files not only to configure services, but also mounts, sockets, and devices. These units’ names end in .sockets, .devices, and so on.<\/p>\n
Targets, meanwhile, are logical groups of units that provide a set of services. Think of a target as a wrapper in which you can place multiple units, making a tidy bundle to work with.<\/p>\n
Unit files are built from several configurable sections, including unit descriptions and dependencies. Systemd also allows administrators to explicitly define a service’s dependencies and load them before the given service starts by editing the unit files. Each unit file has a line that starts After= that can be used to define what service is required before the current service can start. WantedBy=lines specify that a target requires a given unit.<\/p>\n
Targets have more meaningful names than those used in SysV-based systems. A name like graphical.target gives admins an idea of what a file will provide! To see the current target at which the system is residing, use the command systemctl get-default. To set the default target, use the command systemctl set-default targetname.target. targetname can be, among others:<\/p>\n
    rescue.target
\n    multi-user.target
\n    graphical.target
\n    reboot.target<\/p>\n
Looking at the above it becomes obvious that although there is no direct mapping between runlevels and targets, systemd provides what could loosely be termed equivalent levels.<\/p>\n
Another important feature systemd implements is cgroups, short for control groups, which provide security and manageability for the resources a system can use and control. With cgroups, services that use the same range of underlying operating system calls are grouped together. These control groups then manage the resources they control. This grouping performs two functions: it allows administrators to manage the amount of resources a group of services gets, and it provides additional security in that a service in a certain cgroup can’t jump outside of cgroups control, preventing it for example from getting access to other resources controlled by other cgroups.<\/p>\n
Cgroups existed in the old SysV model, but were not really implemented well. systemd attempts to fix this issue.
\nFirst steps in systemd<\/p>\n
Under systemd you can still use the service and chkconfig commands to manage those additional legacy services, such as Apache, that have not yet been moved over to systemd management. You can also use service command to manage systemd-enabled services. However, several monitoring and logging services, including cron and syslog, have been rewritten to use the functionality that is available in systemd, in part because scheduling and some of the cron functionality is now provided by systemd.<\/p>\n
You can also manage systemd with a GUI management tool called systemd System Manger, though it is not usually installed by default. To install it, as root, run yum -y install systemd-ui.<\/p>\n
How can you start managing systemd services? Now that Centos 7 is out of the starting gate we can start to experiment with systemd and understand its operation. To begin, as the root user in a terminal, type chkconfig. The output shows all the legacy services running. As you can see by the big disclaimer, most of the other services that one would expect to be present are absent, because they have been migrated to systemd management.<\/p>\n
Red Hat-based OSes no longer use the old \/etc\/initab file, but instead use a system.default configuration file. You can symlink a desired target to the system.default in order to have that target start up when the system boots. To configure the target to start a typical multi-user system, for example, run the command below:<\/p>\n
\r\nln -sf \/lib\/systemd\/system\/multi-user.target \/etc\/systemd\/system\/default.target\r\n<\/pre>\n
After you make the symlink, run systemctl, the replacement for chkconfig. Several pages of output display, listing all the services available:
\nsystemctl<\/p>\n
\"systemctl-resized-600\"<\/a><\/p>\n
    Unit \u2013 the service name
\n    Load \u2013 gives status of the service (such as Loaded, Failed, etc.)
\n    Active \u2013 indicates whether the status of the service is Active
\n    Description \u2013 textual description of the unit<\/p>\n
The key commands and arguments in systemctl are similar to the legacy ones found in chkconfig \u2013 for example, systemctl start postfix.service.<\/p>\n
In the same vein, use systemctl stop and systemctl status to stop services or view information. This syntax similarity to chkconfig arguments is by design, to make the transition to systemd as smooth as possible.<\/p>\n
To see all the services you can start using systemctl and their statuses, use the command<\/p>\n
systemctl list-unit-files –type=service<\/p>\n
services
\n\"services-resized-600\"<\/a><\/p>\n
While you can no longer enable a runlevel for a service using chkconfig –level, under systemd you can enable or disable a service when it boots. Use systemctl enable service to enable a service, and systemctl disable service to keep it from starting at boot. Get a service’s current status (enabled or disabled) with the command systemctl is-enabled service.
\nFinal thoughts on systemd<\/p>\n
It may take you some time to get used to systemd, but you should plan to use it now before it becomes a requirement and management through legacy tools is no longer available. You should find that systemd makes managing services easier than it used to be with SysV.<\/p>\n","protected":false},"excerpt":{"rendered":"
# systemctl -t service Para parar um servi\u00e7o em execu\u00e7\u00e3o no sistema: # systemctl stop iptables.service Para iniciar um servi\u00e7o no sistema: # systemctl start httpd.service Para desativar um servi\u00e7o no sistema: # systemctl disable sendmail.service Para ativar um servi\u00e7o no sistema: # systemctl enable…<\/p>\n","protected":false},"author":1,"featured_media":808,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/posts\/803"}],"collection":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=803"}],"version-history":[{"count":6,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/posts\/803\/revisions"}],"predecessor-version":[{"id":818,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/posts\/803\/revisions\/818"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=\/wp\/v2\/media\/808"}],"wp:attachment":[{"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.abratel.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}