DEV Community

Cover image for How to Force Quit Unresponsive Applications via CLI on macOS
Geoffrey Kim
Geoffrey Kim

Posted on • Edited on

How to Force Quit Unresponsive Applications via CLI on macOS

#macos #terminal #bash #devops

If you're working on a macOS system and encounter an application that's not responding, you know how frustrating it can be. While the graphical interface offers ways to force quit applications, sometimes you may need or prefer to do this from the command line interface (CLI). Whether you're remote accessing a system, prefer using the terminal, or are in a situation where the GUI is not accessible, knowing how to handle this via CLI can be incredibly useful. Here's a comprehensive guide on how to force quit unresponsive applications using the command line on macOS.

Understanding Process Names vs. Application Names

Before we dive in, it's important to understand that macOS application names often don't match their process names:

  • An application like "Safari.app" might run as a process named "Safari" or "SafariMain"
  • "Microsoft Word.app" might appear as "Microsoft Word" or simply "Word" in process listings
  • Some applications spawn multiple processes with different names

This distinction is crucial when trying to identify and terminate processes via the command line.

1. Finding the Process ID (PID)

The first step in forcing an application to quit is identifying the process ID (PID) of the application. The PID is a unique number that macOS uses to refer to each running process. Here are several ways to find the PID:

Using ps aux:

  • Open the Terminal application.
  • Type ps aux | grep "[application name]" and press Enter. For example: ps aux | grep "Safari"
  • This will display all processes containing that name, along with their PIDs in the second column.

Using pgrep:

  • For a quicker way to find PIDs, use: pgrep -i "[application name]"
  • The -i flag makes the search case-insensitive, which is often helpful.
  • Example: pgrep -i "safari" will return PIDs for Safari processes.

Using top or htop:

  • Run top in Terminal for an interactive, real-time view of all running processes.
  • For a more user-friendly interface, install and use htop with brew install htop (requires Homebrew).
  • These tools allow you to sort by CPU or memory usage, making it easier to identify problematic applications.

2. Understanding Terminal Signals

When terminating a process, you're actually sending it a signal. Different signals have different effects:

  • SIGTERM (15): The default signal sent by the kill command. It asks the process to terminate gracefully, allowing it to save data and clean up resources.
  • SIGKILL (9): A forceful termination that the process cannot ignore or handle. This signal immediately terminates the process without any cleanup, which may lead to data loss.
  • SIGHUP (1): Originally meant to signal that a terminal has been "hung up" (disconnected), many daemons interpret this as a request to reload their configuration.

3. Force Quitting with the kill Command

Once you have the PID, you can proceed to force quit the application:

  • For a graceful termination: kill [PID] (Example: kill 12345)
  • For an immediate, forceful termination: kill -9 [PID] (Example: kill -9 12345)
  • To send a specific signal: kill -[signal number] [PID] (Example: kill -15 12345)

Administrative Privileges

Some processes, particularly system processes, may require administrative privileges to terminate:

  • If a regular kill command fails with "Operation not permitted", try using sudo:
  • sudo kill -9 [PID]
  • You'll be prompted for your administrator password.

4. Using Name-Based Commands

If you prefer not to look up PIDs first, these commands can terminate processes directly by name:

Using killall:

  • The most straightforward method for macOS: killall "[Application Name]"
  • Example: killall "Safari"
  • For forceful termination: killall -9 "Safari"

Using pkill:

  • Similar to killall but with more options: pkill -i "[application name]"
  • The -i flag makes the search case-insensitive
  • For interactive confirmation before killing: pkill -i
  • Example: pkill -i "safari"

5. Handling Complex Applications

Modern macOS applications often consist of multiple processes working together:

Application Bundles:

  • An application like Chrome may have a main process and several renderer processes
  • Killing just the main process usually terminates all related processes

Finding Child Processes:

  • To see the process hierarchy: pstree [PID] (may need to be installed via Homebrew)
  • Or use: ps -f --forest -g $(ps -o pgid= [PID])

Terminating Process Groups:

  • To kill a process and all its children: kill -9 -[PGID] (Process Group ID)
  • Find PGID using: ps -o pgid= [PID]

Caution and Best Practices

While force quitting applications can be necessary, it should be done with caution:

  • Always try normal termination methods first before resorting to kill -9
  • Unsaved data will be lost when using forceful termination
  • Killing system processes may cause system instability
  • If possible, identify why applications are becoming unresponsive to address root causes
  • Consider using Activity Monitor's GUI as an alternative when available

6. Automated Detection and Management of Unresponsive Applications

While manually terminating unresponsive applications is useful, you may want to programmatically detect when applications are stuck and automatically restart them. This is especially valuable for remote administration, automated monitoring, or managing critical applications that need to maintain high availability.

Detecting Unresponsive Applications

macOS doesn't provide a direct CLI equivalent to the "Application Not Responding" (ANR) status shown in Activity Monitor (red highlight). However, we can use several approaches to detect unresponsive applications:

Using AppleScript to Test Responsiveness:

AppleScript can be used to send commands to applications. If an app is unresponsive, the command will time out:

# Note: timeout command may need to be installed via Homebrew
timeout 5 osascript -e 'tell application "Safari" to if it is running then return'
Enter fullscreen mode Exit fullscreen mode

If this command times out (exit code 124), the application is likely unresponsive.

Using spindump to Analyze Process State:

The spindump utility can provide detailed information about process state:

spindump -reveal -o /tmp/app_status.txt [PID] 10
Enter fullscreen mode Exit fullscreen mode

You can then analyze the output file for indicators like "Not Responding":

grep "Not Responding" /tmp/app_status.txt
Enter fullscreen mode Exit fullscreen mode

Monitoring CPU Usage Patterns:

Consistently high CPU usage or completely stalled CPU usage can indicate a stuck application:

ps -p [PID] -o %cpu
Enter fullscreen mode Exit fullscreen mode

Applications that are stuck often show either 0% CPU (completely frozen) or very high CPU (spinning).

Creating an Automated Monitoring Script

Here's a sample script that monitors an application, detects if it's unresponsive, and restarts it if necessary:

#!/bin/bash
# Application monitoring and automatic restart script

APP_NAME="Safari"  # Change to your application name
MAX_RESPONSE_TIME=5  # Maximum time in seconds to wait for response
LOG_FILE="/var/log/app_monitor.log"

# Function to log messages
log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> "$LOG_FILE"
    echo "$1"
}

# Get the PID of the application
PID=$(pgrep -x "$APP_NAME")

# Check if application is running
if [ -z "$PID" ]; then
    log_message "$APP_NAME is not running. Starting..."
    open -a "$APP_NAME"
    exit 0
fi

# Test application responsiveness using AppleScript with timeout
if ! timeout $MAX_RESPONSE_TIME osascript -e "tell application \"$APP_NAME\" to if it is running then return" &>/dev/null; then
    log_message "$APP_NAME (PID: $PID) is not responding. Restarting..."
    kill -9 $PID
    sleep 2
    open -a "$APP_NAME"
    log_message "$APP_NAME restarted."
else
    log_message "$APP_NAME is responsive."
fi
Enter fullscreen mode Exit fullscreen mode

Setting Up Automated Monitoring

To run this script regularly, you can set up a cron job:

  1. Save the script as app_monitor.sh and make it executable: chmod +x app_monitor.sh
  2. Edit your crontab: crontab -e
  3. Add a line to run the script every 5 minutes: 
   */5 * * * * /path/to/app_monitor.sh >> /path/to/cronlog.txt 2>&1
Enter fullscreen mode Exit fullscreen mode

Note: Ensure the script path is absolute and the user has appropriate permissions.

Advanced Implementation Considerations

For more robust monitoring:

  1. Add notification capabilities using osascript -e 'display notification' or tools like Slack webhooks
  2. Implement escalation logic to try graceful termination before force quitting
  3. Add counters to track how many times an application has been restarted to detect recurring issues
  4. Monitor memory usage in addition to responsiveness as memory leaks often precede application freezes
  5. Add logging rotation to prevent log files from growing too large

Testing Your Monitoring Solution

Before relying on your solution:

  1. Simulate unresponsive applications using the yes command or CPU-intensive tasks
  2. Test the script manually first before automating
  3. Verify logging and notification mechanisms work correctly
  4. Ensure the solution works when you're not logged in

Conclusion

Understanding how to manage unresponsive applications through the CLI can be a powerful addition to your troubleshooting toolkit on macOS. These commands offer system administrators, developers, and power users effective ways to regain control over their systems when applications freeze or become unresponsive. With the addition of automated monitoring and management, you can ensure critical applications maintain high availability with minimal manual intervention.

Remember, with great power comes great responsibility. Use these commands wisely and always ensure you have saved your work before force quitting any application.

Top comments (3)

Collapse
 
gentrificationzolaz profile image
gentrificationzolaz • • Edited

Great article! Thanks for sharing! I also had this problem on my mac. However, before this article came out, I also looked at this resource setapp.com/how-to/force-quit-on-mac which also describes in detail how to force quit on mac. After that, I looked at other articles on other topics and found a lot of interesting and useful information. So I think you should also check out setapp to find solutions to your other questions.

Collapse
 
mathieuidix profile image
Mathieu Massebœuf •

Pretty clear article, thanks !
I'm actually looking for a way to find out programaticaly (from the shell / remotely) if an app is stuck or not - ie if an app is in red in Activity Monitor.
For now I tried many way without success - may you have a clue about how to achieve this ?
The goal is to find out if an app is stuck - and restart it if needed.

Collapse
 
mochafreddo profile image
Geoffrey Kim •

Thanks for your question! I've updated the blog with a new section covering how to programmatically detect and restart unresponsive apps.

The simplest method is using AppleScript with timeout:

timeout 5 osascript -e 'tell application "AppName" to if it is running then return'
Enter fullscreen mode Exit fullscreen mode

The updated post includes a complete monitoring script and automation instructions. Check it out and let me know if it helps with your use case!