LFCS Service Configuration — Timed 40 Questions

Question 1

An administrator wants to ensure that a custom service (myapp.service) starts only after the network is available and the PostgreSQL database service is running. Which systemd unit file directive should be used?

40 minute time limit — choose an answer to begin.

Accepted Answer

After=network.target postgresql.service. The `After=` directive in a systemd unit file specifies ordering constraints, ensuring that `myapp.service` starts only after `network.target` and `postgresql.service` have reached the 'started' state. This does not create a dependency that forces those units to start; it only orders the startup sequence, which is exactly what the administrator needs to guarantee the service starts after the network and PostgreSQL are available.

Answer

Requires=network.target postgresql.service

Answer

Wants=network.target postgresql.service

Answer

BindsTo=network.target postgresql.service

Question 2

Which TWO statements are true about systemd service unit files? (Choose two.)

Accepted Answer

The [Service] section is mandatory for a service unit file.. Option C is correct because a systemd service unit must contain a [Service] section, which holds the directives defining how the service is executed (e.g., ExecStart, Type, Restart); without it, systemd cannot treat the unit as a service. Option D is correct because the [Install] section supplies installation-time directives such as WantedBy= and RequiredBy=, which systemctl enable uses to create the appropriate symlinks under /etc/systemd/system/*.wants/ or *.requires/ so the unit starts at boot. Option A is wrong because the correct directive is EnvironmentFile= (not EnvFile=), which loads variables from a file. Option B is wrong because the default Type= is 'simple', not 'forking'. Option E is wrong because section order within a unit file is not significant; systemd parses sections regardless of their position.

Answer

Environment variables can be loaded using EnvFile= directive.

Answer

The default service type is 'forking'.

Answer

The [Service] section must appear before the [Unit] section.

Question 3

A system administrator is configuring a custom systemd service that runs a Python script. The script logs output to stdout. The administrator wants to ensure that the service restarts automatically if it crashes, but only after a 10-second delay. Which directive should be added to the [Service] section of the unit file?

Accepted Answer

Restart=on-failure
RestartSec=10. `Restart=on-failure` ensures the service restarts only when it exits with a non-zero exit code or is terminated by a signal (e.g., SIGKILL), which matches the 'crashes' scenario. Adding `RestartSec=10` introduces a 10-second delay before the restart attempt, as required. The other options either restart on success (irrelevant) or always restart (which would restart even on intentional stops), or omit the restart condition entirely.

Answer

Restart=on-success
RestartSec=10

Answer

Restart=always
RestartSec=10

Answer

RestartSec=10

Question 4

A company runs a critical web application on a Linux server. The application is managed by a systemd service called 'myapp.service'. Recently, after a scheduled maintenance reboot, the service failed to start automatically. The administrator manually started it with 'systemctl start myapp' and it ran fine. The unit file is located at /etc/systemd/system/myapp.service and contains: [Unit] Description=MyApp After=network.target [Service] ExecStart=/usr/local/bin/myapp Restart=on-failure [Install] WantedBy=multi-user.target. The administrator wants to ensure the service starts automatically after future reboots. However, after running 'systemctl enable myapp', the service still didn't start after the next reboot. What is the most likely cause?

Accepted Answer

The service depends on a target that is not reached before the service starts, and 'Restart=on-failure' does not retry the start if the condition is not met.. The 'After=network.target' directive only specifies ordering, not a requirement. If the network target is not fully reached before the service starts, systemd will attempt to start the service once and, if it fails, 'Restart=on-failure' will restart it only if the start was successful but the process later exits with a failure. It does not retry the initial start if a dependency condition is not met. The service must have 'Requires=network.target' or 'Wants=network.target' to ensure the target is active before the service starts.

Answer

The 'systemctl enable' command only creates symlinks; a separate 'systemctl start' must be run after enable.

Answer

The 'systemctl enable' command was not run as root.

Answer

The unit file has a syntax error that prevents systemd from parsing it.

Question 5

Match each Linux process signal to its numeric value.

Accepted Answer

SIGKILL: 9. Common Linux signal numbers: SIGKILL=9, SIGTERM=15, SIGSTOP=19, SIGCONT=18, SIGINT=2. Distractors mix up these values.

Answer

SIGKILL: 15

Answer

SIGCONT: 25

Answer

SIGINT: 9

Question 6

A system administrator wants to limit the CPU usage of a service. Which systemd resource control directive should be used?

Accepted Answer

CPUAccounting=yes and CPUQuota. To limit CPU usage in systemd, you must first enable CPU accounting with `CPUAccounting=yes` to track CPU consumption, and then set `CPUQuota` to specify a maximum percentage of CPU time the service can use. Without `CPUAccounting=yes`, the `CPUQuota` directive is ignored by systemd, making the combination essential for enforcing a hard CPU limit.

Answer

CPUShares

Answer

CPUQuota

Answer

CPULimit

Question 7

To ensure a service starts only after /var/lib/mysql is mounted, which directive should be used in the unit file?

Accepted Answer

After=var-lib.mount. The `After=` directive in a systemd unit file specifies that the current unit should start only after the listed units have been activated. By setting `After=var-lib.mount`, the service will wait until the mount unit for `/var/lib/mysql` is fully mounted before starting, ensuring the required filesystem is available.

Answer

Requires=/var/lib/mysql

Answer

BindsTo=var-lib.mount

Answer

Before=var-lib.mount

Question 8

A service that was once enabled is now failing to start. The administrator wants to immediately disable it to prevent boot delays. Which command sequence is correct?

Accepted Answer

systemctl disable --now service. `systemctl disable --now service` both stops the service immediately and disables it from starting at boot in a single atomic command. This is the most efficient way to prevent boot delays caused by a failing service, as it combines the stop and disable actions without relying on shell operators that could fail if the first command exits with a non-zero status.

Answer

systemctl disable service ; systemctl stop service

Answer

systemctl stop service && systemctl disable service

Answer

systemctl mask service

Question 9

Which TWO commands can be used to check the status of a service?

Accepted Answer

service status. Option B, `service status`, is correct because the `service` command is a wrapper that can query a service's status via its init script (e.g., `service ssh status`), reporting whether it is running or stopped. Option D, `systemctl status`, is correct because `systemctl status <unit>` queries systemd for the unit's state, showing active/inactive, loaded status, and recent log lines. Option A, `systemd-analyze`, is wrong because it analyzes boot performance and unit dependencies, not a service's runtime status. Option C, `start stop restart`, is wrong because these are service control actions, not a status-check command. Option E, `initctl status`, is wrong because `initctl` is the Upstart control utility and is not the standard tool for checking service status in systemd-based systems covered by this exam.

Answer

systemd-analyze

Answer

start stop restart

Answer

initctl status

Question 10

Based on the exhibit, what is the correct interpretation?

Accepted Answer

The service is running but the unit file has been modified recently and needs reloading. The 'daemon-reload' notice in the systemctl status output indicates that the unit file has been modified on disk but systemd has not yet reloaded its configuration. Running 'systemctl daemon-reload' will re-read the unit files and apply the changes, which is why option C is correct.

Answer

The service is inactive

Answer

The configuration file is corrupt

Answer

The service is failing

Question 11

Which of the following statements is true about this unit?

Accepted Answer

The service will be restarted indefinitely with a 10-second delay between restarts regardless of exit status. The `Restart=always` directive in a systemd service unit causes the service to be restarted indefinitely regardless of the exit status, and the `RestartSec=10` directive introduces a 10-second delay between each restart attempt. This behavior is defined in the systemd.service(5) man page, where `Restart=always` triggers a restart for any exit reason, including clean exits or signals.

Answer

The service can be started by a timer unit

Answer

The service will start automatically at boot only if network-online.target is reached

Answer

The service requires SELinux context

Question 12

What can be concluded from the log?

Accepted Answer

SSH server failed to start due to configuration error. The log shows that the SSH service failed to start because of a configuration error. Specifically, the log entry indicates a syntax error or invalid directive in the SSH daemon configuration file (typically /etc/ssh/sshd_config), which prevents the service from binding to the port and starting. This is a common issue when editing the configuration file manually, as the SSH daemon validates its configuration at startup and will refuse to run if any errors are found.

Answer

SSH server is masked

Answer

SSH server is running with errors

Answer

SSH server stopped normally

Question 13

A service requires read-write access to a specific directory that is mounted from an NFS share. The directory is mounted via fstab with the option 'noauto'. The service starts before the mount is available. Which configuration change should be made in the service unit file to ensure the service only starts after the mount is mounted?

Accepted Answer

Add After=mnt-nfs.mount and Requires=mnt-nfs.mount. The service requires the NFS mount to be available before it starts. The `After=mnt-nfs.mount` directive ensures the service unit is ordered after the mount unit, and `Requires=mnt-nfs.mount` makes the mount a hard dependency: if the mount fails or is not active, the service will not start. This combination is necessary because the mount is defined with `noauto` in fstab, meaning it is not automatically mounted at boot; the mount unit must be explicitly started (e.g., by a dependency or another unit) before the service.

Answer

Add Before=mnt-nfs.mount and Requires=mnt-nfs.mount

Answer

Add Wants=mnt-nfs.mount and After=mnt-nfs.mount

Answer

Add After=mnt-nfs.mount and BindsTo=mnt-nfs.mount

Question 14

A system administrator is debugging why a service named 'myapp.service' fails to start. He runs 'systemctl status myapp.service' and sees the status 'failed' with details 'Exit code: 1' and 'Failed with result exit-code'. Which command should be used next to view the full log of the service?

Accepted Answer

journalctl -u myapp.service. The correct command is `journalctl -u myapp.service` because it retrieves the full systemd journal logs for the specified unit, showing detailed error messages, stdout/stderr output, and timestamps that explain why the service exited with code 1. The `-u` flag filters the journal to entries related to that specific service unit, which is essential for debugging exit-code failures.

Answer

systemctl show myapp.service

Answer

journalctl -x -u myapp.service

Answer

systemctl list-dependencies myapp.service

Question 15

A service unit file includes the following: [Install] WantedBy=multi-user.target. What does this directive accomplish?

Accepted Answer

The service is enabled by symlinking in multi-user.target.wants.. The `WantedBy=multi-user.target` directive in the `[Install]` section of a systemd service unit file does not directly start the service when the target is entered. Instead, when the service is enabled (via `systemctl enable`), systemd creates a symbolic link from the service unit file into the `multi-user.target.wants/` directory. This symlink causes systemd to automatically start the service as a dependency when `multi-user.target` is activated, effectively enabling the service for that target.

Answer

The service is stopped when multi-user.target is stopped.

Answer

The service conflicts with multi-user.target.

Answer

The service is automatically started when the system enters multi-user.target.

Question 16

Which two commands produce output that includes the current runlevel or target? (Choose two.)

Accepted Answer

runlevel. Option C (runlevel) is correct because it prints the previous and current runlevel (e.g., 'N 5' or '5 3'), directly reporting the current runlevel. Option D (who -r) is correct because it displays the current runlevel along with the time of last runlevel change, e.g., 'run-level 5  2024-01-01 10:00'. Option A (systemctl list-units --type=target) lists loaded target units but does not indicate which one is currently active as the runlevel/target. Option B (systemctl show-environment) prints environment variables for the systemd manager, not the runlevel or target. Option E (systemctl get-default) shows the default target configured to boot into, not the current runlevel or active target.

Answer

systemctl list-units --type=target

Answer

systemctl show-environment

Answer

systemctl get-default

Question 17

Which two statements are true about systemd socket activation? (Choose two.)

Accepted Answer

The service unit must include 'Sockets=<socket unit>' to bind the service to the socket.. Option C is correct because a service unit that is triggered by a socket unit must reference that socket via the Sockets= directive in its [Unit] section (e.g., Sockets=sshd.socket), which binds the service to the socket and establishes the dependency. Option D is correct because the core purpose of systemd socket activation is on-demand startup: systemd listens on the socket and starts the associated service only when a connection or datagram arrives, then passes the listening file descriptor to the service. Option A is not required, since the [Install] section only controls enablement (e.g., WantedBy=) and is not mandatory for socket activation to function. Option B is incorrect because the service unit uses Type=simple, forking, or notify as appropriate; 'socket' is a unit type for the .socket file, not a valid service Type. Option E is incorrect because socket activation works with AF_UNIX, AF_INET, and AF_INET6 sockets, including both TCP and UDP, not only TCP.

Answer

The socket unit file must have an [Install] section.

Answer

Socket activation requires the service to be of type 'socket'.

Answer

Socket activation only works with TCP sockets.

Question 18

Which three of the following are valid reasons to use 'systemctl mask' instead of 'systemctl disable'? (Choose three.)

Accepted Answer

To ensure that even 'systemctl start' fails.. Option C is correct because masking a unit links it to /dev/null, so any attempt to start it—including an explicit 'systemctl start'—fails with an error rather than launching the service. Option D is correct because a masked unit cannot be pulled in as a dependency by another unit, so it cannot be enabled or started indirectly through Requires/Wants relationships. Option E is correct because masking blocks manual activation as well, not just boot-time activation, which is the key difference from 'disable'. Options A and B are not correct: masking does not hide a unit from status commands (it still appears, typically shown as masked), and it does not make the service 'completely unavailable' in the sense of removing it—the unit file still exists and can be unmasked, so the blanket wording is inaccurate.

Answer

To hide the service from status commands.

Answer

To make the service completely unavailable to the system.

Question 19

Refer to the exhibit. What is the most likely cause of the sshd service failure?

Accepted Answer

The sshd_config file is misconfigured.. The exhibit shows that the sshd service fails to start, and the most likely cause is a misconfiguration in the sshd_config file. When sshd is started via systemd, a syntax error or invalid directive in /etc/ssh/sshd_config will cause the daemon to exit immediately, resulting in a failed status. This is a common issue because sshd validates its configuration file at startup and will refuse to run if it finds an error.

Answer

The OPTIONS environment variable is not set.

Answer

The service is not enabled to start at boot.

Answer

There is a syntax error in the unit file.

Question 20

A company runs a monitoring agent service (monitor.service) that must start after the network is fully up and the DNS resolver is ready. The service currently has the following dependencies in its unit file:

[Unit]
Description=Monitoring Agent
After=network.target
Wants=network.target

[Service]
ExecStart=/usr/bin/monitor

The service starts, but often fails to resolve hostnames because DNS is not yet available. Which change should be made to the unit file to ensure the service only starts after DNS is ready?

Accepted Answer

Add a dependency: After=nss-lookup.target. `nss-lookup.target` is a synchronization point that indicates the hostname resolution subsystem (including DNS) is fully operational. By adding `After=nss-lookup.target`, the monitor service will not start until DNS resolution is available, solving the hostname resolution failures. The existing `Wants=network.target` is insufficient because `network.target` only signals that basic network interfaces are configured, not that DNS services are ready.

Answer

Replace After=network.target with After=network-online.target and add Requires=network-online.target

Answer

Add Before=network.target to delay the start

Answer

Set Type=idle in the [Service] section