Describe the init program.
- Either the init program or systemd is the parent process for every service on a Linux system. It typically has a PID of 1.
- The program is located in the
/etc/, the/bin/, or the/sbin/directory. - On systemd servers, this program is a symbolic link to
/usr/lib/systemd/systemd.
Summarize systemd unit concepts.
- A systemd unit defines a service, a group of services, or an action
- There are currently 12 different systemd unit types.
- To view load units, use the systemctl list-units command.
- The four systemd units to focus on are service, target, mount, and automount.
Explain systemd service units and their files.
- Service units control how services are started, stopped, and managed.
- Their unit files contain configuration information via directives in one of the three primary unit file sections:
[Unit],[Service], and[Install]. - Directives, such as After and Before, configure when a service will be started. While the [Unit] and [Install] file sections are common to all unit files, the [Service] section and its directives are unique to services.
- Unit files may exist in one of three directory locations, and their location is important because if multiple files exist for a particular unit, one takes precedence over the other depending on its whereabouts.
Explain systemd target units and their files.
- Target units are responsible for starting groups of services.
- At system initialization, the default.target unit ensures that all required and desired services are launched. It is set up as a symbolic link to another target unit file.
- The primary target units used for system initialization are
graphical.target,multi-user.target, andrunleveln.target, where n = 1–5 for the desired SysV init runlevel experience. - There are additional target units, which handle system power off, halt, and reboot as well as emergency and rescue modes.
- The target type unit files are similar to service unit files, but they typically contain fewer directives.
Demonstrate how to manage systemd systems via commands.
- The systemctl utility contains many commands that allow you to manage and control systemd units.
- You can jump between targets using the systemctl isolate command.
- You can set particular services to start at system boot time via the systemctl enable command and vice versa via the systemctl disable command. Additional commands allow you to start, stop, restart, and reload units as well as reload their unit files via the
systemctl daemon-reloadcommand. - Helpful commands such as
systemctl is-system-runningandsystemctl get-defaultaid you in assessing your current systemd system. - You can employ the
systemd-analyzeseries of commands to evaluate your server’s initialization process and find ways to improve it.
Summarize SysV init concepts.
- The classic SysV init method consists of the
/etc/inittabfile, which sets the default runlevel via the initdefault record. - Runlevels determine what services are started, and the default runlevel determines what services are started at system initialization. The rc script starts and stops services depending on what runlevel is chosen. It executes the scripts in the appropriate runlevel directory and passes the appropriate stop or start parameter.
- The scripts located in the various runlevel directories are symbolic links to the files within the
/etc/init.d/directory.
Demonstrate how to manage SysV init systems via commands.
- You can determine a SysV init system’s previous and current runlevel via the runlevel command. Runlevels can be jumped into via the init or telinit command.
- Services can have their status checked; have their configuration files be reloaded; or be stopped, started, or restarted with the status command.
- You can view all currently loaded services on a SysV init system by using the service
––status-allcommand. Services are enabled or disabled through either thechkconfigor theupdate-rc.dcommand, depending on your distribution
Describe systemd mount and automount unit files.
If your server employs systemd, besides managing system initialization, it can also persistently attach filesystems. These filesystems can be mounted or automounted via their associated unit files.
Mount and automount unit filenames are based on the filesystem mount point but use the .mount or .automount filename extension, respectively. Their unit file contents have three sections, similar to service unit files, except the mount unit file’s middle section is [Mount], whereas the automount unit file’s middle section is [Automount]. Each unit file has its own special directives that designate what partition is supposed to be mounted at the mount point and other items such as, for automount units, how long a filesystem must be idle before it can be unmounted.
The init program may be located in which of the following directories? (Choose all that apply.)
/etc/rc.d/ /etc/ /sbin/ /usr/lib/systemd/ /bin/
B, C, E. The init program may exist in the /etc/, /sbin/, or /bin/ directory, depending on your distribution and its version, so therefore options B, C, and E are correct. The /etc/rc.d/ directory is used in SysVint systems and is not a location for the init program, so option A is a wrong answer. The /etc/lib/systemd/ directory is the location of the systemd program, and thus option D is also an incorrect choice.
Which of the following is true concerning systemd service units? (Choose all that apply.)
Services can be started at system boot time. Services can be started in parallel. A service can be started based on a timer. A service can be started after all other services are started. A service can be prevented from starting at system boot time.
A, B, C, D, E. This is a tricky question, because all of these statements are true concerning systemd service units. It makes you realize that systemd-managed systems are very flexible.
Which of the following is not a systemd target unit?
runlevel7.target emergency.target graphical.target multi-user.target rescue.target
A. There is no runlevel7.target. The legitimate systemd targets, which provide backward SysV init compatibility, go from runlevel0.target through runlevel6.target. Therefore, option A is the correct answer.
The emergency.target is a special systemd target unit used to enter emergency mode. When your system goes into emergency mode, the system only mounts the root filesystem and mounts it as read-only. Therefore, option B is a systemd target unit and not a correct answer. The graphical.target is a legitimate systemd target, which provides multiple users access to the system via local terminals and/or through the network and offers a GUI. Thus, option C is an incorrect choice. The multi-user.target is also a legitimate systemd target, just like the graphical.target, except that it does not offer a GUI. Therefore, option D is also a wrong answer. The rescue.target is like emergency.target, but it mounts the root filesystem for reading and writing. Therefore, option E is an incorrect choice.
You need to modify a systemd service unit configuration. Where should the modified file be located?
/etc/system/systemd/ /usr/lib/system/systemd/ /etc/systemd/system/ /usr/lib/systemd/system/ /run/system/systemd/
C. Any modified systemd service unit configuration file should be stored in the /etc/systemd/system/ directory. This will prevent any package upgrades from overwriting it and keep the directory precedence from using the unmodified service unit copy, which may reside in the /usr/lib/systemd/system/ directory. The directories in options A and B are made up. The /usr/lib/systemd/system/ directory should only store unmodified unit files, which are provided by default, and thus option D is an incorrect answer. The /run/system/systemd/ directory is also made up.
On your server, you need Service-B to start immediately before Service-A. Within the systemd Service-A unit configuration file, what directive should you check and potentially modify?
Conflicts Wants Requires Before After
E. For starting Service-B immediately before starting Service-A, the Service-A unit configuration file will need to employ the After directive, set to something like After=Service-B.unit. Therefore, option E is the correct answer. The Conflicts directive sets the unit to not start with the designated units. If any of the designated units start, this unit is not started. Therefore, option A is a wrong answer. The Wants directive sets the unit to start together with the designated units. If any of the designated units do not start, this unit is still started. Therefore, option B is also an incorrect answer. The Requires directive sets the unit to start together with the designated units. If any of the designated units do not start, this unit is not started. Thus, option C is a wrong choice. The Before directive sets this unit to start before the designated units. While this should be set in Service-B’s unit configuration file, it does not apply, in this case, to Service-A’s configuration file. Therefore, option D is also an incorrect answer.
For setting environment parameters within a unit configuration file, which directives should you potentially employ? (Choose all that apply.)
Type Environment EnvironmentParam EnvironmentFile PATH
B, D. Linux systems use environment variables to store information about the shell session and working environment. If you need to ensure that a particular environment variable is set properly for your service, you need to use the Environment directive and/or the EnvironmentFile directive for setting environment parameters. Therefore, options B and D are correct answers.
The Type directive sets the unit startup type, which can be, for example, forking. Thus, option A is a wrong answer. The EnvironmentParam is a made-up directive. PATH is an environment variable, which you may modify for your unit’s environmental parameters. However, it is not a directive.
You attempt to jump to a systemd target using the systemctl isolate command, but it will not work. You decide to look at the target unit file. What might you see there that is causing this problem?
static AllowIsolate=yes Type=oneshot AllowIsolate=no disabled
D. If a target unit file has the AllowIsolate=no setting, the target cannot be used with the systemctl isolate command. Therefore, option D is the correct answer. Option A’s static is an enablement state displayed for a unit file via the systemctl –list-unit-files command. Thus, option A is a wrong answer. The AllowIsolate=yes directive permits the target to be used with the systemctl isolate command. Therefore, option B is also an incorrect choice. The Type=oneshot is a service unit directive, and you would not find it in a target unit file. Thus, option C is a wrong answer. Option E’s disabled is also an enablement state, like static, making option E a wrong choice as well.
You have modified an OpenSSH service’s configuration file, /etc/ssh/ssh_config. The service is already running. What is the best command to use with systemctl to make this modified file take immediate effect?
reload daemon-reload restart mask unmask
A. The best command to make the modified file take immediate effect for the OpenSSH service is systemctl reload. This command will load the service configuration file of the running designated service without stopping the service. Therefore, option A is the best answer.
A daemon-reload will load the unit configuration file and not the service configuration file.
The restart command will stop and immediately restart the service. While this will load the modified service configuration file, it will also disrupt the service for current service users. The mask command prevents a particular service from starting; the unmask command undoes the mask command’s effects.
Your system uses systemd and has a service currently set to not start at system boot. You want to change this behavior and have it start. What systemctl command should you employ for this service?
restart start isolate disable enable
E. To set a particular service unit to start at boot time, you need to use the systemctl enable command followed by the service unit name. Therefore, option E is the correct answer. The restart command will stop and immediately restart the service but does not control whether or not a service unit is started at system boot. The start command will start the service but does not control whether or not a service unit is started at system boot. The isolate command is used with systemd target units, not service units. Option D’s disable command will set a particular service unit to not start at boot time (disable it from starting).
You need to change the system’s default target. What systemctl command should you use to accomplish this task?
get-default set-default isolate is-enabled is-active
B. To change the system’s default target, you need to employ the systemctl set-default command, passing the target name as an argument and using super user privileges. The get-default command will show you the system’s current default target. The isolate command is used to jump to new targets and not to set default targets. The is-enabled command displays enabled for any service that is configured to start at system boot and disabled for any service that is not configured to start at system boot. It only deals with services, and therefore option D is a wrong choice. The is-active command also only deals with services.
Your systemd system is taking a long time to boot and you need to reduce the boot time. Which systemd-analyze command is the best to start narrowing down which units need to be investigated first?
time dump failure blame verify
D. The blame command displays the amount of time each running unit took to initialize, and the units and their times are listed starting from the slowest to the fastest. That way, you can start investigating the units at the list’s top. The time command displays the amount of time system initialization spent for the kernel, and the initial RAM filesystem, as well as the time it took for normal system user space to initialize. However, it does not help you determine which unit configurations may be to blame for the slow boot. The dump command displays data concerning all the units and the data is not in a format that lets you easily track down what unit takes the most time to initialize at boot. Therefore, option B is an incorrect choice. Option C’s failure is a service state, indicating that the service has failed. The verify command is handy in that it scans unit files and displays warning messages if any errors are found. However, it does not provide configuration information that can assist you in uncovering the reason a system is slow to boot.
Your older Debian-based Linux distribution system uses SysV init. It will soon be upgraded to a Debian-based distro that uses systemd. To start some analysis, you enter the runlevel command. Which of the following are results you may see? (Choose all that apply.)
N 5 3 5 N 2 2 3 1 2
C, E. Debian-based Linux distributions that use SysV init only use runlevels from 0 through 2. The runlevel command shows the previous runlevel, or N for newly booted. Therefore, the only options that this runlevel command would show on an older Debian-based Linux distribution system, which uses SysV init, are C and E. Option A is incorrect, because it shows 5 as the current runlevel, and Debian-based distros don’t use that runlevel. Option B is also incorrect, because it also shows 5 as the current runlevel. Option D is incorrect because it shows 3 as the current runlevel, and the Debian-based distros do not use that runlevel either.
You’ve recently become the system administrator for an older Linux server, which still uses SysV init. You determine that its default runlevel is 3. What file did you find that information in?
/etc/inittab /etc/rc.d /etc/init.d/rc /etc/rc.d/rc /etc/rc.local
A. For SysV init systems, the default runlevel is stored within the /etc/inittab file within the initdefault record. Therefore, option A is the correct answer. The /etc/rc.d is a directory and not a file. Thus, option B is a wrong answer. The rc file is a script that can reside in either the /etc/init.d/ or the /etc/rc.d/ directory. It runs the scripts that start the various system services when jumping runlevels or booting the system. However, this script does not contain any information concerning the default runlevel. Therefore, options C and D are incorrect choices. The /etc/rc.local file allows you to issue certain commands or run any scripts as soon as system initialization is completed. However, this script also does not contain any information concerning the default runlevel.
Which directory on an old SysV init system stores the service startup scripts?
/usr/lib/systemd/system/ /etc/rc.d/rc n .d/ /etc/init.d/ /etc/systemd/system/ /run/systemd/system/
C. The directory that stores the service startup scripts for an old (and a new) SysV init system is the /etc/init.d/ directory. Therefore, option C is the correct answer. The /etc/rc.d/rcn.d/ directories are used on a SysV init system, but they contain symbolic links to the scripts within the /etc/init.d/ directory. Thus, option B is an incorrect answer. Options A, D, and E are all systemd directories. Therefore, they are incorrect choices.
You are managing a SysV init system and need to perform some emergency maintenance at runlevel 1. To do this, you need to jump runlevels. What command could you employ? (Choose all that apply.)
telinit S telinit 1 init one init s init 1
A, B, D, E. Runlevel 1 is also called single-user mode. You can employ either the init or the telinit command to jump to that runlevel and pass them one of the three following arguments: 1, s, or S. Therefore, options A, B, D, and E are correct answers. You cannot use the one argument to reach runlevel 1, and therefore option C is the only wrong choice.
A customer has complained that a service on your SysV init system is not working. Which of the following commands is the best command to use to check the service?
service start service status service ––status-all service stop service reload
B. The best command to use is the service status command, passing the service name to it as an argument. This will display the service’s current status and allow you to start the troubleshooting process quickly. Therefore, option B is the correct answer. The service start command will start the designated service, but you do not know whether or not this service was stopped. Thus it is not the best command to use, and option A is an incorrect choice. The service –status-all command is not the best command to use because it shows the status of all the various services. Thus, option C is a wrong answer. The service stop command will stop the designated service and provide a FAILED status if it was already stopped. However, this is not the best way to check a service’s status on a SysV init system. The service reload command will load the designated service’s configuration file and provide a FAILED status if the service is stopped. Yet again, this is not the proper way to check a service’s status.
-
Chapter 228
-
Chapter 325
-
Chapter 424
-
Chapter 524
-
Chapter 629
-
Chapter 727
-
Chapter 827
-
Chapter 927
-
Chapter 1026
-
Chapter 1116
-
Chapter 1215
-
Chapter 1316
-
Chapter 1416
-
Chapter 1515
-
Chapter 1615
-
Chapter 1714
-
Chapter 1816
-
Chapter 1914
-
Chapter 2015
-
Chapter 2114
-
Chapter 2214
-
Chapter 2314
-
Chapter 2416
-
Chapter 2517
-
Chapter 2617
-
Chapter 2715
-
Chapter 2815
-
Chapter 2915
-
Chapter 3014
-
Domain 196
