Detect Platform

Run this first, before any service-specific troubleshooting. Most support mistakes are not about the service — they are about assuming the environment: apt on a dnf box, a unit that has a different name here, "8 GB of RAM" when the container is capped at 512 MB, a 403 that is really SELinux. This skill establishes the ground truth once and hands the next skill a short profile.

Detection only. It reads; it changes nothing. Every command here is safe to run on a production host. If a command is missing or returns nothing, record "unknown" and move on — an absent tool is itself a signal (no systemctl usually means not systemd).

Probe, top to bottom

OS and package family — decides package manager, unit names, config paths.

grep -E '^(PRETTY_NAME|ID|ID_LIKE|VERSION_ID)=' /etc/os-release
for p in apt dnf yum apk zypper pacman; do command -v "$p" >/dev/null && echo "pkg: $p"; done

ID=ubuntu/ID_LIKE=debian => apt, services often named <svc> or <svc>-server, config under /etc/<svc>/. ID=rhel/fedora/centos (ID_LIKE includes rhel) => dnf, and SELinux is in play (below).

Init system — decides how you inspect and signal services.

ps -p 1 -o comm=            # "systemd" => systemctl/journalctl; otherwise adapt (openrc, s6, runit, init)

Substrate — bare metal, VM, container, or pod? This decides whether host-level tuning even applies (a container inherits it; bare metal owns it) and where logs go.

systemd-detect-virt         # "none" => bare metal; a hypervisor name (kvm/vmware/…) => VM;
                            # "docker"/"lxc"/"podman" => container
test -f /.dockerenv && echo "container: docker"
grep -qa 'kubepods' /proc/1/cgroup 2>/dev/null && echo "kubernetes: pod"
[ -n "$KUBERNETES_SERVICE_HOST" ] && echo "kubernetes: yes (service env present)"

Resources — and the cgroup limit, which is the one that fools people. The process sees the cgroup limit, not the host's RAM; a service sized for the host gets OOM-killed inside a smaller container.

nproc                                   # visible CPUs
free -h | awk '/Mem:/{print $2" total, "$7" available"}'
# cgroup v2 (most modern hosts):
cat /sys/fs/cgroup/memory.max           # a number = the hard cap in bytes; "max" = no limit
cat /sys/fs/cgroup/cpu.max              # "<quota> <period>"; "max <period>" = uncapped
# cgroup v1 fallback:
cat /sys/fs/cgroup/memory/memory.limit_in_bytes 2>/dev/null

If memory.max is a real number well below free -h total, that number is the ceiling — quote it to the service skill, which will size caches/workers against it.

Disk and filesystem — for the data path the service actually uses.

df -h /                                 # and df -h <data-dir> for the service's dbPath/dir
findmnt -no FSTYPE,OPTIONS /            # ext4/xfs/btrfs; note "noatime", and overlay => container layer

Security module — the top cause of "permission denied / 403" that is not a file mode.

getenforce 2>/dev/null                  # Enforcing/Permissive/Disabled (RHEL family); absent elsewhere
command -v aa-status >/dev/null && aa-status --enabled && echo "apparmor: enabled"   # Debian/Ubuntu

Enforcing means a denial may be SELinux, not the service — the service skill will point at ausearch -m avc and booleans/labels rather than at file modes.

The profile to carry forward

Assemble what you found into a few lines and keep it in front of you for the rest of the session. Example from a real run of the commands above:

os: Ubuntu 24.04 (debian family, apt)     init: systemd
substrate: bare metal                      k8s: no
cpu: 24                                     ram: 124Gi total
cgroup mem limit: none (bare metal)         rootfs: ext4 on LVM, 1.8T (46% used)
security: AppArmor enabled; SELinux n/a

Then hand these facts to the service skill: they tell it the package manager and unit names to use, whether host tuning applies, the memory ceiling to size against, and whether a permission failure is likely the security module. Do not re-detect them in the service skill — it assumes this ran.

Scope

• Detection and interpretation only — no installs, no config changes, no restarts.
• Unknown is a valid answer. Record it and continue; a later step can probe deeper if it matters.
• This is host/substrate detection, not service discovery. Which services run, and their versions, belong to each service's own skill.