Last week’s article, Command-Line Deep Dive: Mastering Shell and Utilities, covered the essential Linux tools every homelab administrator should know. You explored the shell, navigated filesystems, and gained hands-on experience with commands for inspecting, manipulating, and automating your system. These foundational skills set the stage for the next level of control: managing the processes and services that keep your system running reliably.

Now that you can navigate the shell confidently, it’s time to focus on the processes and services that form the backbone of your Linux environment. Each running process—from a background daemon to a foreground application—contributes to the living ecosystem of your homelab. Monitoring, controlling, and configuring these tasks is essential for maintaining stability, performance, and reliability.

In this article, we’ll explore service management using systemd, the modern init system used by most current Linux distributions. You’ll learn how to view and control processes, configure services, and create custom unit files. Along the way, we’ll also cover legacy SysV Init scripts, which still exist in some packages, and demonstrate how systemd integrates with them seamlessly.

By the end, you’ll be equipped to take full control of your services: start and stop them, enable them at boot, monitor logs, and configure automatic restart policies. We’ll illustrate these concepts with a practical example: running a Synchronet BBS instance in your homelab.

Understanding Processes

A process is any running instance of a program on your system. Each process has a unique process ID (PID) and may spawn child processes, forming a hierarchy rooted at PID 1—the init system. Understanding this hierarchy helps you monitor system health, troubleshoot issues, and manage runaway tasks effectively.

Processes can consume varying amounts of CPU and memory, respond to signals, and run with different privileges. Being able to inspect and control them provides direct insight into how your homelab operates in real time.

Common commands to inspect processes:

**ps aux**        # List all processes with details
**top**           # Interactive CPU/memory monitor
**htop**          # Enhanced interactive monitor with sorting/filtering
**pstree**        # Visualize the process hierarchy
**pgrep <name>**  # Search for processes by name

Managing processes:

**kill <PID>**       # Send a signal to a specific process
**pkill <name>**     # Kill processes by name
**killall <name>**   # Kill all processes with a given name
**nice -n 10 <cmd>** # Start a process with lower priority
**renice -n 5 -p <PID>** # Adjust priority of a running process

Tip: If a backup script consumes all CPU resources, terminate it gracefully:

**pkill -f backup.sh**

Monitoring resource usage is as important as controlling processes. Tools like top and htop help spot memory leaks, CPU spikes, or zombie processes that could degrade system performance. For advanced monitoring, check our Linux Monitoring and Performance Tools guide.

Pull quote: “Understanding processes gives you real-time insight into the heartbeat of your system.”

From SysV Init to systemd

Historically, Linux used SysV Init to manage services. Packages provided scripts in /etc/init.d/, and symbolic links in /etc/rc*.d/ determined which services ran at each runlevel. While functional, SysV Init started services sequentially, lacked dependency awareness, and required additional tools to monitor or restart daemons.

systemd replaced SysV Init in most modern distributions. It introduced:

• Parallel service startup for faster boot times
• Declarative unit files to define services and dependencies
• Centralized logging with journald
• Resource management with cgroups
• Timers and targets for flexible scheduling

Legacy SysV scripts still exist, but systemd manages them alongside modern units seamlessly, allowing administrators to consolidate service management.

Tip: Even if a package includes SysV scripts, you can manage it like a modern systemd service without extra setup.

For more on Linux init systems, see Understanding Linux Init Systems.

Managing Services with systemd

systemd unifies service management under a single, consistent interface. Key concepts include:

• Units: Define services, sockets, timers, or targets
• Targets: Group units, similar to runlevels
• Dependencies: Control the order services start and their relationships
• Journald: Centralized logging for all unit output

Common systemd commands:

**systemctl start <service>**       # Start a service immediately
**systemctl stop <service>**        # Stop a service immediately
**systemctl restart <service>**     # Restart a service
**systemctl reload <service>**      # Reload configuration without restarting
**systemctl enable <service>**      # Enable service at boot
**systemctl disable <service>**     # Disable service at boot
**systemctl status <service>**      # Check status and recent logs

Tip: Mastering systemctl lets you respond quickly to issues, automate service management, and maintain uptime across your homelab. For deep dives into journald and logging, see Linux Logging with systemd Journald.

Pull quote: “systemd gives you a single interface to manage processes, dependencies, and logs efficiently.”

Practical Example: Synchronet BBS Service

Let’s run the main Synchronet BBS daemon as a systemd service:

[Unit]
Description=**Synchronet BBS**
After=**network.target**
Wants=**network-online.target**
[Service]
Type=forking
User=**sbbs**
Group=**sbbs**
Environment=SBBSCTRL=/opt/sbbs/sbbs/ctrl
Environment=SBBSEXEC=/opt/sbbs/sbbs/exec
WorkingDirectory=/opt/sbbs/sbbs
ExecStart=/opt/sbbs/sbbs/exec/sbbs -d /opt/sbbs/sbbs/ctrl
Restart=always
RestartSec=5
StandardOutput=append:/var/log/sbbs/sbbs.log
StandardError=append:/var/log/sbbs/sbbs-error.log
[Install]
WantedBy=multi-user.target

Highlights:

• Runs the daemon under systemd (Type=forking)
• Least-privilege execution with User and Group
• Logs captured through StandardOutput and StandardError
• Automatic restart ensures reliability (Restart=always)
• Dependencies guarantee network availability

Enable and start the service:

**sudo systemctl daemon-reload**
**sudo systemctl enable sbbs**
**sudo systemctl start sbbs**
**sudo systemctl status sbbs**

Tip: Always reload systemd after creating or modifying unit files to ensure changes are applied.

Optional: Synchronet BBS Control Panel with tmux

You can create a separate systemd service that launches a detached tmux session with multiple panes:

• Top-left: scfg (configuration interface)
• Top-right: umonitor
• Bottom-left: events.log
• Bottom-right: sbbsecho-cron.log

Key points from the startup script (sbbscpanel.sh):

• Kill old session: bashtmux kill-session -t sbbs
• Start a detached session: bashtmux new-session -d -s sbbs
• Split the window into panes and send commands
• Enable mouse mode: bashtmux set-option -g mouse on
• Stop panel cleanly: bashtmux kill-session -t sbbs

Service definition:

[Unit]
Description=**Synchronet BBS Control Panel (tmux)**
After=network.target sbbs.service
Requires=sbbs.service
[Service]
Type=forking
User=sbbs
Group=sbbs
WorkingDirectory=/opt/sbbs/byobu
ExecStart=/opt/sbbs/byobu/sbbscpanel.sh
ExecStop=/opt/sbbs/byobu/sbbscpanel-die.sh
Restart=on-failure
StandardOutput=journal
StandardError=journal
SyslogIdentifier=sbbscpanel
[Install]
WantedBy=multi-user.target

Summary

Last week’s article introduced the essential Linux tools for homelab administrators. Building on that foundation, this article dives into processes and services, covering systemd, legacy SysV scripts, and practical examples like running a Synchronet BBS instance.

A process is any running instance of a program, each with a unique PID and potential child processes. Tools like ps, top, and htop allow administrators to inspect resource usage, manage priorities, and terminate runaway tasks. Being comfortable with these commands ensures real-time insight and helps prevent performance bottlenecks.

Service management using systemd is now standard for most distributions. Core concepts such as units, targets, dependencies, and journald logging are explained with practical examples. Readers learn how to start, stop, enable, and monitor services, and configure automatic restart policies.

To illustrate these principles, the article demonstrates running a Synchronet BBS instance as a systemd service, including an optional control panel managed via tmux. Readers also learn how to create custom service units, manage legacy scripts, and troubleshoot services effectively. Mastering these techniques gives homelab administrators full control over processes and services, ensuring a reliable, well-monitored Linux environment.

Appendix: Synchronet BBS Control Panel Scripts

Startup Script: sbbscpanel.sh

#!/bin/bash
SESSION=sbbs
# Kill old session if exists
**tmux kill-session -t $SESSION 2>/dev/null**
# Start detached tmux session
**tmux new-session -d -s $SESSION -n monitor -x 82 -y 30**
# Split panes: top 75% for monitoring, bottom 25% for logs
**tmux split-window -v -p 25 -t $SESSION:0.0**
**tmux split-window -h -t $SESSION:0.1 -l 41**
**tmux split-window -h -t $SESSION:0.0 -l 41**
**tmux set-option -g mouse on**
sleep 0.5
# Send commands to panes
**tmux send-keys -t $SESSION:0.0 "/opt/sbbs/sbbs/exec/scfg" C-m**
**tmux send-keys -t $SESSION:0.1 "/opt/sbbs/sbbs/exec/umonitor" C-m**
**tmux send-keys -t $SESSION:0.2 "tail -f /opt/sbbs/sbbs/logs/events.log" C-m**
**tmux send-keys -t $SESSION:0.3 "tail -f /opt/sbbs/sbbs/logs/sbbsecho-cron.log" C-m**

Stop Script: sbbscpanel-die.sh

#!/bin/bash
# Stop the Synchronet BBS control panel session
**tmux kill-session -t sbbs 2>/dev/null**