Part 9

Hosting is a system: establish the facts before changing anything

A hosting problem often looks like “the script is broken” when the real cause is a PHP version, missing extension, full filesystem, permission, network path or mail transport. Terminal work becomes calmer when you first describe the machine you actually have.

The same project can behave differently on a different host

Your files may be identical while the runtime is not. PHP version, loaded extensions, filesystem limits, ownership, permissions, time, network access and server policy all affect what the application can do.

This is why a useful first question is not “what should I change?” but “what environment is executing this?” A terminal is good at turning that vague environment into inspectable facts.

Start with one screen of facts

core shows the current lil Core, PHP, interface layer, installed extension file, updates, active file and directory. doctor -q gives a compact health view, while sys host and sys uptime describe the host and how long the system has been running.

Do not treat a healthy summary as proof that every application is healthy. It is a baseline: a fast way to notice that the machine, Core or runtime is not what you expected before you investigate deeper.

core

doctor -q

sys host

sys uptime

A PHP feature exists only when this runtime actually provides it

php version, php modules and doctor extensions answer capability questions directly. A module such as IMAP, SQLite, GD or an encryption primitive may exist on one hosting plan and be absent on another.

A missing capability is different from a bad command. Prefer a clear capability error over random workarounds; confirm the extension first and then decide whether to enable it, choose another tool or move the task elsewhere.

php version

php modules

php info memory -c

doctor extensions

Free space, directory usage and permissions are different questions

disk . reports filesystem capacity; disk . -r deliberately walks the current tree to calculate usage. stat tells you what a path actually is. Permissions are another layer: a file can exist and there can be free space while PHP still cannot read or write it.

Do not “fix permissions” by making everything writable. Inspect owner and mode, change the smallest target that needs a change, then verify it again. Permissions are a local access boundary, not a substitute for authentication or encryption.

disk .

disk . -r

stat .

Read logs before deleting, restarting or guessing

log -l discovers likely logs. Once you know the relevant file, bounded head/tail reads and literal filtering let you inspect the newest evidence without loading a huge log into the browser.

A useful log line has context: time, component, request or operation, and the actual error. Preserve that context before you “clean up” anything. Many difficult incidents become ordinary once you can say exactly when the failure started and what changed around it.

log -l

Environment values and mail are separate subsystems worth testing explicitly

env exposes environment, server and request values in readable form while masking sensitive names. It helps answer questions such as which temporary directory or server address PHP sees without making you dump the whole runtime blindly.

mail is its own diagnostic surface: local PHP mail transport and an IMAP connection are not the same thing. A website can render perfectly while outbound mail is rejected, or IMAP can be unavailable because the extension is missing. Test the subsystem you actually depend on.

env server SERVER_ADDR

env TMP

mail

Save the baseline before the repair

Redirect compact reports into a diagnostics/ directory before you change PHP settings, modules, permissions or hosting configuration. After the change, collect the same reports again and compare facts rather than relying on “it feels better now”.

This habit scales beyond lil-terminal. On Linux, macOS, Windows, containers and control panels, good diagnostics follow the same sequence: identify the environment, isolate the layer, collect evidence, change one thing, verify.

md diagnostics

doctor -j > diagnostics/doctor.json -r

sys > diagnostics/system.txt -r

php version > diagnostics/php.txt -r

Keep this as a script

Save this as hosting-baseline.lil. It collects a compact diagnostic snapshot into diagnostics/ without changing application data. Keep snapshots from before and after a hosting change: comparison is usually more useful than memory.

#lil
@install md doctor sys php disk log env
md diagnostics
core > diagnostics/core.txt -r
doctor -q > diagnostics/doctor.txt -r
sys > diagnostics/system.txt -r
php version > diagnostics/php.txt -r
disk . > diagnostics/disk.txt -r
log -l > diagnostics/logs.txt -r
env server SERVER_ADDR > diagnostics/server.txt -r