Top 20 Linux Commands Every IoT Developer Should Know
If you've ever SSH into a gateway at 2 a.m. because telemetry stopped flowing, you already know: on IoT hardware, the terminal isn't a convenience — it's the only interface you get. Most edge devices, gateways, and single-board computers run headless. No GUI, no desktop, sometimes not even a display driver. Whatever you can't do from a shell prompt, you can't do at all.
That's why Linux command-line fluency shows up on almost every IoT and embedded job description, right next to MQTT, RTOS, and PKI. Distributions like Yocto, Buildroot, Ubuntu Core, and Raspberry Pi OS all assume you're comfortable working blind — diagnosing a flaky sensor over SSH, figuring out why a device won't reconnect to the broker, or tracing why a gateway silently filled its disk with logs.
This article walks through the 20 Linux commands that come up constantly in real IoT workflows — grouped not alphabetically, but by the actual problems they solve: navigating the filesystem, watching resource usage on constrained hardware, managing services, diagnosing the network stack, and talking directly to sensors over I2C or GPIO.
Why Linux Command-Line Skills Matter for IoT Development
Before the list, it's worth being clear on why this matters more in IoT than in general software work.
Linux is the default OS at the edge. Gateways, industrial controllers, and single-board computers overwhelmingly run some Linux variant — Yocto-built images, Buildroot, Debian-based distros, or Ubuntu Core for snap-based fleets. If you're building the firmware-to-cloud pipeline, you're living in that shell.
Most IoT devices are headless by design. There's no monitor plugged into a sensor gateway sitting in a factory panel. Every log you read, every process you kill, and every network interface you inspect happens through a terminal session, usually over SSH.
Field debugging is command-line only. When a device is already deployed — behind a firewall, on a cellular modem, three states away — you don't get a debugger UI. You get ssh, and whatever commands you know well enough to use quickly under pressure.
With that context, here are the 20 commands, grouped by workflow.
File & Directory Management Commands
ls, cd, pwd — Navigating Embedded Filesystems
The basics, but embedded filesystems have their own conventions worth knowing — /etc for device configs, /var/log for application logs, and vendor-specific paths like /opt for Greengrass or AWS IoT Device SDK installs. ls -la is your default: it shows hidden dotfiles (like .aws or .ssh) that hold credentials and config.
ls -la /opt/aws/greengrass
cd /var/log && pwd
find and grep — Locating Config Files, Logs, and Firmware Artifacts
When a device has thousands of log files and you're hunting one error, find locates files and grep searches inside them.
find / -iname "*.log" -mtime -1 # log files modified in the last day
grep -r "TLS handshake failed" /var/log/
cp, mv, tar — Packaging and Transferring OTA Payloads
Firmware and OTA update artifacts are almost always moved around as compressed archives. tar is the standard for bundling a firmware image with its manifest and signature before pushing it to a device fleet.
tar -czvf firmware_v2.1.tar.gz ./build/firmware.bin ./manifest.json Quick answer: How do I search for a file across an entire embedded Linux filesystem? Combine find (to locate by name or timestamp) with grep -r (to search file contents) — together they cover nearly every "where did that config go" scenario.
System Monitoring & Resource Management Commands
top / htop — Catching CPU Spikes on Resource-Constrained Boards
IoT boards often run on a fraction of the CPU and RAM of a server. top (or the friendlier htop, if installed) shows live CPU and memory usage per process — essential for catching a runaway sensor-polling loop before it saturates the board.
top
htop # if available — sortable, color-coded, easier to read
free -h — Monitoring RAM on Low-Memory Devices
On a Raspberry Pi or similarly memory-limited SBC, free -h gives a human-readable snapshot of used, free, and cached memory — the first command to run when a device becomes sluggish or an OOM killer starts terminating your application.
free -h
df -h and du -sh — Preventing Disk-Full Failures
Gateways that buffer sensor data locally before uplinking are notorious for silently filling their disks. df -h shows overall disk usage by partition; du -sh <directory> drills into which directory is the culprit.
df -h
du -sh /var/log/*
ps aux — Finding Rogue or Zombie Processes
Where top shows a live view, ps aux gives you a static, scriptable snapshot of every running process — useful for piping into grep to check whether your MQTT client or Greengrass core is actually running.
ps aux | grep mosquitto Quick answer: Why does my IoT gateway run out of memory over time? Usually a combination of unbounded local log growth (du -sh) and a process leaking memory (top/htop) rather than being restarted — both of which these four commands will surface in under a minute.
Process & Service Management Commands
systemctl — Managing Services Like Greengrass, Mosquitto, or Custom Daemons
Modern embedded Linux distros use systemd to manage background services, including your edge application, MQTT broker, or AWS IoT Greengrass core. systemctl starts, stops, restarts, and reports the status of any of these.
sudo systemctl status greengrass.service
sudo systemctl restart mosquitto
sudo systemctl enable my-edge-app.service # start automatically on boot
journalctl — Reading Service Logs for a Crashed Edge Application
When a systemd-managed service crashes, journalctl is where the stack trace and exit reason live — far more useful than digging through scattered log files.
journalctl -u greengrass.service -n 100 --no-pager
journalctl -f -u my-edge-app.service # follow logs live
kill / killall — Recovering From a Hung Sensor-Polling Process
Sometimes a process ignores its own shutdown signal and needs to be terminated directly, by process ID (kill) or by name (killall).
kill -9 <pid>
killall -9 sensor-poller Quick answer: How do I check why a systemd service failed on an IoT device? Run systemctl status <service> first for the immediate error, then journalctl -u <service> -n 100 for the full log leading up to the failure — this two-command combo resolves the majority of "why won't my edge app start on boot" issues.
Network Diagnostics Commands
ping — Verifying Broker/Cloud Connectivity From the Device Side
The first sanity check when a device stops publishing: can it even reach the network at all?
ping -c 4 a1b2c3d4e5.iot.us-east-1.amazonaws.com
ip a / ifconfig — Checking Interface State on Wi-Fi, Ethernet, or Cellular
ip a (the modern replacement for the deprecated ifconfig) shows every network interface, its assigned IP, and whether it's actually up — critical when a device has multiple possible uplinks (Wi-Fi, Ethernet, LTE modem).
ip a
ss / netstat — Confirming a Device Is Listening on the Right Port
ss (replacing the older netstat) confirms whether your MQTT-over-TLS client or local broker is actually bound to the port you expect.
ss -tuln | grep 8883 # confirm something is listening on the MQTT TLS port
curl / wget — Hitting REST Endpoints and Testing OTA URLs
Beyond MQTT, most IoT stacks also lean on HTTPS for OTA firmware downloads or REST-based provisioning. curl is the faster diagnostic for testing an endpoint or downloading a firmware bundle directly on-device.
curl -v https://your-ota-bucket.s3.amazonaws.com/firmware_v2.1.tar.gz -o firmware.tar.gz
tcpdump — Packet-Level Debugging of TLS Handshakes and MQTT Traffic
When ping succeeds but the device still can't establish an MQTT-over-TLS session, tcpdump lets you capture and inspect the actual handshake — invaluable for catching certificate mismatches or blocked ports at the packet level.
sudo tcpdump -i eth0 port 8883 -w mqtt_capture.pcap Quick answer: How do I debug an IoT device that won't connect to AWS IoT Core? Work outward: ping for basic reachability, ip a to confirm the interface has a valid IP, ss -tuln to check local port binding, and tcpdump if the TLS handshake itself is failing — this ordering isolates the failure layer by layer instead of guessing.
Remote Access & File Transfer Commands
ssh — The Backbone of Headless Device Management
Everything above assumes you can get onto the device in the first place. ssh is that connection — and for production fleets, it should always use key-based authentication rather than passwords.
ssh -i ~/.ssh/device_key.pem pi@192.168.1.42
scp / rsync — Pushing Firmware or Config Updates to Fleets
scp handles simple one-off file transfers; rsync is the better choice for syncing directories or repeatedly pushing updated configs, since it only transfers what's changed.
scp firmware_v2.1.tar.gz pi@192.168.1.42:/home/pi/updates/
rsync -avz ./configs/ pi@192.168.1.42:/etc/my-app/
Subtopic worth flagging: for production device fleets, disable password auth entirely and provision devices with unique SSH key pairs tied to your PKI/X.509 identity scheme — the same principle you'd apply to device certificates applies to shell access.
Hardware & Device Interaction Commands
dmesg — Diagnosing USB/Sensor Detection Issues at Boot
dmesg prints the kernel ring buffer — the running log of what the kernel has detected and initialized since boot. It's the first place to look when a USB sensor, serial adapter, or peripheral isn't showing up.
dmesg | tail -20
dmesg | grep -i usb
lsusb / lsblk — Enumerating Connected Peripherals and Storage
lsusb lists every USB device the system currently sees; lsblk lists block storage devices and partitions — both essential when you're trying to confirm hardware is even recognized before debugging software.
lsusb
lsblk
i2cdetect / gpio — Bus-Level and Pin-Level Hardware Debugging
For direct sensor communication, i2cdetect scans an I2C bus and reports which addresses respond — the fastest way to confirm a sensor is wired and powered correctly before writing a single line of driver code. GPIO utilities (varying by platform — gpio on some boards, gpioget/gpioset via libgpiod on others) let you read or toggle pins directly from the shell.
i2cdetect -y 1 # scan I2C bus 1 for connected devices
gpioget gpiochip0 17 # read the state of GPIO pin 17 Quick answer: How do I check if my sensor is detected on the I2C bus? Run i2cdetect -y <bus_number> — if the sensor's expected address doesn't appear in the output grid, the issue is wiring or power, not your code.
Permissions, Security & Package Management Commands
chmod / chown — Fixing Permission Errors on Device Certificates and Keys
Device certificates and private keys used for X.509-based authentication to AWS IoT Core or similar platforms need tightly scoped permissions — a common source of "permission denied" errors when a device app starts.
chmod 600 device-private.pem.key
chown iot-app:iot-app device-private.pem.key
sudo — Privilege Scoping on Production Devices
Running everything as root on a production device is a common but avoidable security gap. Use sudo deliberately, and configure sudoers to grant only the specific privileges a service account actually needs.
sudo -l # list what the current user is permitted to run with sudo
apt / pip — Managing Dependencies on Debian-Based Edge OSes
Most Debian-derived edge distributions (Raspberry Pi OS, Ubuntu Core) use apt for system packages and pip for Python dependencies — both of which should be pinned to specific versions in production images rather than left to float.
sudo apt update && sudo apt install -y mosquitto-clients
pip install --break-system-packages awsiotsdk
Subtopic worth flagging: apply least-privilege principles to where device credentials live on disk — a 600-permission key file owned by a dedicated, non-root service account closes off one of the more common IoT security gaps.
Putting It Together — A Sample IoT Debugging Workflow
Here's how several of these commands chain together in a scenario every IoT developer eventually hits: a device has stopped publishing telemetry.
sshinto the device — confirm you can still reach it at all.systemctl status my-edge-app.service— is the application process even running?journalctl -u my-edge-app.service -n 100— if it crashed, what was the last error before it died?pingthe IoT endpoint — rule out a basic network outage.ip a— confirm the active interface still has a valid IP (Wi-Fi drops are a common culprit).ss -tuln | grep 8883— confirm the MQTT client is bound and attempting a connection.tcpdump -i eth0 port 8883— if the connection is attempted but failing, inspect the TLS handshake itself.free -handdf -h— rule out the app being OOM-killed or blocked by a full disk.
Eight commands, run roughly in that order, will isolate the failure layer — application, network, or resource exhaustion — in a few minutes rather than a few hours of guessing.
Frequently Asked Questions
What Linux distro is best for IoT development?
It depends on the constraint you're optimizing for. Raspberry Pi OS is the easiest starting point for prototyping. Yocto and Buildroot give you a fully custom, minimal image for production hardware where every megabyte of flash matters. Ubuntu Core is worth considering for fleets that benefit from snap-based, transactional updates.
Do I need to know Linux for embedded/IoT engineering?
For anything beyond bare-metal RTOS work, yes. The moment your device runs embedded Linux — which most gateways, edge AI boards, and connected industrial devices do — command-line fluency is how you'll do the majority of your debugging, provisioning, and deployment work.
What's the difference between Linux commands for IoT vs. general DevOps?
Significant overlap (ssh, systemctl, journalctl, networking tools), but IoT work adds a hardware-interaction layer DevOps rarely touches — dmesg, i2cdetect, lsusb, and GPIO utilities — because you're debugging physical sensors and peripherals, not just services in a data center.
Can these commands be scripted for fleet-wide device management?
Yes — this is exactly where tools like Ansible, cron jobs, or a custom fleet-management script earn their keep. Wrapping commands like df -h, systemctl status, or certificate expiry checks into a scheduled script run across a fleet turns manual debugging into proactive monitoring.
How do I practice these commands without physical hardware?
Docker containers running a Debian or Alpine base cover most file, process, and networking commands. For hardware-specific ones like i2cdetect or GPIO tools, simulators like QEMU (for full embedded Linux images) or Wokwi (for microcontroller-level I2C/GPIO simulation) let you practice without a physical board.
Conclusion
These 20 commands won't make you a Linux expert overnight, but they cover the workflows that come up again and again in IoT development: navigating a headless filesystem, watching resource usage on constrained hardware, managing services, diagnosing the network stack from ping down to packet level, and talking directly to sensors over I2C or GPIO. Bookmark this as a reference, and the next time a device goes quiet in the field, you'll know exactly which command to reach for first.
Join the conversation