vicigeeksimple guides
Browse
Infrastructure

Running your system · Start here · foundations

Inspect Linux services and logs for VICIdial

Use systemctl and journalctl to inspect the affected service and incident window without restarting it.

Start the guide
By Vicigeek Editorial DeskStep-by-step guide2 minute readUpdated November 4, 2026

01 / 03

1. Identify the host and service

  1. Run hostname and date -Is; compare the host with the incident inventory.
  2. Run systemctl list-units --type=service --state=running and locate the exact service name used on this host.
  3. Run systemctl status SERVICE --no-pager, substituting that name.
Before you use it
Confirm that these are the service names on your host.
Lab web and database services
systemctl is-active apache2 mariadb
Evidence · Recorded ViciBox 12 lab · SVN 4037 · read-only inspection

Captured demo response · 2026-11-04T08:36:24.024456Z. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.

Command output line: systemctl is-active apache2 mariadb
active
active
Success looks like
The lab returned active for both services at 08:36 UTC on November 4, 2026.
Stop if
If a unit is inactive or unknown, inspect its exact name and status before taking action.

Observed web and database service states

Open to enlarge
Rendered lab command showing apache2 and mariadb active.
Rendered transcript of the exact read-only command executed on the ViciBox 12 lab, SVN 4037, 2026-11-04.
Capture detailsThis inspection does not establish a completed call or restore.

You should seeActive indicates systemd's current unit state, not proof that the application works. A missing unit may have another name or may not be managed by systemd.

02 / 03

2. Inspect the incident window

  1. For the lab web service, run journalctl -u apache2 --since '30 minutes ago' --no-pager. Replace apache2 with the exact unit found on your host; output and incident times may differ.
  2. Compare timestamps with the incident and note repeated errors, exit status and dependencies.
  3. Inspect application-specific logs only where the service owner identifies them; avoid copying credentials or customer data.

You should seeAn error near the incident is a lead to investigate, not automatically the root cause. An empty journal can mean the application logs elsewhere.

03 / 03

3. Check the application

  1. From an approved client run curl --fail --show-error --head https://YOUR_HOSTNAME/ with the actual HTTPS host, then compare the response with the web service status. A response does not establish login or call audio.
  2. If the service is failed, capture a redacted status and incident time for the owner.
  3. Do not restart or change the service until the owner approves a maintenance action.

You should seeService health and application behavior should be checked separately.

Checks and sources

What was checked

  • Both samples here only observe: `systemctl status` and `journalctl` never start, stop, enable or restart a unit.

Primary references

Sources

  1. systemctl manualsystemd · accessed November 4, 2026
  2. journalctl manualsystemd · accessed November 4, 2026