When dealing with NFS mounts that become unresponsive, standard reboot commands often fail to resolve the issue. The key observation is:

# This hangs indefinitely during NFS issues
sudo shutdown -r now

# This forces an immediate reboot
sudo reboot -f

The fundamental difference lies in how these commands interact with the kernel and system services:

• shutdown performs a graceful reboot sequence:

  1. Sends SIGTERM to all processes
  2. Waits for clean termination
  3. Unmounts filesystems
  4. Syncs disks
  5. Executes reboot

• reboot -f triggers a direct kernel reboot:

  1. Skips process termination
  2. Bypasses filesystem unmounting
  3. Immediately calls kernel reboot syscall

On systemd-based Debian systems, the behavior becomes more nuanced:

# View the actual commands being called
systemctl status reboot.target
systemctl status shutdown.target

# Forcing through systemd (alternative approach)
sudo systemctl reboot --force --force

Here's a script I use to handle stubborn NFS situations:

#!/bin/bash
# Attempt graceful unmount first
umount -fl /mnt/nfs

# Check if NFS processes are stuck
if pgrep -f "nfs"; then
    echo "Forcing reboot due to NFS hang"
    reboot -f
else
    shutdown -r now
fi

For critical systems where hangs must be prevented:

# Add to /etc/sysctl.conf
kernel.panic = 60
kernel.hung_task_timeout_secs = 30
kernel.sysrq = 1

# Then apply
sysctl -p

Use shutdown -r when:

• Services need clean termination
• Filesystem consistency is critical
• You have time for proper shutdown sequence

Use reboot -f when:

• System is unresponsive to normal commands
• NFS or other network filesystems are hung
• You need immediate hardware reset

---

When dealing with stubborn NFS mount issues where umount -f fails, many admins instinctively reach for shutdown -r now. However, in cases where the filesystem is completely locked up, this command may hang indefinitely while reboot -f succeeds. The key difference lies in how these commands interact with system services and processes.

shutdown -r now performs a graceful reboot sequence:

1. Notifies all processes via SIGTERM
2. Waits for clean process termination
3. Attempts proper filesystem unmounting
4. Syncs disks before rebooting

In contrast, reboot -f (the -f flag is crucial) forces an immediate reboot:

1. Skips service shutdown notifications
2. Bypasses filesystem unmount attempts
3. Forces kernel reboot without sync

When NFS clients hang, they often maintain kernel-level locks that prevent normal shutdown procedures. Here's what happens with each command:

shutdown -r now gets stuck because:

- Waits indefinitely for NFS operations to complete
- Can't terminate processes holding NFS references
- Hangs during unmount attempts

reboot -f succeeds because:

- Ignores hung NFS operations
- Kills processes without cleanup
- Forces reboot regardless of filesystem state

While reboot -f works, consider these less disruptive options first:

# Attempt lazy unmount
umount -l /mnt/nfs

# Kill processes using the mount
fuser -km /mnt/nfs

# Force TCP disconnect (for NFSv3)
rpcinfo -T tcp server.nfs.ip

Use shutdown -r now when:

- Performing scheduled maintenance
- Need clean service termination
- Filesystems are healthy

Use reboot -f when:

- Facing unrecoverable hangs
- NFS/Kernel is completely locked
- Need immediate recovery

On modern Debian systems using systemd, the behavior stems from different unit files:

# shutdown triggers these targets
DefaultDependencies=yes
Conflicts=shutdown.target
Before=shutdown.target

# reboot -f bypasses these
DefaultDependencies=no
KillMode=process

The -f flag essentially tells systemd to skip its normal shutdown sequencing and force immediate action.

To prevent needing forced reboots, consider these NFS client tweaks:

# /etc/nfs.conf
[nfsmount]
defaults=soft,timeo=10,retrans=3

# Kernel parameters
echo 10 > /proc/sys/kernel/hung_task_timeout_secs
echo 1 > /proc/sys/fs/nfs/nfs_congestion_kb