← Embedded Track
Embedded Systems & IoT · Course 05

Embedded Linux
& Device Services

Make Raspberry Pi and Linux-based embedded devices behave like products: services, logs, boot behavior, update scripts, health checks, and deployment routines.

Start Course 05 ← Course 04 Course 06 →
12Modules
systemdServices + boot
Device agentsLogs, updates, health
CapstoneDevice agent
Course Progress
0%
Module 01

Embedded Linux Mindset

Linux turns a board into a maintainable device. This module explains why products need predictable boot, services, logs, and recovery behavior.

🧱 Product expectations
  • A device should restart cleanly after power loss.
  • A useful app should start without a human opening a terminal.
  • Logs should explain what happened after failure.
  • Configuration should be separated from code.
  • Updates should be repeatable and reversible.
🧪 Lab: Service Inventory

Pick one Pi project and list every process, port, file, and command required to keep it running.

🧠 Quick Check
What makes Linux device work different from running a script manually?
Module 02

Filesystem, Users & Permissions

Learners understand where apps, logs, configs, and data belong, then practice safe ownership and permissions.

📁 Useful locations
  • /home holds user files and prototypes.
  • /etc holds system configuration.
  • /var/log holds logs.
  • /opt is a good place for self-contained apps.
  • File ownership affects whether services can read or write.
ls -la
whoami
groups
sudo chown -R $USER:$USER ~/my-device
chmod +x run.sh
🧪 Lab: Clean App Folder

Create an app folder with src, config, logs, and README files. Set permissions so your user can edit it safely.

🧠 Quick Check
Why does file ownership matter for services?
Module 03

systemd Services

A systemd unit lets a device app start on boot, restart on failure, and become visible to standard Linux admin tools.

⚙️ Unit file basics
  • Description explains the service purpose.
  • ExecStart points to the command.
  • Restart controls failure behavior.
  • WantedBy makes the service start during boot.
[Unit]
Description=TeqStudy Device Agent
After=network-online.target

[Service]
WorkingDirectory=/opt/teq-device
ExecStart=/usr/bin/python3 /opt/teq-device/agent.py
Restart=always
User=pi

[Install]
WantedBy=multi-user.target
🧪 Lab: Create a Service

Turn a simple Python script into a systemd service, enable it, reboot, and confirm it starts automatically.

🧠 Quick Check
What is the main job of systemd in this course?
Module 04

Logs & journalctl

When a device fails overnight, logs are the evidence. Learners inspect service status and read logs with journalctl.

🧾 Debugging commands
  • systemctl status shows current service state.
  • journalctl shows service history.
  • Timestamps reveal when failure happened.
  • Clear log messages make support easier.
systemctl status teq-device --no-pager
journalctl -u teq-device -n 80 --no-pager
journalctl -u teq-device -f
🧪 Lab: Log a Failure

Intentionally break a service path, restart the service, then use journalctl to explain exactly what failed.

🧠 Quick Check
Why are logs more useful than guessing?
Module 05

Python Device Agent

A device agent is a small background program that reads state, makes decisions, and reports health.

🐍 Agent loop pattern
  • Initialize configuration.
  • Connect to required resources.
  • Run a controlled loop.
  • Handle exceptions without crashing silently.
  • Log status regularly.
import logging, time

logging.basicConfig(level=logging.INFO)

while True:
    try:
        logging.info("device heartbeat")
        time.sleep(10)
    except Exception as exc:
        logging.exception("agent failed: %s", exc)
        time.sleep(5)
🧪 Lab: Heartbeat Agent

Build a Python agent that writes a heartbeat every 10 seconds and runs under systemd.

🧠 Quick Check
What should a background agent do when an error occurs?
Module 06

Configuration & Secrets

Learners separate settings from code and avoid hard-coding private tokens, Wi-Fi data, and API keys in public repositories.

🔑 Config practices
  • Use config files or environment variables.
  • Keep secrets out of Git.
  • Provide example config files without real credentials.
  • Validate required settings at startup.
# .env.example
MQTT_HOST=192.168.1.10
MQTT_TOPIC=home/device/status
API_TOKEN=replace_me
🧪 Lab: Example Config

Create a .env.example file and update the README so someone else knows which settings are required.

🧠 Quick Check
Why should real secrets stay out of public code?
Module 07

Boot Behavior & Recovery

A real device needs to know what happens after power loss, network delay, and partial startup failures.

🚀 Boot questions
  • Does the app wait for the network?
  • What happens if the sensor is missing?
  • Does the dashboard start after reboot?
  • Can the device recover without keyboard and monitor?
systemctl enable teq-device
systemctl restart teq-device
systemctl is-enabled teq-device
🧪 Lab: Power Pull Test

Reboot the device three times and record whether the service starts, logs correctly, and recovers network access.

🧠 Quick Check
Why test boot behavior repeatedly?
Module 08

Update Scripts & Rollback

Learners write basic update scripts and plan what to do if a deployment breaks a device.

🔄 Update design
  • Pull or copy the new release.
  • Install dependencies repeatably.
  • Restart services in a controlled way.
  • Keep a known-good version or rollback plan.
  • Write update notes.
#!/usr/bin/env bash
set -e
cd /opt/teq-device
git pull
python3 -m pip install -r requirements.txt
sudo systemctl restart teq-device
🧪 Lab: Safe Update Script

Create an update.sh script, run it twice, and confirm the second run does not break anything.

🧠 Quick Check
What does set -e help with in a shell update script?
Module 09

Health Checks & Watchdogs

Health checks let the device tell you whether its service, network, disk, and sensors are working.

❤️ Health signals
  • Service active state.
  • Free disk space.
  • Network connectivity.
  • Recent sensor reading age.
  • Last successful API or MQTT publish.
systemctl is-active teq-device
df -h /
ping -c 1 8.8.8.8
🧪 Lab: Health Report

Write a script that prints OK or FAIL for service state, disk space, and network connectivity.

🧠 Quick Check
What should a good health check report?
Module 10

Secure Device Access

This module reinforces safe remote administration, local firewalls, least privilege, and avoiding unnecessary exposed services.

🛡️ Safer access habits
  • Use strong passwords or SSH keys.
  • Disable services you do not use.
  • Keep software updated.
  • Avoid public exposure by default.
  • Document who should access the device.
sudo systemctl list-unit-files --type=service
ss -tulpn
sudo ufw status
🧪 Lab: Service Surface Review

List listening ports and installed services. Disable anything that is unnecessary for the project.

🧠 Quick Check
What is the safest default for device services?
Module 11

Deployment Checklist

Learners turn loose instructions into a repeatable deployment checklist that someone else can follow.

📋 Checklist sections
  • Hardware requirements.
  • OS image and setup steps.
  • Install commands.
  • Configuration files.
  • Service names.
  • Admin URLs and recovery notes.
🧪 Lab: One-Page Runbook

Write a one-page runbook explaining how to install, start, stop, update, and troubleshoot the device.

🧠 Quick Check
Why write a deployment checklist?
Module 12

Capstone: Device Agent

The capstone packages everything into a Linux device agent that starts on boot, logs status, exposes a health report, and includes update and recovery notes.

🏁 Final requirements
  • Python agent runs under systemd.
  • Agent logs a heartbeat.
  • Health script reports service, disk, and network status.
  • Configuration is separated from code.
  • Update script is documented.
  • README includes install and rollback instructions.
🧪 Lab: Ship the Agent

Build the final agent, reboot-test it, intentionally break one config value, then use logs to diagnose and recover.

🧠 Quick Check
What makes the capstone product-like?