Where Solaris keeps its logs, and using fmadm/fmdump for hardware and software faults

What it is

Solaris keeps most system-wide log messages in /var/adm/messages; dmesg displays the last 200 syslog entries from that file and any rotated copies of it, in chronological order. Separately, each SMF service instance's own stdout/stderr from its start method lands in a per-instance log file under /var/svc/log/, whose exact path is what svcs -l <fmri> reports. Independently again, the Fault Management Architecture (FMA) — fmd and its administration tools fmadm and fmdump — diagnoses hardware and some software faults, turning raw telemetry into a diagnosed fault with a UUID, a suspect list and a suggested action.

Why it matters

FMA exists because a single hardware event (a failing DIMM, a disk starting to report errors) can generate many raw error reports; FMA's diagnosis engines correlate them into one fault record instead of leaving an administrator to read many log lines and guess. This is a different mental model from Linux, where kernel logs and separate vendor tools are typically used piecemeal for the same purpose.

How to apply

• List currently faulty components: fmadm faulty shows components FMA has diagnosed as faulted, defective, or otherwise flagged, with the diagnosis UUID for cross-reference. It needs the solaris.fm.read authorization (rights profile "Fault Information" or "Fault Management", or the root role); SMF services that dropped into maintenance can appear here too.
• View the full diagnosis history, not just current faults: fmdump alone prints the fault log (one line per diagnosis event, including rotated logs); add -v for verbose per-event detail. fmdump -e shows the raw error telemetry (ereports) instead, which is private-format and not meant for parsing in scripts. Reading these logs normally needs the root role.
• Look up one event by its UUID: fmdump -u <uuid> -v prints the full diagnosis for that event, useful when a service or monitoring alert already gave you a UUID.
• For an SMF service failure, start from svcs -x (see the SMF article in this series), which names the log path; read that file under /var/svc/log/ for the service's own error output, separate from anything FMA diagnosed.
• Check kernel-level and general system messages quickly with dmesg, and read /var/adm/messages directly for more than the last 200 entries or for entries dmesg has already rotated past.

Pitfalls

• Looking only in /var/adm/messages for a service failure: the service's own start-method output is in its dedicated file under /var/svc/log/, not in the system message log.
• Treating fmadm faulty as the complete fault history: it shows current faults, not resolved ones; use fmdump for the full timeline, including faults that have since been repaired or replaced.
• Assuming every hardware problem produces an FMA fault; some conditions still only appear as raw messages in /var/adm/messages, particularly on unsupported or virtualized hardware where platform-specific diagnosis modules are absent.