Skip to main content

Servcheck

A quick bash script for sanity checks of a Linux web server.

Run:

curl -L https://bit.ly/servchecksh | bash

Description of the checks

1. Out-of-memory conditions

This checks whether the Linux kernel had killed a process due to reaching the OOM (Out of Memory) condition.
It typically indicates severe misconfiguration on the server.
Solutions include allocating swap space, lowering the number of worker processes for Apache or PHP-FPM, reducing MySQL buffers, etc.

To check this manually, on CentOS 7, you can run:

journalctl --no-pager --priority=err --dmesg | grep "Out of memory"

On CentOS 8+, you can run:

journalctl --no-pager --priority=err --dmesg --grep="Out of memory"

Example output, indicating Redis service was killed due to OOM:

Sep 24 20:37:43 host.example.com kernel: Out of memory: Kill process 20775 (redis-server) score 817 or sacrifice child

2. Broken outgoing email

This is a performance sanity check: telnet to 25 of external mail servers works?
Note that it is common for Amazon AWS (blocked outgoing port 25 can yield very poor WP performance when SMTP plugins are in use).

3. Missing swap allocation

Swap space is very essential to have on most servers. This check will find if your server is lacking swap space.
If it does, make sure to set up swap space.

4. Storage media and bounded write sample

Servcheck inspects the filesystem mounted at / by default. Set SERVCHECK_DISK_PATH to inspect another path. It resolves the mount source through findmnt (with df as a fallback) and walks common partition, LVM, device-mapper, and mdraid stacks through lsblk.

The storage type is reported as SSD/non-rotational only when every exposed backing disk has the kernel’s ROTA=0 signal, HDD/rotational only when every backing disk has ROTA=1, and unknown for mixed media, missing signals, virtual filesystems, or unresolved device chains. On virtual or cloud storage, ROTA=0 describes the presented block device and does not prove physical SSD media.

When safe, the check creates a unique temporary file on the selected filesystem and runs one 64 MiB sequential write sample. It requires at least 256 MiB free, requests direct I/O plus fsync, falls back to fsync when direct I/O is unsupported, and stops after 8 seconds. It never reads from or writes to a raw block device. The temporary file is removed on success, failure, timeout, or a handled signal. The result is a short diagnostic sample, not a sustained benchmark; caches, thin provisioning, network storage, and virtualization can affect it.

To inspect another filesystem:

curl -L https://bit.ly/servchecksh | sudo env SERVCHECK_DISK_PATH=/var/lib/mysql bash

To run the storage check without any write sample:

curl -L https://bit.ly/servchecksh | sudo env SERVCHECK_DISK_WRITE_TEST=0 bash

The write sample is also skipped when the target path is missing, free space cannot be verified, the filesystem is read-only, temporary-file creation fails, or a required utility is unavailable. These expected limitations do not make the check fail.

Recent Posts