Getting Your Ubuntu Apps Under Control
Ubuntu runs two different app ecosystems simultaneously, and that alone causes most people headaches. The Snap Store handles snap packages, which are containerized apps bundled with their own dependencies. System Monitor, on the other hand, is your view into what those processes are actually doing on the machine. They serve different purposes but overlap enough that you need to know where each one fits. I keep coming back to the same issue: a user installs an app from the Snap Store, then opens System Monitor and sees eight separate processes all named slightly differently. Most people assume the app is running multiple instances or bloatware. In practice, it is just how snaps work. A snap gets its own mount namespace, its own PID space boundary, and several helper threads for sandboxing and auto-refresh. That is normal. The snap command-line interface is where most of the real control lives. I open a terminal and use snap list to see everything installed. It shows version, tracking branch, refresh time, and whether the snap is disabled. That last field matters more than people realize. If a snap is disabled, it will not start on login, but it still occupies disk space and may show up in System Monitor if the snapd daemon is managing it in the background.
To get detailed info about a specific snap, I run snap info application-name. This tells me the installed version, the channel it is tracking, the commands it exposed, and the interfaces it has connected. The interfaces section is where things get interesting. Each interface is a policy connection between the snap and the system. Audio play-back, home, network, removable media, desktop, desktop-legacy, opengl — these are all individual permissions you can inspect and manage separately. There is a common pitfall here that catches people out. When you install a snap, many interfaces auto-connect because they are in the snap's declared plug list and the store considers them safe. But not all of them. Sometimes a snap installs and appears broken because a required interface did not auto-connect. I spent a solid afternoon troubleshooting a voice recorder app that silently failed to save files. The app was running fine otherwise. The issue was the home interface had not been connected after installation. Running snap connect recorder-app:home fixed it immediately. Checking snap connections shows the full state at any time, and I treat it as a first diagnostic step whenever an app behaves oddly. System Monitor reveals the same information visually, but it does not explain why. The Processes tab lists every process sorted by resource usage. If you filter by the snap name, you will see the main process plus helper threads, the snap-confine seccomp wrapper, and the snapd daemon handling the refresh cycle. Sorting by memory or CPU can make a single snap look like it is consuming far more than it should, mostly because the snapshot includes kernel-level overhead from the mount namespaces. What looks like a memory leak is often just the snap being held at a higher baseline because it preloads more libraries inside its bundled runtime.
One counter-intuitive thing about snaps is that they are not necessarily heavier than traditional .deb packages. A snap might have a larger disk footprint because it bundles its libraries, but on systems where multiple apps share similar dependencies, the deduplication within the snap blob means less actual unique data on disk than you would get from installing the same libraries separately through apt. The trade-off is RAM. Snaps tend to hold onto their libraries in memory differently, so the per-app baseline is slightly higher. On a machine with 8 GB of RAM or less, this difference shows up. On 16 GB or more, it rarely matters. For managing running snaps directly, snap services is useful. It shows which snaps are running as systemd services versus which are just triggered applications. If a snap has a service component and it is failing, snap logs application-name gives you the journal output. I found this critical when a background media server snap kept stopping after each reboot. The snap itself was fine. The service unit had a timeout set too low for the hardware I was running. Adjusting the timeout through the systemd override and restarting the service resolved it without touching the snap configuration. System Monitor also has a Resources tab that shows disk, network, and memory breakdowns. The disk section here will show you how much space is being used by the /snap directory. If that number keeps growing, the likely cause is old snap revisions accumulating. Each snap refresh keeps the previous revision around for rollback, and by default Ubuntu retains roughly two previous versions. Over months, that adds up. I run snap refresh --time to see when the next refresh is scheduled, and I remove unused revisions manually with snap remove --revision when I am confident the current version is stable.
Get the Full Details
Another practical detail that most guides skip: you can disable auto-refresh entirely if you prefer to control when snaps update. snap refresh --time=0 turns it off. This is relevant if you rely on specific app versions for stability, like a development tool or a workflow-critical editor. The downside is that you also stop receiving security updates automatically, so you need to remember to refresh manually. I set a recurring reminder instead of relying on my memory, which works better than I expected. When an app from the Snap Store acts strangely, the standard troubleshooting path I follow is straightforward. First, check if it is running with ps aux | grep snap-name. Second, verify connections with snap connections snap-name. Third, pull the logs with snap logs snap-name. Fourth, if those do not reveal anything, try refreshing the snap to the latest stable version or rolling back to the previous revision. This sequence resolves the majority of issues without needing to purge and reinstall. Purging a snap removes the installed version and all its data. sudo snap remove --purge snap-name does this. Be careful with this command if the snap stores configuration or user data in a place you want to keep. Some snaps store data under ~/snap/application-name, and removing the snap does not touch that directory automatically. If you want a clean slate, you need to delete that folder manually afterward. I learned this the hard way with a note-taking app that I switched away from and later wanted back with its old data intact.
System Monitor becomes much more useful once you stop treating it as a generic task manager and start using it alongside the snap commands. Cross-referencing a process count from System Monitor with the output from snap info and snap connections gives you a complete picture in about two minutes. Without that habit, you end up guessing, which wastes more time than the commands themselves take to run. There are scenarios where snaps simply do not fit. If you need direct hardware access that the interface system does not support, or if you are running a specialized server workload where every megabyte of memory matters and the snap overhead is unacceptable, then traditional apt packages are the better choice. The Snap Store is convenient for desktop apps and general-use software. It is not a universal solution, and pretending it is will only lead to frustration on constrained or specialized systems. The bottom line is that Ubuntu gives you both tools for a reason. The Snap Store manages what is installed and how it behaves. System Monitor shows you what is running. Neither replaces the other, and neither alone gives you full visibility. Using them together with the command-line tools as a bridge is what actually lets you troubleshoot efficiently instead of restarting the system and hoping for the best.
