5. wall
A sysadmin might send out a message like this:
$ wall The system will be going down in 15
minutes to address a serious problem
6. wall
Everyone logged into the system will see
something like this:
Broadcast message from admin@dragonfly
(pts/0) (Thu Mar 5 08:56:42 2020):
The system is going down in 15 minutes to
address a serious problem
7. wall
If you want to use single quote marks in your
message, enclose the message in double quote
marks like this:
$ wall “Don’t forget to save your work before
logging off”
The outside quote marks will not show up in the
transmitted message, but, without them, the
command sits and waits for a closing single quote.
8. mesg
If, for some reason, you don’t want to accept
messages from another user, you can stop them
from arriving with the mesg command. This
command can be used with a “n” argument to
refuse mail from the user or a “y” argument to
allow the messages to arrive.
$ mesg n doug
$ mesg y doug
9. mesg
The blocked user will not be notified that their
messages have been blocked. You can also block
or allow all messages with a mesg command like
one of these:
$ mesg y
$ mesg n
10. write
Another command for sending text without
reverting to email is write. This command can be
used to communicate with a specific user.
$ write nemo
Are you still at your desk?
I need to talk with you right away.
^C
11. write
If the user you are trying to write to has messages
blocked, you should see something like this:
$ write nemo
write: nemo has messages disabled
12. write
Enter your text and use ^C to exit when you’re
done. The command allows you to send text, but
doesn’t start a two-way conversation.
It just sends the text. If the user is logged in on
more than one terminal, you can specify which
terminal you want to send the message to or you
can rely on the system to choose the one with the
shortest idle time.
$ write nemo#1
13. talk/ytalk
The talk or ytalk command gives you a chance to
have an interactive chat with one or more other
users. The command will bring up a double-pane
(top and bottom) window.
Each individual will type into the top portion of the
display on their screen and see the responses in
the bottom section(s).
The respondents can respond to a talk request by
typing "talk" followed by the username of the
person addressing them.
15. talk/ytalk
The window can involve more than two
participants if ytalk is used.
As you can see in the example below (the result
of the "talk dory" command shown above), talk is
often ytalk.
----------------------------= YTalk version 3.3.0 =--------------------------
Is the report ready?
-------------------------------= nemo@dragonfly =----------------------------
Just finished it
16. talk/ytalk
As explained above, on the other side of the conversation, the talk session
window panes are reversed:
----------------------------= YTalk version 3.3.0 =--------------------------
Just finished it
-------------------------------= dory@dragonfly =----------------------------
Is the report ready?
Again, use ^C to exit.
17. talk/ytalk
To talk with someone on another system, you just need to add a -h option and
the hostname or IP address with a command like this:
$ talk -h 192.168.0.11 nemo
18. Active directory and components
Active Directory, LDAP and Kerberos shall be
covered in a future class after it is working on my
system. Requires a day or two to prepare well.
19. Systemctl
The systemctl command is a utility which is
responsible for examining and controlling the
systemd system and service manager.
It is a collection of system management libraries,
utilities and daemons which function as a
successor to the System V init daemon.
21. Systemctl
Managing Services
What is a Service?
In the systemd utility, a service is referred to as a
unit. A unit is any resource that the system knows
how to act on and administrate. A unit is the
principal object that the systemd tools know how
to address. These assets are defined in a
configuration file called a unit file.
22. Systemctl
Check Service Status
Using systemctl, we can check the status of any
systemd service on the managed dedicated
server. The status command provides information
about a service. It also lists the running state, or
detail on why it is not running, or if a service has
been stopped unintentionally. If we are connected
to the server as a non-root user, we will have to
run the systemctl commands using.
systemctl status servicename.service
23. Systemctl
This unit can be called without the .service
extension. Since systemctl will look for those files
with .service suffix, the command can also be
used like this.
systemctl start servicename
24. Systemctl
Example of status output:
[root@host ~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset:
disabled)
Active: active (running) since Fri 2020-05-08 14:15:54 EDT; 1 weeks 2 days ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 3767 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited,
status=0/SUCCESS)
Main PID: 1321 (httpd)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
CGroup: /system.slice/httpd.service
├─1321 /usr/sbin/httpd -DFOREGROUND
├─3769 /usr/sbin/httpd -DFOREGROUND
25. Systemctl
Starting or Stopping a Service
The systemctl utility can also be used to start or stop systemd services using a service
unit file, with or without that .service suffix.
systemctl start servicename.service
The same rules apply when we want to stop a specific service.
systemctl stop servicename.service
Keep in mind that the start order can only be used on systemd services that are not
currently running, and the stop command used only with running services.
26. Systemctl
Restarting or Reloading a Service
A running service can be restarted using the restart command to avoid stopping and
starting it manually using the following command.
systemctl restart servicename.service
Occasionally, we do not need to restart a service to apply configuration changes, if any
were you made. Instead, we can use the reload command to restart the service which
implements any changes to the running service.
systemctl reload servicename.serivce
If we are not sure about which of the two commands we should use, there is an additional
option using the reload-or-restart command which will automatically determine it for us.
systemctl reload-or-restart servicename.service
27. Systemctl
Enable or Disable a Service
When it comes to cloud server services, we require most of them to be online and active
all the time. Starting them manually is not a convenient method to employ, due to the
number of services required to run on a server. This is where the enable and disable
commands come into play. Using the enable command, we can modify how the systemd
service responds once the server has been started or rebooted. It will update the service
settings, which then tells systemd that the specific service needs to start up automatically,
once the server is up. The command to accomplish this is as follows.
systemctl enable servicename.service
While most of the services like HTTPD, MySQL, MariaDB, etc. will have already
automatically started, we may need to enable the automatic startup for some of them
manually. Similar to how we can set a service to automatically start when the server boots
up, we can also disable a service using the following command.
systemctl reload-or-restart servicename.service
The disable command prevents the automatic startup of a service at boot time, leaving it
inactive until it started manually.
28. Systemctl
System State Overview
All the systemctl commands that we have covered are mainly used to manage individual
services. Let's review some other commands systemctl has to offer and their uses.
30. Systemctl
What is a Unit File?
A unit file is a flat text file that contains information about a service, socket, device, mount
point, swap file, partition, start-up target, an asset management slice, or a group of
externally created processes.
Working with Unit Files
List Units
The list-units command displays all the active systemd services on your server. Our
output is similar to the information provided by the systemctl status command, but not as
detailed.
systemctl list-units
31. Systemctl
Here is the example of the output of that command.
root@host [~]# systemctl list-units
UNIT LOAD ACTIVE SUB DESCRIPTION
crond.service loaded active running Command Scheduler
dovecot.service loaded active running Dovecot IMAP/POP3 email server
firewalld.service loaded active running firewalld - dynamic firewall daemon
httpd.service loaded active running The Apache HTTP Server
mariadb.service loaded active running MariaDB database server
named.service loaded active running Berkeley Internet Name Domain (DNS)
32. Systemctl
Now that we have an example of the output, let's review the meaning of each column.
UNIT: The name of the systemd unit.
LOAD: This indicates if the unit's configuration is being loaded by systemd. If it is, the
configuration is stored in the server's memory.
ACTIVE: This states the status of the unit and shows whether it is active or not.
SUB: This provides more detailed information about the unit, which will vary depending
on the type of unit, state, and the method the unit runs in.
DESCRIPTION: This short description contains what each unit is and what it does.
33. Systemctl
Unit States
Using the systemctl list-units command will reveal all the units that are “loaded” and
“active” state in the LOAD and ACTIVE columns; however, if we wish to get a more
detailed list of all the services, we need to employ the usage of command flag. In this
case, the --all flag.
systemctl list-units --all
Using the -all flag, we can obtain a list of all the systemd units that are loaded or that
systemd has tried to load. This output will also show the services that are currently in an
inactive, dead, failed state, or that have not been found on the disk of the server.
34. Systemctl
While this flag provides the full output of all the units on the server, which systemd loaded
into memory, we can use additional flags to further filter the output of list-units. One of
them would be the --state= flag. We can use this flag to further filter the state in the
LOAD, ACTIVE, and SUB columns.
systemctl list-units --all --state=failed
Just as we can filter out the units by their state, we can also use the same type to
accomplish the same task.
systemctl list-units --all --type=mount
35. Systemctl
The list-units command displays the units that systemd has loaded or attempted to load
into memory. But, what about the units that are not in the systemd memory? This is where
the list-unit-files flag comes into play, as this command will display all available units on
the server.
systemctl list-unit-files
36. Systemctl
The output will be given in two columns with the name of a file and state.
UNIT FILE STATE
Proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount disabled
The STATE column had four different states, which are:
Enabled
Disabled
Static
Masked
37. Systemctl
Masked Units
As you can see in the output above, many of the units show a staticSTATE status. This indicates that
those units do not have an “install” section within the unit's configuration file, and therefore, cannot
be enabled. On the other hand, some units may be masked, and as such, we will not be able to start
it. Masked units will provide output using the start command if we attempt to launch it.
systemctl start servicename.service
Failed to start servicename.service: Unit is masked.
Unmasking a unit is simple and will return the unit to the state where it can be started or enabled.
systemctl unmask servicename.service
38. Systemctl
Creating a Unit File
Occasionally, we may need to create a unit file for a custom daemon or another instance of an
already existing service. The creation of a unit file is executed via the root user in the
/etc/systemd/system/ directory. This is accomplished like so.
touch /etc/systemd/system/servicename.service
chmod 644 /etc/systemd/system/servicename.service
39. Systemctl
Next, we will open the newly created unit file in a text editor (like vim or nano) and add the service
configuration options. Below, we can see a basic example of the unit file.
[Unit]
Description=This is the manually created service
After=network.target
[Service]
ExecStart=/path/to/executable
[Install]
WantedBy=multi-user.target
40. Systemctl
Let’s quickly breakdown what these settings mean before we proceed further:
Description: The description is the description of the service, and will be displayed when we use
the systemctl status command for the created service.
After: The After setting indicates that a service will only start on reboot after a specified target or
another service has been started.
ExecStart: The ExecStart is the path to the actual executable file of the service.
WantedBy: The WantedBy setting states the target that the service should start under. This is
similar to runlevels.
41. Systemctl
Once the service file has been created, we will need to tell the system about it with the following
commands.
systemctl daemon-reload
systemctl start servicename.service
42. Systemctl
Viewing a Unit File
Once the unit file has been created, we do not necessarily need to navigate to the file itself to see
what is written inside. The systemctl command has a feature that displays the content of the unit file
for us. It can be performed with the following command.
systemctl cat servicename.service
43. Systemctl
Viewing Dependencies
Just like we can see inside a unit file, we can also use the following command to display the
dependency tree of that unit.
systemctl list-dependencies servicename.service
[root@host ~]# systemctl list-dependencies httpd.service
httpd.service
● ├─-.mount
● ├─system.slice
● └─basic.target
● ├─microcode.service
● ├─rhel-dmesg.service
● ├─selinux-policy-migrate-local-changes@targeted.service
● ├─paths.target
● ├─slices.target
● │ ├─-.slice
● │ └─system.slice
44. Systemctl
There are a few useful flags that can be added to the command such as the --all flag which lists all
dependencies recursively, or --reverse which will list them in reverse order. There is also the --before
and --after flags which are used to show unit starting before or after the specified unit.
45. Systemctl
View Properties
Additionally, we can see the properties of a unit by using the show command.
systemctl show servicename.service
This will give you output similar to the one below.
[root@host ~]# systemctl show httpd.service
Type=notify
Restart=no
NotifyAccess=main
RestartUSec=100ms
TimeoutStartUSec=1min 30s
TimeoutStopUSec=1min 30s
WatchdogUSec=0
WatchdogTimestamp=Thu 2020-06-25 05:43:53 EDT
46. Systemctl
In case you are looking for a single setting, you can use -p flag with the setting name. For example,
to get the PID of a running service, use this command.
[root@host ~]# systemctl show httpd.service -p MainPID
MainPID=4004
47. Systemctl
Edit Unit Files
In cases where the unit files need to be modified, systemctl has a built-in editing system that allows
us to modify unit files without searching for them on the server. This can be done using the edit
command.
systemctl edit httpd.service
This creates a directory in /etc/systemd/system named the same as the service with a .d appended
to it. It looks this: /etc/systemd/system/httpd.service.d.
This is where the edits would be stored, and any directives within this file would override the main
unit file. The snippet created in that directory would be named override.conf. In case we wish to edit
using file itself rather than creating a snippet, we can use the following command.
systemctl edit --full httpd.service
48. Systemctl
Removing Unit Files
Removing a unit file and overriding snippets can be accomplished using the following commands.
rm -r /etc/systemd/system/httpd.service.d
We can use the command below to remove the snippet directory, which overrides directives and
removes the full modified unit file.
rm /etc/systemd/system/httpd.service
Whenever we make edits or remove any of the unit files, we need to make sure that changes are
applied by using this command.
systemctl daemon-reload
49. Systemctl
Using Targets (Runlevels)
What is a Systemd Target?
When it comes to unit files, there are special files that we call targets that describe a system state or
synchronization point. These files can be identified by a suffix, which is called .target.
What are these .target files for? They can be used to change the system to certain states, similar to
how other init systems use runlevels.
50. Systemctl
List Targets
There is a number of target files on the server systems, and we can list them using the following
command.
systemctl list-unit-files --type=target
While working with runlevels, activating the runlevels is done one at a time, but when it comes to
targets, we can activate multiple targets at once. In order to see all active targets, we use the
following command.
systemctl list-units --type=target
51. Systemctl
Stopping or Rebooting the Server
Finally, we can use systemctl to stop the server, power it off, or to reboot it. For stopping the server,
we use the following halt command.
systemctl halt
To completely shut down the server, we use poweroff command.
systemctl poweroff
And to reboot the server, we can use the reboot command.
systemctl reboot
