Troubleshooting
Checking Logs
How you access logs depends on how you run pyprland.
Systemd Service
If you run pyprland as a systemd user service:
journalctl --user -u pyprland -fexec-once (Hyprland)
If you run pyprland via exec-once, logs go to stderr by default and are typically lost.
To enable debug logging, add --debug to your exec-once command. Optionally specify a file path to also save logs to a file:
exec-once = /usr/bin/pypr --debug $HOME/pypr.logThen check the log file:
tail -f ~/pypr.logTIP
Use a path like $HOME/pypr.log or /tmp/pypr.log to avoid cluttering your home directory.
Running from Terminal
For quick debugging, run pypr directly in a terminal:
pypr --debugThis shows debug output directly in the terminal. Optionally add a file path to also save logs to a file.
General Issues
In case of trouble running a pypr command:
- Kill the existing pypr daemon if running (try
pypr exitfirst) - Run from a terminal with
--debugto see error messages
If the client says it can't connect, the daemon likely didn't start. Check if it's running:
ps aux | grep pyprYou can try starting it manually from a terminal:
pypr --debugThis will show any startup errors directly in the terminal.
Force Hyprland Version
In case your hyprctl version -j command isn't returning an accurate version, you can make Pyprland ignore it and use a provided value instead:
[pyprland]
hyprland_version = "0.41.0"Unresponsive Scratchpads
Scratchpads aren't responding for a few seconds after trying to show one (which didn't show!)
This may happen if an application is very slow to start. In that case pypr will wait for a window, blocking other scratchpad operations, before giving up after a few seconds.
Note that other plugins shouldn't be blocked by this.
More scratchpads troubleshooting can be found here.
See Also
- Getting Started: Running the Daemon - Setup options
- Commands: Debugging - Debug flag reference