Overview

system-admin provides practical workflows for Linux system administration, including viewing basic OS and host information, inspecting hardware, real-time and historical resource monitoring, and managing services via systemd. You use these repeatable patterns to verify server status, troubleshoot performance issues, and ensure correct startup behavior of services.

How This Skill Works

You leverage a curated suite of native Linux tools described in the skill content to gather state and enforce operational checks. You’ll typically run commands like cat /etc/os-release, uname -a, and uptime to establish a quick health baseline, then drill into hardware with lscpu and /proc reads, monitor in real time with top/htop, vmstat, iostat, iotop, iftop, and nethogs, and finally inspect historical trends with sar. For service management, you use systemctl to query, start/stop/restart, and enable/disable units, complemented by journalctl for per-service logs.

When to Use It

• After provisioning a new Linux host to verify baseline (OS, host, hardware)
• During performance troubleshooting (high load, IO wait, memory pressure)
• When investigating a failing or misbehaving systemd service
• For capacity planning and resource auditing using real-time and historical data
• For post-change validation after patches or configuration updates

Quick Start

1. 1) Run a quick health snapshot to establish baseline:
2. ```bash
3. echo "=== System Load ===" && uptime
4. echo "=== Memory Usage ===" && free -h
5. echo "=== Disk Usage ===" && df -h
6. echo "=== Failed Services ===" && systemctl --failed
7. ```
8. 2) Inspect OS and host identity:
9. ```bash
10. cat /etc/os-release
11. uname -a
12. hostnamectl
13. ```
14. 3) Check hardware and storage layout:
15. ```bash
16. lscpu
17. free -h
18. lsblk
19. df -h
20. ```
21. 4) Start real-time monitoring and service checks:
22. ```bash
23. top
24. vmstat 1
25. iostat -x 1
26. systemctl status nginx
27. journalctl -u nginx | tail -n 20
28. ```

Best Practices

• Run commands with sudo when you need privileged access to /proc or systemd
• Prefer non-intrusive monitoring on production (avoid long-running heavy captures)
• Capture outputs to logs for auditability (e.g., using tee to write to a file)
• Use sar for historical data instead of relying solely on ad-hoc snapshots
• Combine classification commands (e.g., systemctl + journalctl) to correlate service status with logs

Example Use Cases

• Scenario: Post-Provisioning Sanity Check — you verify the fresh server baseline with cat /etc/os-release, uname -a, hostnamectl, and baseline hardware view via lscpu and lsblk before deploying workloads.
• Scenario: Troubleshoot High CPU / Load — you identify top CPU consumers with ps aux --sort=-%cpu | head -10 and cross-check with uptime, then isolate memory pressure via ps aux --sort=-%mem | head -10 and free -h.
• Scenario: Disk Space Shortage — you check disk usage with df -h, then drill into large directories with du -sh /*, and optionally ncdu for interactive exploration.
• Scenario: Service Misbehavior — you verify service status via systemctl status, check if it's enabled on boot, and inspect recent logs with journalctl -u <service-name> --since today.
• Scenario: IO and Network Bottlenecks — you monitor IO with iostat -x 1 and iotop, and examine network usage with iftop or nethogs to identify bandwidth-heavy processes.

Frequently Asked Questions