Mr Frosty Pants

A Proper Guide to Mr Frosty Pants for System Monitoring

Mr Frosty Pants is a terminal-based system monitoring and automation daemon that sits between something like htop and a full cron setup. It gives you live resource graphs with alerting built in, plus an event-driven task system so you don't need to cobble together three separate tools to get basic server oversight. I started running it about two years ago on a handful of small VPS instances and a few desktop workstations, mostly because I was tired of maintaining separate monitoring stacks that required too much manual intervention. The core piece is a lightweight daemon called fspd that runs in the background. It collects CPU, memory, disk I/O, network throughput, and a few other metrics at configurable intervals and stores them in a local SQLite database. The CLI tool, simply called mfp, reads from that database and renders a TUI. Beyond live monitoring, you can define alerts based on thresholds and register event handlers that run shell commands or Python scripts when conditions are met. That means a disk usage alert doesn't just beep at you — it can archive old logs, rotate files, or notify you through a webhook without any manual setup. The project is open source and the primary install paths are through pip for Python 3.10 and above, or compiling from source on Debian-based systems. It currently has no official Windows support. The Linux compatibility is solid on anything running a recent kernel, though I've had quirks on older Raspberry Pi OS builds where the libnl dependency version conflicted with the system's bundled copy. That one took me about an hour to resolve by pinning the package version in my requirements file.

Installation Walkthrough

If you're on a Debian or Ubuntu system, start by installing the base dependencies: sudo apt-get install libnl-3-dev libnl-genl-3-dev python3-dev sqlite3 build-essential Then grab the package via pip with pip3 install --user mr-frosty-pants. The --user flag keeps it isolated from your system Python install, which matters if you rely on system packages for anything else. If you need the latest development version rather than the stable release, clone the repository and run python3 -m pip install -e . from the project root. The editable install lets you patch the code directly without reinstalling.

After installation, initialize the daemon config: mfp init --config-dir ~/.config/mfp This creates the default configuration file and the SQLite database in your home directory. You'll want to edit the config before starting the daemon for the first time. The default sample config works fine for a quick test run, but the collection interval defaults to every 30 seconds and the retention period defaults to 7 days. Those numbers are reasonable for personal use but too aggressive if you're running this on a production server where you need to investigate incidents that happened weeks ago.

Basic Configuration

The config file is structured YAML. Here's what a minimal production-ready section looks like for a small VPS: daemon:
collection_interval: 15
retention_days: 30
log_level: info

alerts:
- metric: cpu_percent
threshold: 85
duration_seconds: 60
handler: script:///usr/local/bin/mfp/cpu_alert.sh

- metric: disk_free_pct
path: /var/log
threshold: 10
duration_seconds: 300
handler: script:///usr/local/bin/mfp/log_rotate.sh The duration_seconds field is important and often overlooked. Without it, a brief CPU spike would trigger the alert immediately. Setting duration_seconds means the condition has to persist for that long before the handler fires. I've found 60 seconds for CPU and 300 seconds for disk alerts to be a good balance between catching real problems and avoiding noise from transient spikes.

The handler field supports several formats. script:// runs a local executable, http:// sends a POST request to a webhook endpoint, and mail:// triggers a simple SMTP notification. For most people, combining script:// handlers with a centralized notification service like PagerDuty or a Slack webhook gives you the most flexibility.

Running the TUI

Start the daemon with mfp daemon start, then open the interface with mfp tui. The layout shows CPU and memory graphs at the top, disk and network below that, and a process table at the bottom. You navigate with arrow keys, press Enter on any process to see its thread-level breakdown, and press q to quit. It's not the most polished TUI I've used — the refresh rate can feel sluggish when you have more than five monitored metrics and retention is set above 14 days, since the database queries get heavier. But it's functional and gets the job done. For remote access, Mr Frosty Pants includes a lightweight web interface you can enable by adding a section to the config. It's not as feature-rich as the TUI but it works fine for quick checks from a browser. I run this on a couple of machines I SSH into infrequently, and the web UI saves me from having to install the full package on my laptop just to check one metric.

Event Handlers and Automation

This is where the tool becomes genuinely useful rather than just another monitoring dashboard. I wrote a handler script for one of my development servers that watches inode usage on the /tmp partition. When inodes drop below 15 percent, the script finds files older than 48 hours owned by the current user and removes them. It runs as a cron job independently, but Mr Frosty Pants also monitors the result and logs an alert if the cleanup fails. That redundancy has saved me once when a stuck process was holding open a large number of temporary files and the cleanup script silently skipped them due to a permission error. Here's what that handler script looks like roughly: #!/usr/bin/env python3
import os
import shutil
import time

threshold = 0.15
current_usage = shutil.disk_usage('/tmp').free / shutil.disk_usage('/tmp').total
if current_usage < threshold:
cutoff = time.time() - (48 * 3600)
for entry in os.scandir('/tmp'):
if entry.is_file() and entry.stat().st_mtime < cutoff:
try:
os.unlink(entry.path)
except PermissionError:
print(f'Skipped {entry.path}: permission denied', flush=True)

Make it executable and point your alert handler at it. The script should log its own output so you can verify it ran correctly by checking the journal or the mfp log directory.

Common Pitfalls and Edge Cases

There are a few things that will trip you up if you're not expecting them. First, the SQLite database grows linearly with your retention period and collection frequency. A 30-day retention at 15-second intervals on a four-metric setup will produce a database around 400 megabytes. At 5-second intervals it jumps to roughly 1.2 gigabytes. That's not huge, but if you're running this on a system with limited disk space it matters. I learned that the hard way on a 20-gigabyte container where I had retention set to 90 days by mistake. The disk filled up and the daemon started failing to write new records silently. The fix was setting up a retention policy in the config that automatically purges records older than the threshold, which I should have done from the start. Second, the network monitoring module relies on libnl and can conflict with systems that use custom routing tables or VPN interfaces. On one of my machines running a WireGuard tunnel, the bandwidth counters were reporting zero for the tun0 interface for several days. Switching the network source to read from /proc/net/dev instead of the netlink socket resolved it, though with slightly less granularity. You configure this in the daemon section under network.source. Third, the Python handler scripts run in the same process as the daemon by default. If your handler crashes or hangs, it blocks the entire collection loop. Always wrap your handler logic in a try/except block and consider running long-running handlers as separate processes with a timeout. I use a simple subprocess call with a 30-second timeout on any handler that might involve network calls or heavy I/O.

When Mr Frosty Pants Isn't the Right Tool

Let me be straightforward about the limitations. If you're managing more than ten servers, you'll want something with a centralized backend. Mr Frosty Pants stores data locally only. You could set up a shared database or replicate the SQLite files, but that's not something the project supports out of the box. For multi-server setups, a tool like Prometheus with Grafana is the more appropriate choice even though it requires more initial configuration. If you need fine-grained application-level metrics — request latency, error rates, custom business KPIs — this tool won't give them to you. It monitors system resources, not application behavior. You'd pair it with something like Datadog Agent or the Prometheus node_exporter for that layer. The TUI also lacks any kind of theming or color scheme customization beyond the built-in palettes. That's a minor complaint but it does make long sitting sessions slightly more fatiguing if you're sensitive to color contrast. The dark palette is decent. The light one isn't.

Bottom Line

Mr Frosty Pants is a solid choice for single-server monitoring where you want live visibility and basic automation without maintaining a full monitoring stack. The event handler system is its real differentiator and the one thing I keep coming back to. For larger deployments or application-level monitoring, it falls short of dedicated tools. But for what it does, it does it well and the learning curve is manageable if you already know your way around a Linux terminal.