Packages, logs, cron and disks

apt update only downloads fresh package lists from the configured repositories, so apt knows which versions exist. It changes no software. apt upgrade then installs newer versions of packages that are already installed, without removing anything. apt full-upgrade goes further and may install new dependencies or remove packages to complete the upgrade, which kernel and some library updates need. So the normal sequence is update, then upgrade. On production I review apt list --upgradable first, take a snapshot before larger changes, and let unattended-upgrades handle routine security fixes daily. Moving between Ubuntu releases is a separate, planned do-release-upgrade.

First stabilize: df -h to see which filesystem is full, and df -i to rule out inode exhaustion. Then find the cause with du -xh --max-depth=1 sorted by size, drilling into the largest directories, or ncdu. Common culprits are logs without rotation, the journal, Docker images and build cache, old release directories and stray database dumps. I free space safely: truncate live logs instead of deleting them, vacuum the journal, prune Docker, remove old releases. If space does not come back, lsof +L1 shows deleted files still held open by a process. Afterwards I fix the root cause with logrotate rules, journal limits and a disk alert.

Cron runs commands with a minimal environment. PATH contains only a few system directories, your .bashrc or .profile is not loaded, the working directory is the user's home, and it uses /bin/sh rather than bash unless you say otherwise. So commands like node or php installed in other places are not found, relative paths break and environment variables are missing. Fix it with absolute paths to binaries and files, cd into the right directory, set needed variables in the crontab or a wrapper script, and always redirect output to a log with >> file 2>&1 so you can see errors. Also check the time zone.

For text log files I add a logrotate rule per application: rotate daily or weekly, keep a fixed number of files, compress old ones, and use copytruncate or a postrotate signal so the app keeps writing to the new file. For the systemd journal I set SystemMaxUse in journald.conf so it stays under a size limit. Applications should avoid debug-level logging in production. For anything that matters long-term, logs should be shipped to a central system, such as Loki or a hosted service, so the server only keeps a short local window. And a disk usage alert catches whatever the rules miss.

Usually not. Linux uses otherwise idle RAM as a page cache for files, which makes disk reads faster, and releases it immediately when applications need memory. That cache shows up as used, so the free column looks small on a healthy machine. The number to watch is available, which estimates how much memory can be given to new work without swapping. Real trouble looks like low available memory, steady swap activity, rising load with high I/O wait, or OOM killer messages in journalctl -k. Then I look for the process that grew, such as a leak or an untuned database, before simply buying more RAM.

On most small and medium VPS instances, yes, a modest amount, typically 1 to 2 GB or so. It acts as a safety buffer: a short memory spike makes the server slower instead of triggering the OOM killer, which might kill the database. It also lets the kernel move rarely used pages out of RAM. Swap is not extra memory, though; disk is far slower than RAM. If a server swaps constantly, it is undersized or an app is leaking, and the fix is more RAM or tuning. Some setups, like Kubernetes nodes or latency-critical databases, deliberately run without swap or with very low swappiness.

I separate risk levels. Security updates from the distro's security pocket are applied automatically every day with unattended-upgrades, because a known vulnerability left open is a bigger risk than a well-tested security patch. Feature and point updates, third-party repositories such as databases or runtimes, and anything needing a restart of a critical service go through a planned window: staging first, a snapshot, then production. Packages that must move in step with the application, such as a database major version, are pinned or held. For kernel updates I either allow automatic reboots at a quiet hour, if the app tolerates a short restart, or track /var/run/reboot-required and reboot deliberately. Fleet-wide, I stagger updates across servers so a bad update never hits everything at once.

I confirm it with numbers before tuning anything. vmstat shows blocked processes and wa; iostat -x shows per-device read and write latency and queue size. On network-attached cloud volumes, compare the observed IOPS and throughput with the plan's documented limits, because hitting a provider cap looks exactly like slow disk. pidstat -d or iotop confirms the database is the process doing I/O, and /proc/pressure/io shows how much time tasks are stalled. Then I check the cause on the database side: missing indexes causing full scans, a buffer pool too small for the working set, so reads go to disk, or a checkpoint or backup job saturating writes. Fixes range from query and memory tuning to local NVMe or a higher IOPS tier.

I treat the server disk as replaceable. It holds the operating system, the application release, short-lived caches, a short window of local logs and the database files if the database is self-hosted. Anything whose loss would hurt goes elsewhere: user uploads to S3-compatible object storage, database backups to object storage at another provider or region, and logs shipped to a central system. That makes the disk small and predictable, so it rarely fills up, and makes rebuilding a server a matter of provisioning plus restoring data rather than rescuing a pet machine. The trade-offs are extra latency and egress for object storage, more moving parts, and the need to handle credentials for those services securely.