Debug a Linux Health Monitor

Build and repair a Bash health monitor with a systemd user service.

Introduction

30 Second Summary

When your computer slows down, useful clues are scattered across several places. Finding the cause becomes harder when those clues disappear before you can compare them.

In this project, you will build a local Bash health monitor that refreshes a text report every 15 seconds. You will use systemd to diagnose a deliberately triggered file permissions failure before recovering the service.

What You'll Build

You will watch a text report update with current machine health while a user-level service keeps running in the background.

By the end of this project, you'll have:

  • A repeatable health snapshot you can open to see current uptime, storage, memory, processes, and listening sockets.
  • A controlled failure demo that turns a missing write permission into a visible failed service.
  • A recovered service you can prove is active, enabled, and refreshing its report.
  • Secret Mission: Add a validated --interval SECONDS option that lets systemd run the monitor at a custom cadence.

Are there any prerequisites?

You need a working Lubuntu desktop with permission to use the local terminal. The lab runs entirely on your machine, so you need no cloud account or paid service.

Before We Start

First, lock in what you are about to build and why the planned failure matters. You are committing to create a local Linux health monitor that you will deliberately break, diagnose, and recover.

Prepare the Lubuntu Lab

A troubleshooting lab is useful only when every command it depends on is available. Missing utilities can make a planned experiment fail for the wrong reason.

You will verify the tools on your Lubuntu desktop before creating an isolated workspace. A systemd user manager keeps the experiment inside your account instead of changing system-wide services.

In this step, get ready to:
  • Verify every command the monitor needs.
  • Create an isolated home for the lab files.
  • Prove the full local setup is ready.
Verify the local command toolkit

The monitor will use Bash to combine several views of your machine. Checking each source now separates missing software from script bugs later.

  • Use the desktop application menu to locate Lubuntu Terminal.
  • Select Lubuntu Terminal.
  • Display the installed tool information and health data by running these checks:
bash --version
systemctl --version
nano --version
date
uptime
df "$HOME"
free
ps -e -o pid,comm,pcpu,pmem
ss -tuln

What do these checks prove?

  • The version checks confirm Bash, systemd, and GNU nano respond on this machine.
  • GNU Coreutils supplies date and df.
  • procps-ng supplies uptime, free, and ps.
  • iproute2 supplies ss for socket inspection.

✔️ Every command prints output

Good, the lab's command toolkit is ready for the monitor.

ⓧ A base utility is missing

A missing base utility can be restored from Ubuntu's distro-managed packages. This fallback installs only the utilities used by the lab.

Your terminal may ask for your local password. The package commands receive temporary administrator access on this machine.

  • Refresh Ubuntu package data by running:
sudo apt update

What does this command do?

This refreshes the package information from your configured Ubuntu repositories. The next command can then request the distro-managed utility packages.

  • Install the required base utility packages by running:
sudo apt install coreutils procps iproute2

What did you install?

  • The coreutils package provides the file and system-data commands used by the report.
  • The procps package provides the memory and process commands.
  • The iproute2 package provides the socket inspection command.
  • Rerun the missing utility check from the earlier command list.

You should now see normal output from the command that was missing.

Package installation failed?

  • Confirm that your Lubuntu machine has a working internet connection.
  • Check the terminal output for the package name that could not be retrieved.

Help me diagnose this package installation failure. Share the missing command name and terminal output with the NextWork community.

Create an isolated workspace

An isolated workspace gives the monitor script, generated reports, and user unit predictable homes. Everything stays under your account's home directory.

  • Create the project and user-unit directories by running this command:
mkdir -p "$HOME/linux-health-lab/bin" "$HOME/linux-health-lab/reports" "$HOME/.config/systemd/user"

How is the workspace organized?

  • The $HOME/linux-health-lab/bin directory will hold the monitor script.
  • The $HOME/linux-health-lab/reports directory will hold the latest health snapshot.
  • The $HOME/.config/systemd/user directory is where systemd loads user-level unit files.
  • The parent-directory option creates any missing folders without failing when a folder already exists.
Prove the lab is ready

A user-level systemd manager controls the units for your account. Its response proves the service layer is available before you add the monitor unit.

Before you run the final check, picture the two outputs that would prove your user manager and workspace are ready.

  • Run the end-to-end readiness check:
systemctl --user list-units --type=service --no-pager
ls -ld "$HOME/linux-health-lab" "$HOME/.config/systemd/user"

What should you see?

The first command prints a service-unit table from your user manager. This confirms that systemd accepts commands for your local account.

The second command prints entries for $HOME/linux-health-lab and $HOME/.config/systemd/user. This confirms that both workspace locations exist.

That is the foundation in place. Your verified tools and isolated workspace are ready for the monitor.

User manager or path missing?

  • Confirm that you are still signed into the local Lubuntu desktop.
  • Retry the user-manager check from Lubuntu Terminal in your own desktop session.
  • Rerun the directory-creation command if either workspace path is missing.
  • Help me diagnose my Lubuntu lab readiness check.

Your command toolkit is verified. Next, you will turn those data sources into a one-shot Linux health report.

Build a One-Shot Health Report

Your lab directories and command-line utilities are ready from the previous step. Now you can turn those commands into a reusable Bash health snapshot.

Before systemd manages the monitor, the script needs to prove that every Linux data source works on its own. A one-shot run gives you that evidence in a report you can inspect.

In this step, get ready to:
  • Create the Bash script that gathers system health data.
  • Run the script once to generate the latest report.
  • Inspect the report to trace each section to its source command.
Write the health monitor script

GNU nano gives you a terminal editor for building the script inside the existing $HOME/linux-health-lab/bin directory. The script starts with paths and settings that every later section uses.

  • Switch back to the Lubuntu Terminal from earlier.
  • Open the script in GNU nano by running this command:
nano "$HOME/linux-health-lab/bin/health-monitor.sh"

What Does This Command Do?

The nano command opens $HOME/linux-health-lab/bin/health-monitor.sh in the terminal editor. GNU nano creates the script file when you save it.

  • Place the cursor on the first line in GNU nano.
  • Paste the script setup below:
#!/bin/bash
set -u

LAB_DIR="${HOME}/linux-health-lab"
REPORT_DIR="${LAB_DIR}/reports"
REPORT_FILE="${REPORT_DIR}/latest.txt"
INTERVAL_SECONDS=15

How Does the Setup Work?

  • The first line tells the operating system to use Bash for the script.
  • The set -u setting makes an unset variable produce an error.
  • The LAB_DIR and REPORT_DIR variables keep the workspace paths in one place.
  • The REPORT_FILE variable points to the report that the script updates.
  • The INTERVAL_SECONDS value prepares the repeating mode to wait for 15 seconds between reports.
  • Press ^O to write the current file.
  • Press Enter to confirm the existing path.

GNU nano's status area confirms that the file was written.

Having Trouble Saving the Setup?

  • Check that GNU nano still shows health-monitor.sh as the current file.
  • Compare the four variable names with the code block above if the paths look different.

Help me check the setup section of my Bash health monitor.

The generate_report() function collects each command's output into one snapshot. Its write check also gives a future service failure a clear exit status.

  • Move the cursor to the blank line beneath INTERVAL_SECONDS=15.
  • Paste the report function below:
generate_report() {
  if ! {
    printf 'Linux Health Snapshot\n'
    printf 'Generated: '
    date

    printf '\n== Uptime and load ==\n'
    uptime

    printf '\n== Home filesystem ==\n'
    df "$HOME"

    printf '\n== Memory ==\n'
    free

    printf '\n== Processes ==\n'
    ps -e -o pid,comm,pcpu,pmem

    printf '\n== Listening TCP/UDP sockets ==\n'
    ss -tuln
  } > "$REPORT_FILE"; then
    printf 'ERROR: cannot write %s\n' "$REPORT_FILE" >&2
    return 1
  fi

  printf 'Report updated: %s\n' "$REPORT_FILE"
}

What Does the Function Do?

  • The generate_report() function groups the health commands into one operation.
  • The redirection after the closing brace sends the complete snapshot to REPORT_FILE.
  • A failed write prints ERROR: cannot write to standard error.
  • A successful write prints Report updated: with the report path.
  • Press ^O to write the updated file.
  • Press Enter to confirm the existing path.

GNU nano's status area confirms that the function is saved in the script.

Does the Function Look Incomplete?

  • Check that the function starts with generate_report() {.
  • Check that the final closing brace appears beneath the success message.
  • Compare every quote around $REPORT_FILE with the code block above.

Help me find a missing brace or quote in my generate_report function.

The final block chooses between a one-shot report and the repeating monitor loop. It also rejects unsupported arguments with exit status 2.

  • Move the cursor to the blank line beneath the closing brace of generate_report().
  • Paste the control flow below:
if [ "${1:-}" = "--once" ]; then
  generate_report
  exit $?
fi

if [ "$#" -gt 0 ]; then
  printf 'Usage: %s [--once]\n' "$0" >&2
  exit 2
fi

while true; do
  generate_report || exit 1
  sleep "$INTERVAL_SECONDS"
done

How Does the Script Choose a Mode?

  • The --once option calls generate_report() once.
  • The first exit passes the report's exit status back to the terminal.
  • An unsupported argument prints the accepted usage and exits with status 2.
  • No argument starts the repeating loop with the configured interval.
  • Press ^O to write the completed script.
  • Press Enter to confirm the existing path.

GNU nano's status area confirms that the completed script was written.

  • Press ^X to return to the Lubuntu Terminal.

Did GNU Nano Ask to Save Again?

  • Choose to save the modified buffer if GNU nano reports unsaved changes.
  • Confirm $HOME/linux-health-lab/bin/health-monitor.sh as the destination.

Help me save and exit GNU nano without losing my health monitor script.

✔️ Awesome, I've got everything!

Your script now contains the path settings, report function, argument checks, and repeating loop. Make sure the file is saved before running it.

ⓧ I'd like to double check the full code

#!/bin/bash
set -u

LAB_DIR="${HOME}/linux-health-lab"
REPORT_DIR="${LAB_DIR}/reports"
REPORT_FILE="${REPORT_DIR}/latest.txt"
INTERVAL_SECONDS=15

generate_report() {
  if ! {
    printf 'Linux Health Snapshot\n'
    printf 'Generated: '
    date

    printf '\n== Uptime and load ==\n'
    uptime

    printf '\n== Home filesystem ==\n'
    df "$HOME"

    printf '\n== Memory ==\n'
    free

    printf '\n== Processes ==\n'
    ps -e -o pid,comm,pcpu,pmem

    printf '\n== Listening TCP/UDP sockets ==\n'
    ss -tuln
  } > "$REPORT_FILE"; then
    printf 'ERROR: cannot write %s\n' "$REPORT_FILE" >&2
    return 1
  fi

  printf 'Report updated: %s\n' "$REPORT_FILE"
}

if [ "${1:-}" = "--once" ]; then
  generate_report
  exit $?
fi

if [ "$#" -gt 0 ]; then
  printf 'Usage: %s [--once]\n' "$0" >&2
  exit 2
fi

while true; do
  generate_report || exit 1
  sleep "$INTERVAL_SECONDS"
done

How to Use This Reference

Compare this reference with your saved health-monitor.sh file from top to bottom. Every line shown here matches the complete script for this step.

Run the one-shot report

The --once option gives you a small test loop. The script writes one snapshot before returning control to the terminal.

  • Before you run it, predict whether the script stops after one report or keeps running.
  • Generate one health snapshot by running this command:
bash "$HOME/linux-health-lab/bin/health-monitor.sh" --once

What Does This Command Do?

The bash command runs the saved script with its one-shot option. The script calls generate_report() before returning the report's exit status.

You'll see Report updated: followed by the path to latest.txt.

Good progress. Your monitor can now collect a complete snapshot with one command.

Did the Script Report an Error?

  • Check that the script path ends with bin/health-monitor.sh.
  • Compare the line number from any Bash error with the full-code reference above.
  • Check that every quote and closing brace matches the reference.

Help me diagnose the error from my one-shot Bash health report.

Inspect the complete snapshot

The terminal confirmation proves that a write occurred. The saved report proves that each health command contributed its data.

  • Before you display it, predict which health headings the report should contain.
  • Display the generated report by running this command:
cat "$HOME/linux-health-lab/reports/latest.txt"

What Does This Command Do?

The cat command reads latest.txt and prints the complete snapshot in your terminal. This makes every section available for inspection.

You'll see a complete Linux Health Snapshot with generated system data beneath each heading.

How Does Each Section Get Its Data?

  • The Generated: line uses date to show when the snapshot was created.
  • The == Uptime and load == section uses uptime to show runtime and load information.
  • The == Home filesystem == section uses df to show storage usage for your home filesystem.
  • The == Memory == section uses free to show memory totals and usage.
  • The == Processes == section uses ps to show process IDs, commands, CPU usage, and memory usage.
  • The == Listening TCP/UDP sockets == section uses ss to show listening network sockets.

Your one-shot monitor now proves that every data source works. Next, you'll place it under systemd and observe how a service records a real operational failure.

Launch a Service That Fails on Purpose

Your one-shot Bash script already proves that every health source can produce a complete report. Now you will hand that script to systemd.

Interactive success can disappear when file permissions change. This step creates a safe user-level failure that you can investigate without touching system-wide services.

In this step, get ready to:
  • Prepare a report directory without owner write access.
  • Create a user-level systemd unit for the existing monitor.
  • Capture the planned failed state after the user manager starts the unit.
Remove write access from the report directory

The owner write bit controls whether your user can create a file inside a directory. The script itself stays unchanged.

  • Prepare the controlled permission fault by running these commands:
rm -f "$HOME/linux-health-lab/reports/latest.txt"
chmod u-w "$HOME/linux-health-lab/reports"
ls -ld "$HOME/linux-health-lab/reports"

What do these commands change?

  • The rm command removes the previous snapshot. The next report must be created from scratch.
  • The chmod command removes the directory owner's write bit with u-w.
  • The ls command displays the directory's symbolic permission mode.

In the directory listing, the owner's permission group no longer includes w. The missing bit is the controlled fault that the service now encounters.

Directory mode unchanged?

  • Confirm that the path ends with linux-health-lab/reports.
  • Check that the chmod mode is u-w.

Ask for help interpreting the directory mode.

Create the user service unit

A user unit lets your own service manager run the monitor without creating a root-owned service. Its definition belongs in the existing $HOME/.config/systemd/user directory from earlier.

  • Open $HOME/.config/systemd/user/linux-health-monitor.service in Nano by running this command:
nano "$HOME/.config/systemd/user/linux-health-monitor.service"

Why Use This File Location?

The nano command opens the named unit file inside the existing user-unit directory.

This path belongs to your current user's service manager. It keeps the lab isolated from system-wide units.

  • Paste this service definition into Nano:
[Unit]
Description=Linux Health Monitor Lab

[Service]
Type=simple
ExecStart=/bin/bash %h/linux-health-lab/bin/health-monitor.sh

[Install]
WantedBy=default.target

What Does This Unit Define?

  • The [Unit] section gives the service its description.
  • The Type=simple setting makes the foreground process the service's main process.
  • The ExecStart directive launches the existing monitor with /bin/bash.
  • The %h specifier resolves to your home directory.
  • The WantedBy=default.target setting records the unit's future enablement target.
  • Press ^O in Nano to write the file.
  • Press Enter to confirm the current file name.
  • Press ^X to return to the terminal.

✔️ Awesome, I've got everything!

Your unit file is saved in the user-unit directory.

ⓧ I'd like to double check the full code

[Unit]
Description=Linux Health Monitor Lab

[Service]
Type=simple
ExecStart=/bin/bash %h/linux-health-lab/bin/health-monitor.sh

[Install]
WantedBy=default.target

Unable to Save the Unit?

  • Confirm that the file name ends with linux-health-monitor.service.
  • Confirm that Nano opened the existing $HOME/.config/systemd/user directory.

Ask for help saving the user unit.

Load the service and observe the failure

systemd keeps a loaded version of each unit definition. The daemon-reload action makes the user manager read the new file before start launches it.

Before you run these commands, do you expect the service to keep running or stop when it tries to create the report?

  • Load the new unit and attempt its first start by running these commands:
systemctl --user daemon-reload
systemctl --user start linux-health-monitor.service

The Failed Start Is Intentional

  • The daemon-reload command loads the new definition into your user manager.
  • The start command launches the monitor as your current user.
  • The script reaches its report redirection without directory write permission.
  • The script emits ERROR: cannot write.
  • Exit status 1 makes systemd record the unit as failed.

The start attempt has produced evidence. Before you check the unit state, what single state do you expect systemd to report?

  • Check the recorded service state by running this command:
systemctl --user is-failed linux-health-monitor.service

What Should You See?

You should see failed. This proves that systemd launched the unit and received a nonzero exit status.

The user manager preserves that failed state for the diagnosis in the next step.

You've captured the controlled incident. Your user manager now holds a repeatable failed state with the script's own write error behind it.

Service State Not Failed?

  • Confirm that ExecStart matches the saved unit definition exactly.
  • Confirm that the owner's permission group still lacks w in the directory listing from the first substep.
  • Confirm that the unit file is named linux-health-monitor.service.

Ask for help tracing the unexpected service state.

The failure is now visible and preserved. Next up, you'll correlate service status, journal evidence, and directory mode before making the smallest repair.

Diagnose and Repair the Permission Fault

Your health monitor already proved that a working Bash script can still fail when systemd runs it under changed filesystem conditions. The recorded failed state is the symptom you will investigate.

A failed state alone cannot identify the root cause. Status output shows how the service stopped.

The journal connects that exit to the script's write error. The directory's file permissions confirm the cause before the smallest fix.

In this step, get ready to:
  • Correlate the failed service state with its recent log evidence.
  • Identify the missing owner write bit in the directory mode.
  • Apply the narrow permission repair before restarting the service.
Inspect the failure evidence

An exit status records whether a command succeeded. The service log adds the script message that explains this failure.

Before you inspect the status, do you expect it to contain the root cause or only the process outcome?

  • Inspect the current service status by running this command:
systemctl --user status linux-health-monitor.service --no-pager

What Does the Status Prove?

The status view confirms that linux-health-monitor.service is failed. It also identifies the Bash process that exited.

The nonzero exit result explains the recorded failed state. The script message supplies the root-cause clue.

  • Read the recent unit logs by running this command:
journalctl --user-unit linux-health-monitor.service --since "5 minutes ago" --no-pager

What Does the Journal Add?

The journal query limits the evidence to the last five minutes. You should find the script's ERROR: cannot write message.

The message comes from generate_report. The service ended with exit status 1 because report creation failed.

Missing Recent Journal Evidence?

  • Use the recent log lines in the status output if your explicit journal query has no entries.
  • Confirm that the unit name is exactly linux-health-monitor.service.

Help me compare my service status with the journal evidence.

Restore owner write permission

Directory mode shows which permission bits are available to the owner. The missing owner write bit matches the report creation failure.

  • Inspect the current directory mode by running this command:
ls -ld "$HOME/linux-health-lab/reports"

What Does the Directory Mode Show?

The long directory listing exposes the permission string for reports. The owner section lacks write access.

This missing bit matches the script's inability to create latest.txt.

Permission changes can feel risky. This repair restores write access only for the directory owner.

  • Restore owner write permission by running this command:
chmod u+w "$HOME/linux-health-lab/reports"

What Does This Permission Change Do?

The symbolic mode u+w targets the owner. It adds write permission to the report directory.

The group permissions stay unchanged. The permissions for other users also stay unchanged.

  • Confirm the changed directory mode by running this command:
ls -ld "$HOME/linux-health-lab/reports"

What Confirms the Repair?

The owner's write bit is present again. This visible mode change confirms the permission repair.

Owner Write Permission Still Missing?

  • Make sure the command targets $HOME/linux-health-lab/reports.
  • Check that you used u+w in the permission command.

Help me restore owner write permission on the report directory.

Clear the failure and restart the service

Systemd records a failed state after a service exits unsuccessfully. reset-failed clears that record before the retry.

  • Clear the recorded failed state by running this command:
systemctl --user reset-failed linux-health-monitor.service

What Does Resetting the Failure Do?

The reset-failed command clears the unit's recorded failed state. The repaired directory is ready for the next start.

  • Restart the repaired service by running this command:
systemctl --user restart linux-health-monitor.service

What Happens During the Restart?

The restart runs the unit's ExecStart command again. The script can now create latest.txt.

The foreground loop keeps the service running after the first report is written.

Before you check the recovered unit, do you expect systemd to report it as active or failed?

  • Check the current service state by running this command:
systemctl --user is-active linux-health-monitor.service

What Should the Service Report?

You should see active. This confirms that the restarted Bash process remains under systemd management.

  • Print the regenerated health report by running this command:
cat "$HOME/linux-health-lab/reports/latest.txt"

What Proves the Recovery?

The cat command prints the report recreated by the running service. You should see headings for uptime, filesystem, memory, processes, and listening sockets.

The recreated file proves that the repaired directory accepts writes from the user service.

Service Still Failing?

  • Return to the directory mode check to confirm the owner write bit is present.
  • Review the latest service status for a new process failure.
  • Compare the latest journal message with the earlier write error.

Help me diagnose why the repaired service still fails.

That is the incident recovered. You traced the failed state to one permission bit before restoring the service.

Your monitor is healthy again. Next, you'll prove systemd owns its process while the report keeps refreshing.

Enable and Verify the Monitor

Your repaired monitor is active again. Now you need evidence that the recovery survives beyond a single successful restart.

You will identify the Bash process managed by systemd. You will then confirm the report refreshes before checking future-login enablement.

In this step, get ready to:
  • Enable the user service for future logins.
  • Identify the Bash process managed by systemd.
  • Confirm the report completes another refresh cycle.
Configure future-login startup

The service is active for your current session. An enablement link beneath default.target tells the user manager to include it at future logins.

  • Create the enablement link by running this command:
systemctl --user enable linux-health-monitor.service

What does this command do?

Enabling creates the link described by the unit's [Install] section. It leaves the already-running service untouched.

  • Check the recorded enablement state by running this command:
systemctl --user is-enabled linux-health-monitor.service

What does this check prove?

This check reads the service's enablement state. It confirms whether the link for future logins exists.

You should see enabled. That confirms your repaired monitor is prepared for your next login.

Still Seeing a Different State?

  • Confirm the unit file still contains WantedBy=default.target beneath [Install].
  • Repeat the enable command after confirming the unit file.

Help me diagnose why my user service is not enabled.

Identify the managed process

A running service needs a foreground process for systemd to supervise. The status view connects your unit to the Bash process executing the monitor script.

  • Inspect the service and its managed process by running this command:
systemctl --user status linux-health-monitor.service --no-pager

What Does the Status Show?

The status view confirms the unit's current runtime state. It also identifies the foreground process managed by systemd.

You should see the service listed as active. You should also see a Bash process running %h/linux-health-lab/bin/health-monitor.sh.

Cannot Find the Bash Process?

  • Confirm the status output still lists the service as active.
  • Inspect the unit's command if the displayed process does not reference health-monitor.sh.

Help me understand the process shown in my service status.

Prove the report keeps refreshing

The script uses a 15-second interval between updates. Waiting 16 seconds crosses one complete interval before you inspect the report again.

  • Let one complete refresh interval pass by running this command:
sleep 16

Why Wait 16 Seconds?

The monitor sleeps for 15 seconds after each report. The extra second gives the next update time to finish writing the file.

Before you inspect the report, do you expect its generated time to match the earlier snapshot or show a newer refresh?

  • Reveal the refreshed report by running this command:
cat "$HOME/linux-health-lab/reports/latest.txt"

What Does This Check Prove?

The cat command prints the report currently stored on disk. The monitor overwrites that file after every completed interval.

You should see a newer generated time. Farther down, you should see == Processes == followed by current process rows.

You should also see == Listening TCP/UDP sockets == followed by current listening sockets.

Enablement and runtime are separate service states. Before the final checks, which state do you expect each command to report?

  • Confirm both service states by running these commands:
systemctl --user is-enabled linux-health-monitor.service
systemctl --user is-active linux-health-monitor.service

What Do the Two States Mean?

  • The first check confirms whether the service is configured for future logins.
  • The second check confirms whether the service is running now.

You should see enabled from the first check. You should see active from the second check.

Report or State Check Failed?

  • Confirm the service status if the report's generated time did not change.
  • Inspect the current service status if the final runtime check does not show active.
  • Repeat the enable command if the final enablement check does not show enabled.

Help me diagnose my monitor's final verification results.

You have completed the operational proof: systemd is running your monitor as a managed user service.

The report now refreshes every 15 seconds. The enablement link prepares the service for your next login.

Secret mission

Make the Sampling Interval Configurable

Your monitor currently refreshes on one fixed schedule. Add a validated interval option so the service can request a five-second cadence without changing the script's default.

Clean Up Your Resources

Clean Up Your Resources

The monitor runs entirely on your Lubuntu machine, so there are no ongoing financial costs. Choose whether to keep it running, pause it for later, or delete it entirely.

Resources you used:

  • The active and enabled systemd user service linux-health-monitor.service, including its enablement symlink.
  • The user unit file at $HOME/.config/systemd/user/linux-health-monitor.service.
  • The $HOME/linux-health-lab workspace, including the Bash script and its latest report.

Keep everything running

No action needed. Choose this if you still want a health report that refreshes every five seconds.

  • The linux-health-monitor.service service stays active.
  • The report at $HOME/linux-health-lab/reports/latest.txt continues receiving current health data.
  • The service stays enabled for your next login.

Pause - I'll come back to this later

Pausing frees the local CPU time used by the monitor. Your script and service configuration remain ready for later.

  • Pause the monitor by running this command:
systemctl --user stop linux-health-monitor.service

What does this command do?

This stops the active user service. Its enablement symlink stays in place, so the service can start at your next login.

The monitor is now inactive. Its script, report, unit file, and enablement setting remain on your machine.

Delete - I don't want to use this again

Removal is permanent, so save any report you want to keep first. Your Lubuntu installation and system-wide services stay untouched.

  • Shut down the enabled monitor by running this command:
systemctl --user disable --now linux-health-monitor.service

What gets disabled?

The --now option stops the running service. Disabling the unit removes its enablement symlink.

  • Remove the workspace and unit file by running this command:
rm -rf "$HOME/linux-health-lab" "$HOME/.config/systemd/user/linux-health-monitor.service"

What gets removed?

This deletes the $HOME/linux-health-lab workspace. It also deletes the $HOME/.config/systemd/user/linux-health-monitor.service unit file.

  • Refresh the user manager after deleting the unit file by running this command:
systemctl --user daemon-reload

Why reload the manager?

This makes the user manager reload its available unit definitions after the service file is removed. Your health-monitor resources are now cleaned up.

Nice Work!

Nice Work!

Excellent work. Your Bash health monitor now runs as an active user-level systemd service that is ready for your next login.

You've learned how to:

  • Built a Linux health monitor that turns time, load, storage, memory, process, and socket data into a refreshed report.
  • Used redirection and exit status to expose a write failure that systemd could record.
  • Diagnosed a planned service incident with status output, journal evidence, and symbolic permissions. Restored owner write access to recover the service.
  • Secret Mission: Added a validated sampling interval that lets systemd refresh the report every five seconds.

Ready to quiz yourself?