MACOS
Restarting GlobalProtect on macOS without a reboot
When the VPN agent wedges and breaks DNS or routing, launchctl restarts it in seconds. The bootout and bootstrap commands, and why it sometimes comes straight back.
GlobalProtect occasionally gets into a state where the tray icon claims it is connected but nothing routes. Usually it is DNS: the agent has installed resolvers that no longer answer, so kubectl hangs, internal registries stop resolving, and a docker pull sits there until it times out. Rebooting fixes it and costs you every terminal, editor and port-forward you had open.
You do not need to reboot. The agent is two launchd jobs, and restarting them takes a few seconds.
The two processes
GlobalProtect on macOS splits into a service and a user-facing agent, and they are managed separately.
- PanGPS is the service that does the actual VPN work: tunnel, routes and DNS.
- PanGPA is the agent you interact with, the menu bar item and the connection window.
Restarting PanGPS alone fixes most routing and DNS problems. Restart PanGPA as well when the UI itself is unresponsive or shows a state that disagrees with reality.
Find the plists first
bootout and bootstrap take an explicit domain, so you need to know whether each job is a per-user agent or a system daemon before you can target it. Packaging has varied across GlobalProtect versions, so check rather than assume:
ls /Library/LaunchAgents/com.paloaltonetworks.* \
/Library/LaunchDaemons/com.paloaltonetworks.* 2>/dev/nullAnything under LaunchAgents belongs to the per-user domain, written gui/<uid>. Anything under LaunchDaemons is system scope and needs sudo.
Stop them
launchctl bootout gui/$(id -u) /Library/LaunchAgents/com.paloaltonetworks.gp.pangps.plist
launchctl bootout gui/$(id -u) /Library/LaunchAgents/com.paloaltonetworks.gp.pangpa.plistIf the plists live in /Library/LaunchDaemons instead, the domain is system:
sudo launchctl bootout system /Library/LaunchDaemons/com.paloaltonetworks.gp.pangps.plistStart them again
Order matters here. Bring the service up before the agent, so the agent finds something to attach to rather than reporting a failure.
launchctl bootstrap gui/$(id -u) /Library/LaunchAgents/com.paloaltonetworks.gp.pangps.plist
launchctl bootstrap gui/$(id -u) /Library/LaunchAgents/com.paloaltonetworks.gp.pangpa.plistVerify
launchctl list | grep -i paloBoth jobs should be listed with a numeric PID in the first column. A - instead of a PID means the job is loaded but not running, and a non-zero value in the second column is the exit status of the last run, which is the first thing worth reading when a restart does not take.
For more than a PID, print dumps the full job state, including the last exit reason and whether launchd intends to keep it alive:
launchctl print gui/$(id -u)/com.paloaltonetworks.gp.pangpsSummary
Two launchd jobs, bootout then bootstrap, service before agent. It replaces a reboot with about ten seconds and keeps your session intact. When it does not stick, read the exit status from launchctl list before assuming the command failed.
Source: How to manually stop and start PanGPS or GlobalProtect on macOS in the Palo Alto Networks knowledge base, which documents the older load and unload form of the same operations.