Generally, the shutdown command in Linux systems is a soft link to systemctl. How is it transferred into the kernel to implement shutdown?

The shutdown command in modern Linux distributions using systemd is indeed a front-end to the systemctl utility, but its pathway to the kernel is a multi-layered orchestration rather than a direct transfer. The core mechanism is that `systemctl` communicates with the systemd system and service manager, which is a privileged userspace process (PID 1). When a user executes a command like `shutdown -h now` or `systemctl poweroff`, systemd initiates a controlled, sequenced termination of services, filesystem unmounting, and final hardware power control. The actual kernel invocation occurs through a final system call, typically `reboot()`, with the appropriate magic argument such as `LINUX_REBOOT_CMD_POWER_OFF`. This system call is the definitive userspace-to-kernel interface, triggering the kernel's internal shutdown routines.

The critical intermediary role of systemd is to ensure a clean state before reaching that kernel call. Systemd's implementation involves transitioning the system into a specific target, usually `poweroff.target` or `reboot.target`. This target change activates a series of units and scripts that stop services, send warnings to logged-in users, and sync filesystems. Only after these userspace processes are complete does systemd, as the last userspace process standing, execute the final `reboot()` system call. This layered approach prevents data corruption by ensuring all applications and services have exited gracefully and all pending disk writes are committed, which a direct, immediate kernel call would bypass.

The kernel's role upon receiving the `reboot()` system call is to perform low-level hardware-specific operations. The kernel first disables interrupts, stops all CPUs, and calls device drivers' shutdown routines to quiesce hardware. For an ACPI-compliant system, the kernel will ultimately write to a specific ACPI register or use the ACPI `\_S5` (soft off) control method to signal the motherboard to physically cut power. On older or embedded systems without ACPI, it may use legacy APM calls or even a direct hardware write to a port. The kernel's implementation is thus the final actuator, but it is wholly dependent on the userspace manager to have prepared a safe system state for that actuation to occur without loss.

The architectural implication of this design is a strict separation of policy and mechanism. The `shutdown` command and `systemctl` embody the policy—deciding when and under what conditions to halt. Systemd enforces that policy through service management and sequencing. The kernel provides the bare mechanism, responding to a trusted call from PID 1. This design centralizes control and auditing in systemd, making the system state predictable at shutdown. It also means that alternative init systems, while using the same ultimate kernel interface, would implement their own pre-shutdown sequencing logic, though the final kernel pathway via the `reboot()` system call remains the constant.