Working with Solaris machines feels different from solaris commands handling Linux boxes, and anyone who has spent late nights troubleshooting a slow server knows this truth firsthand.
Every command carries its own logic, and the syntax often surprises even experienced admins. This guide walks through the everyday Solaris commands that keep a system healthy, checked, and ready for production work.
Solaris Commands
I always start a health check by looking at memory, since a starved system rarely performs well. Running prtconf and piping it through grep reveals the Memory size, and on one of my own servers this showed 261632 Megabytes assigned to the box.
When the devinfo facility isn’t available, prtdiag becomes the backup tool, and both commands help confirm exactly how much RAM sits on the Solaris Machine, giving a DBA a clear starting point before digging into performance issues.
CPU / Cores
Counting cores on a Solaris box takes a small combination of tools, and kstat paired with cpu_info, core_id, uniq, and wc gets the job done quickly.
On a system I managed, this returned 32 total cores, and dividing that number by the output of psrinfo -p, which showed 4, gave 8 cores per physical processor.
Running psrinfo -pv dug even deeper and revealed 64 solaris commands virtual processors numbered 0-63 on a SPARC-T4 chip running at clock speed 2848 MHz; checking the CPU status with psrinfo -v rounds out this picture nicely.
Prstat (Process Monitoring)
prstat works like top for Solaris administrators, and those coming from Linux experience often install top out of pure convenience before realizing prstat format offers more depth.
Running prstat -a shows active processes, while adding -s size sorts them by MEMORY CONSUMING PROCESS in DESCENDING ORDER; a similar view comes from ps -efo pmem,rss,pid,pcpu,args piped through sort and head 20.
Using prstat -t shows users resource utilization, and prstat -L breaks output down by thread per line instead of grouping by process.
Each column in prstat output tells its own story: PID identifies the process ID, USERNAME shows the real user or login name or user ID, and SIZE reports the total virtual memory size including mapped files and devices in kilobytes (K), megabytes (M), or gigabytes (G).
RSS tracks the resident set size, STATE reflects whether a process sits in cpuN, sleep, wait, run, zombie, or stop mode, and PRI shows priority, where larger numbers mean higher priority.
The NICE column carries the nice value used in priority computation, though only certain scheduling classes actually use it, and TIME tracks cumulative execution time while CPU shows the percentage of recent CPU time consumed, which changes inside a non-global zone when the pools facility and processor set for that pool or zone come into play.
PROCESS simply lists the name of the executed file, and NLWP counts the lwps running under it. Load average figures like 0.65, 0.42, and 0.36 represent the last minute, last five minutes, and last 15 minutes respectively, giving a quick snapshot of system strain.
Sorting with prstat -s supports sub-options including cpu, pri, rss, size, and time, letting an admin sort by process cpu usage, priority, resident set size (physical memory), size (virtual memory), or execution time.
Digging deeper still, prstat -mL reveals microstate accounting across the USR column through the LAT column over a sampling period of 5 seconds, and these figures should total 100 percent of threads time for that window.
This view supports System Bottleneck determination, where USR shows regular usage, SYS shows kernel load, LAT flags CPU bottleneck identification, TFL and DTL point to memory paging waits for memory bottleneck identification, and SLP highlights disk and network waits tied to I/O bottleneck identification.
Running prstat -c switches to continuous mode, and adding -n 3 limits output to just three reports; new reports get printed below older ones instead of overprinting them, which helps enormously when gathering information into a file like prstat.txt using a maximum length setting.
This kind of process monitoring separates a casual user from someone who genuinely understands the box.
A handful of Solaris veterans use prstat properly, offering CPU info, CPU usage stats across global zones and non-global zones, multiple screens of data at set intervals, and useful summaries of the top users consuming OS resources, and getting comfortable with this guru-level command examples pays off during any real production incident.
Networking
Checking network health on Solaris starts with ifconfig -a, which lists network cards and their IP addresses in one shot. Firewall status gets checked and changed through svcadm enable or disable on the service ipfilter, using the full path svc:/network/ipfilter:default, and ipfstat -io shows the current rule set in action.
For link speed, a simple one-liner using kstat -p piped through grep for link_speed works even as a regular user, and on one e1000g nic this returned a Port Stats value of 1000, tagged neatly under useful Solaris commands for network troubleshooting.
Process Information / Ports
Tracking down open files for any process happens through pfiles followed by the process_id. Sometimes an admin needs to kill specific processes, and a script targeting apache for a particular user like oracles combines ps -fu, grep, -v grep, and awk to print the right column before piping into xargs for kill -9.
Beyond that, checking listening ports across all processes uses ps -ef combined with egrep for sockname, and dropping that filter gives an even more detailed view of examining process activity across all processes running on the box.
DISK
Disk health starts with iostat -xzn 5, producing extended device statistics across columns like r/s, w/s, kr/s, kw/s, wait, actv, wsvc_t, asvc_t, %w, %b, and device.
On one system this showed 8.2 and 6.2 for read/write rates, 163.8 and 90.0 for throughput, 0.5 and 0.2 for wait, 35.4 and 13.1 for service times, 8 and 10 percent busy against device c3d0; another line showed 1.4, 12.2, 30.0, 81.4, 0.1, 0.2, 8.9, 13.0, 3, and 7 against c6t0d0.
The wait column really matters here, since it reflects waiting queue length for pending IO operations, and staying in the single digit range usually means the bottleneck sits elsewhere.
fsstat -F 5 gives a completely different angle, solaris commands showing new name, name, attr, lookup, rddir, read, write, file, remov, chng, get, set, ops, and bytes counts across filesystem types like ufsv, proc, nfs, zfs, lofs, tmpfs, mntfs, nfs3, and nfs4.
Real numbers from a busy box showed 1.05K file operations, 2.22K lookups, 4 reads totaling 1.04K ops and 406K bytes, and 2 writes covering 32 ops; the zfs line alone carried 1 file operation, 1 rename, 3.89K attr gets, 5 attr sets, 12.6K lookup ops, 4 read ops pulling 9.7K bytes, 8.19K write ops pushing 568K bytes, plus 41 on lofs and 33, 34, 6, and 2.41K scattered across tmpfs.
This tool answers real questions about whether users create too many filesystems, generate heavy IO load, or push traffic through NFS versus keeping it local, and a few well-chosen flags unlock all of that insight.
VMSTAT (Virtual Memory Statistics)
Running vmstat 5 collects virtual memory statistics across a time interval of five seconds, and the procs section reports kernel threads sitting in the dispatch queue (r), blocked kernel threads waiting on resources (b), and swapped out LWPs (w) still waiting for processing.
The memory section covers real memory and virtual memory usage through swap (available swap space) and free (free list), while the page section tracks page faults and paging activity per second through re (pages reclaimed), mf (minor faults and major faults), pi (kbytes paged in), po (kbytes paged out), fr (kbytes freed), de (anticipated memory for recently swapped-in processes), and sr (pages scanned by the page daemon).
Disk activity reports disk operations per second, faults shows trap and interrupt rates through in (interrupts per second), sy (system calls per second), and cs (CPU context switch rate), and finally cpu breaks down us (user time), sy (system time), and id (idle time).
A real sample using kthr, cd, s0, and s2 columns showed values like 446144, 130076, 23, 100, 1, 3, 0, 12, 7, -0, 13, 465, 1352, 1137, 6, and 82; a second line showed 405376, 90808, 33, 41, 0, 39, 514, 500, 571, 4, 11, and 85, and a third showed 405296, 90536, 29, 502, 778, 551, 10, and 86 — always skip the very first line, since it reflects an unknown sample size rather than real-time behavior.
For CPU health, watching system idle time as a percent answers most questions instantly, since staying above zero most of the time means adequate CPU power, and only a persistently flat zero suggests it’s time to buy a bigger CPU.
For memory, three numbers matter most: swap shows free virtual memory, free shows free physical memory, and scan rate shows how hard the memory page scanner works to free up expendable chunks of physical memory; single-digit scan rates stay healthy, but large sustained values point straight to needing more RAM.
Disk Type
Checking disk hardware type happens through iostat -E, giving a fast readout of drive information without extra noise.
Change the prompt in Solaris
Customizing the prompt makes navigation easier, and setting PS1 to include hostname and pwd shows exactly where a session sits at any moment. Inside ksh, running export with a PS1 value of $PWD achieves the same clarity, keeping every terminal window easy to track during long sessions.
System and Software Version
Checking the installed OS release and patch level happens through showrev -a, which prints a full summary in one command.
System Product Name
Identifying the exact hardware model running underneath solaris commands happens through prtconf -b, a quick check worth running before opening a support case.
Using nohup for existing processes
nohup solves a problem every admin runs into eventually: closing a terminal session or losing an SSH connection to a remote server normally sends SIGHUP as a signal to every child process, telling the shell to wrap up and terminate whatever it was doing.
Running a script like massive-job.sh with nohup in the background keeps it alive past session end, sending output into a log file called nohup.out, and the returned PID (in this case 3763) identifies the process ID for later reference; watching that output live works through tail -f on nohup.out.
Newer versions of Solaris 10 added a genuinely useful twist: applying nohup to an existing process through -p and a PID like 3468, without needing to restart anything from scratch.
This matters most when a script kicked off in the morning clearly won’t finish by afternoon, and rather than leaving a laptop connected all day just to avoid SIGHUP, updating the running process directly solves it.
Trying this without proper privileges returns a permission denied message instead, so checking access level matters before assuming the fix will work, and this small trick has saved plenty of evenings where disconnecting a laptop would otherwise kill a critical job.
Using Service Controller to confirm battery status
Replacing hardware like an SC battery inside a T2000 server sometimes leaves prtdiag unable to report fans stats right after rebooting, since the picld daemon hasn’t fully started yet.
Switching over to ALOM and running show environment solves this gap completely, returning full voltage sensors data measured in volts across every sensor with its status, voltage, LowSoft, LowWarn, HighWarn, and HighSoft thresholds. Boards like MB/V_+1V5, MB/V_VMEML, MB/V_VMEMR, MB/V_VTTL, MB/V_VTTR, MB/V_+3V3STBY, and MB/V_VCORE all reported OK status with readings such as 1.48, 1.36, 1.39, 1.60, and 1.63 volts.
Additional sensors covering IOBD/V_+1V5, IOBD/V_+1V8, IOBD/V_+3V3MAIN, IOBD/V_+3V3STBY, IOBD/V_+1V, IOBD/V_+1V2, IOBD/V_+5V, IOBD/V_-12V, and IOBD/V_+12V showed values ranging from 1.18 up through 12.06, with negative rail readings like -12.11 and -13.08 falling within expected bounds.
The battery-specific line, SC/BAT/V_BAT, reported OK at 3.37 volts against a LowWarn of 2.25, confirming the replacement battery had installed correctly and giving peace of mind before closing out the maintenance ticket.
Architecture
Checking binary compatibility on Solaris 10 solaris commands happens through isainfo -v, which confirms support for both 32-bit and 64-bit binaries on the current architecture.
Other interesting stuff to begin with
Listing every service instances on a box, whether active, inactive, or disabled, happens through svcs -a pulled straight from the service configuration repository.
Each service keeps its own log file under /var/svc/log, making troubleshooting far faster once an admin knows exactly where to look. Downloading a package from a repository works even across versions, since a Solaris11 machine can pull software meant for installation destination on a Solaris10 server.
Running /opt/csw/bin/pkgutil with flags like –stream, –target=sparc:5.10, –output, and –download grabs a package such as vim-and-others.pkg, and confirming with –yes completes the vim installation cleanly.
Once downloaded, pkgadd -d finishes the installation on the target Solaris 10 machine. Storage checks round things out nicely .
Getting the list of LUNs uses sudo with mpathadm list lu piped through grep for rdsk, and checking the state of those LUNs across multiple hosts works by looping ssh through each dir, running mpathadm show lu for every result, solaris commands and appending output for later review.
FAQS about solaris commands
What is the command for Solaris version?
Checking the Solaris version happens through showrev -a, which prints the full OS release and patch level in seconds. Every admin should run this quick check before opening a support case, since it saves time explaining the setup.
What are 5 Linux commands?
Common Linux commands include ps, grep, top, ifconfig, and awk, each handling process, text, or network tasks. Solaris shares some of these tools too, though the arguments often behave a little differently across both systems.
What are 10 examples of commands?
Useful examples span prtconf, psrinfo, prstat, iostat, vmstat, ifconfig, svcadm, pfiles, nohup, and showrev, covering memory, CPU, and disk checks. Learning these ten builds real confidence for anyone managing a Solaris Machine day to day.
How do I list all processes in Solaris?
Running ps -ef lists every process on a Solaris system, while prstat -a shows a live, sortable view instead. Combining either with pfiles or egrep for sockname reveals exactly what each process is doing.