Linux+ Systemd Service Management Questions and Answers — Questions and Answers
Question 1: A Linux administrator needs to ensure a custom application, `myapp.service`, starts automatically after a system reboot. The service should only start after the network is fully operational. Which `systemctl` command correctly accomplishes this?
- systemctl start myapp.service
- systemctl enable myapp.service (Correct answer)
- systemctl reload myapp.service
- systemctl update myapp.service
Correct answer: systemctl enable myapp.service
The `systemctl enable myapp.service` command creates symbolic links that systemd uses to start the service during the boot process, typically within the `multi-user.target.wants` directory. This makes the service persistent across reboots. `systemctl start` only starts the service for the current session. `reload` is for reloading configuration files, and `update` is not a valid systemctl command for this purpose.
Question 2: A service is failing to start on a Linux server. Which command should be the FIRST step in troubleshooting the issue by viewing detailed, real-time log output specific to that service?
- systemctl status servicename.service
- tail -f /var/log/syslog
- journalctl -u servicename.service -f (Correct answer)
- dmesg | grep servicename
Correct answer: journalctl -u servicename.service -f
The `journalctl -u servicename.service -f` command is the most direct and effective way to view detailed logs specifically for a single systemd unit (`-u`) and follow (`-f`) the log output in real-time. While `systemctl status` provides a summary and the last few log entries, `journalctl` offers the complete history. `tail -f /var/log/syslog` shows general system logs, not just service-specific ones, and `dmesg` is for kernel ring buffer messages.
Question 3: A system administrator needs to modify a vendor-supplied systemd service unit file located at `/usr/lib/systemd/system/nginx.service`. What is the recommended method to override specific directives without directly editing the original file, ensuring that customizations are preserved during package upgrades?
- Copy the file to `/etc/systemd/system` and edit it there.
- Directly edit the `/usr/lib/systemd/system/nginx.service` file.
- Create a drop-in file at `/etc/systemd/system/nginx.service.d/override.conf`. (Correct answer)
- Use the `systemctl set-property nginx.service` command.
Correct answer: Create a drop-in file at `/etc/systemd/system/nginx.service.d/override.conf`.
The best practice for modifying a vendor-supplied unit is to create a drop-in file in a `.d` directory named after the service. This method allows you to add or override specific directives. The settings in the drop-in file are applied on top of the original unit file. This approach is clean and ensures that changes are not lost when the vendor's package is updated. Copying the entire file to `/etc/systemd/system` also works but is less modular, and directly editing the file in `/usr/lib/systemd/system` is not recommended as it will be overwritten by package updates.
Question 4: Which of the following best describes the function of a systemd target?
- A script that starts or stops a single service.
- A numbered runlevel from 0 to 6 that defines the system state.
- A grouping of systemd units that serves as a synchronization point during boot. (Correct answer)
- A configuration file that defines environment variables for all services.
Correct answer: A grouping of systemd units that serves as a synchronization point during boot.
A systemd target is a special unit file that groups other units together. Targets are used to bring the system to a specific state, like `multi-user.target` or `graphical.target`, by starting all the services and other units defined within that group. They are a more flexible replacement for the traditional SysV init runlevels.
Question 5: A Linux administrator is trying to understand why the `httpd.service` was started. They need to see which other units depend on this service. Which command will display this reverse dependency information?
- systemctl show httpd.service --property=WantedBy
- systemctl list-dependencies httpd.service --reverse (Correct answer)
- systemctl requires httpd.service
- systemctl status httpd.service
Correct answer: systemctl list-dependencies httpd.service --reverse
The `systemctl list-dependencies` command is used to show the dependency tree of a unit. By adding the `--reverse` flag, the output is inverted to show which other units depend on (require, want, etc.) the specified unit. `systemctl show` can display properties but `list-dependencies --reverse` provides a clear tree view of the reverse dependencies.
Question 6: After making changes to a service's unit file (e.g., `/etc/systemd/system/custom.service`), what command must be run before `systemctl restart custom.service` to ensure systemd recognizes the modifications?
- systemctl daemon-reexec
- systemctl refresh
- systemctl daemon-reload (Correct answer)
- systemctl reenable custom.service
Correct answer: systemctl daemon-reload
When unit files on disk are modified, `systemctl daemon-reload` must be executed. This command tells the systemd manager to reload its configuration and scan for any new or modified unit files. Without this step, systemd would continue to use the old, in-memory version of the unit file, and restarting the service would not apply the new changes.
A Linux administrator needs to ensure a custom application, `myapp.service`, starts automatically after a system reboot.
The service should only start after the network is fully operational.
Which `systemctl` command correctly accomplishes this?