A medium-sized company runs a web application on a Linux server. The server uses systemd and has the following configuration: the web application service (webapp.service) is configured to start after network.target and requires a database service (database.service) to be running. The database service has a Restart=on-failure directive. Recently, the server experienced a power outage. Upon reboot, the system administrator notices that the web application fails to start because the database service is in a failed state. The administrator checks the status of database.service and sees 'inactive (dead)' with no recent attempts to restart. The journal shows that the database service failed to start because a required filesystem (mounted at /var/lib/database) was not mounted when the database service tried to start. The filesystem is listed in /etc/fstab with the nofail option. The administrator wants to ensure that in future reboots, the database service starts successfully and the web application comes up without manual intervention. Which of the following is the best course of action?
This ensures the database service waits for the mount unit to be active before starting.
Why this answer
Option C is correct because the database service failed due to a missing mount at /var/lib/database. By adding 'After=var-lib-database.mount' and 'Requires=var-lib-database.mount' to the database.service unit, systemd will ensure the mount unit is started before the database service and that the database service is stopped if the mount fails. This directly addresses the root cause—the filesystem not being ready—without altering the restart behavior or the fstab nofail option, which is appropriate for allowing the system to boot even if the mount fails.
Exam trap
The trap here is that candidates often focus on restart policies (Option A) or fstab options (Option B) without realizing that systemd's dependency system must be used to enforce ordering between services and mount units, especially when nofail is present.
How to eliminate wrong answers
Option A is wrong because changing Restart to 'always' would cause the database service to restart indefinitely even after successful runs, but it does not solve the underlying issue of the mount not being ready; the service would still fail on the first attempt if the mount is missing, and Restart=on-failure already handles restarts after failure, but the service never got a chance to restart because it was never started again after the initial failure. Option B is wrong because removing the nofail option from /etc/fstab would cause the system to fail to boot entirely if the filesystem cannot be mounted, which is worse than the current behavior; the nofail option is correctly used to allow boot to proceed, but the dependency must be expressed in systemd units. Option D is wrong because webapp.service already has 'After=database.service' and 'Requires=database.service' (implied by the requirement that the database service must be running), so adding them again does nothing; the problem is that database.service itself fails due to the mount, not that webapp.service lacks ordering or dependency on database.service.