Reader setup
Before you apply
- A completed ViciBox Express lab from the previous lesson, powered on and reachable
- Root or sudo access on that lab host, since asterisk -rx needs it
- No production system — this tour is written for the disposable lab you built in this curriculum
- Expected result
- You can list the lab's detached screen sessions, ask Asterisk directly about its own uptime and channel count, and confirm MariaDB and Asterisk are both active, using only read-only commands.
- Before making changes
- Every command in this lesson only reads status. Run it on the disposable lab from the ViciBox Express lesson, never against a system taking real calls.
Why tour the host at all
A working Admin login proves the web server answered a request. It does not prove Asterisk is healthy, that the database is reachable, or that the background processes VICIdial depends on are still running. Those live below the browser, on the host itself.
This lesson is a walkthrough of a lab you already built: the ViciBox Express install from the previous lesson. Every command below reads status only. The goal is a habit — when something looks wrong later, you check the host directly instead of guessing from a web page.
Reading a host directly is a transferable skill, not a ViciBox-specific trick. The same three questions apply anywhere you administer a system: which processes are supposed to be running, does the software you rely on actually answer when asked directly, and are the services underneath it active. This tour asks all three questions of one lab, in order, so the habit sticks before you ever need it under pressure.
- Which processes should be running on a healthy Express lab
- Whether Asterisk answers a direct question, not just a web page load
- Whether the database service underneath is active
Find the screen sessions astguiclient runs
ViciBox keeps its dialer-control processes running inside detached `screen` sessions rather than as ordinary background services. A detached session keeps running after you log out, which is exactly what a call-control process needs — nobody has to stay logged in for the dialer to keep working.
`screen -ls` opens with a `There are screens on:` line, lists one line per session in the form `PID.name` alongside a state such as `(Detached)`, and ends with a line counting the sockets it found. Detached means no terminal is currently attached; it does not prove the program inside the session is healthy. Compare the session names with the lab’s expected process list, then use the direct service checks below.
- Before you use it
- Run this on the ViciBox Express lab using the account that owns the dialer sessions, as confirmed by the lab administrator. It lists sessions and does not attach to them or start anything.
screen -lsCaptured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- Expect roughly a dozen detached sessions with astguiclient-style names — the exact count depends on your build's configuration and uptime, so treat any specific number as a rough expectation, not a pass/fail threshold.
- Stop if
- If the list is empty or unexpectedly short, first confirm the host, session-owning account and screen socket context with the administrator. A different account may not see the dialer sessions. Then check the expected processes and the direct Asterisk and MariaDB results; do not restart anything blindly.
Steps and result3 steps
Read actual root SSH results for screen sessions, Asterisk status and supporting units.
Observed read-only result12 root screen sessions were detached; Asterisk reported zero active calls; MariaDB was active and the vicidial unit enabled.
Read the captured terminal transcript
Read the chapter notes
- Root screen listing: 12 detached sessions, visible in the root socket context.
Read-only captured command and output; rendered for this replay.
- Asterisk answered directly: zero active channels and calls at capture.
Read-only captured command and output; rendered for this replay.
- MariaDB was active and the vicidial unit enabled.
Read-only captured command and output; rendered for this replay.
November 4, 2026 · ViciBox 12 · SVN 4037. Root SSH context. Screen visibility depends on the account and socket directory. Rendered actual SSH capture using xterm.js; paced still frames, not a live terminal recording. SSH client warning omitted from captured output. Use fullscreen to read the terminal output.
View a still screenshot
Recorded lab terminal: screen sessions
Open to enlarge
Capture details
Read-only observation, not a completed call or routing test. Display trims blank space; enlargement opens the complete original. Removed local SSH client post-quantum negotiation warning from stderr; command stdout preserved.- The socket count on the closing line
- Whether each session reports (Detached) rather than (Attached) or (Dead)
- Any name pattern you do not recognize, to look up before your next visit
What actually runs inside them
On this build, the sessions carry real names, not generic labels. ASTupdate runs `AST_update_AMI2.pl` and ASTlisten runs `AST_manager_listen_AMI2.pl`. ASTsend runs `AST_manager_send.pl`, which delivers the AMI actions VICIdial queues in its own manager table. ASTVDauto runs `AST_VDauto_dial.pl`, which places the auto-dial calls, and ASTVDadapt runs `AST_VDadapt.pl`, which adjusts the dial level for the ADAPT dialing methods. ASTVDadFILL runs `AST_VDauto_dial_FILL.pl` and ASTVDremote runs `AST_VDremote_agents.pl`. ASTfastlog runs `FastAGI_log.pl`, the FastAGI server on port 4577 that the dialplan's `AGI(agi://127.0.0.1:4577/call_log)` lines call. ASTConfUpdater runs `AST_conf_update_screen.pl`, and ASTemail runs `VD_email_inbound.pl`. Two further sessions round out a typical list: `asterisk` itself, and one `astshell` session named for the timestamp it was opened.
Asterisk handles the calls. Which additional processes are required depends on the features enabled on the installation; compare this list with your lab’s documented configuration. Housekeeping is deliberately not one more screen session: root's own crontab runs it instead, on its own schedule, separate from anything these processes start themselves. On the documented lab, a scheduled job checks for missing sessions; do not assume another installation has the same recovery schedule.
You do not need to memorize every daemon's name to use this curriculum. The point of this section is narrower: knowing that this layer exists means a paused campaign or a stuck hopper is sometimes a process problem, not a configuration problem, and the two need different fixes — restarting the wrong thing wastes time, and editing a campaign setting to fix a dead process wastes more.
Ask Asterisk directly, not just the web page
Asterisk's `-rx` flag stands for remote execute: it connects briefly to the already-running Asterisk instance, runs the single command you give it in quotes, prints the result, and disconnects. No interactive console session is left open behind you, which makes it safe to use for a quick health read without risking an accidental follow-up command.
`core show uptime` prints two lines: the system's uptime since it started, and separately the time since its last configuration reload — the two can differ if you reloaded Asterisk without a full restart. `core show channels count` prints a short block of counts, including active channels and active calls; a channel is one leg of a call, so these numbers reflect calls in progress, not agents logged in or leads loaded.
- Before you use it
- Run both lines on the lab host. Neither places a call, changes a configuration file, or restarts the service.
asterisk -rx 'core show uptime'asterisk -rx 'core show channels count'Captured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- The first command reports how long Asterisk has been running since its last restart; the second reports zero active channels and zero active calls on an idle lab with no agents logged in and no test call in progress.
- Stop if
- A connection-refused or permission error here means the Asterisk service itself is not running or you lack CLI access — confirm with the supporting-services check below before assuming a deeper fault.
Recorded lab terminal: asterisk status
Open to enlarge
Capture details
Read-only observation, not a completed call or routing test. Display trims blank space; enlargement opens the complete original. Removed local SSH client post-quantum negotiation warning from stderr; command stdout preserved.- The reported uptime, to notice if Asterisk restarted recently without your knowledge
- The active-channels and active-calls counts — zero on both is the expected, healthy result with no agent logged in and no call in progress
Confirm the supporting services are active
VICIdial's processes depend on MariaDB, so a health tour is incomplete without checking it. Asterisk itself is not checked here — on this build, Asterisk is not a systemd service at all; it runs inside the `asterisk` screen session you already found, and `systemctl is-active asterisk` reports `inactive` even while Asterisk is fully healthy. The previous section's direct question to Asterisk is the real health check; systemd's opinion of it is not.
ViciBox instead ships a `vicidial` systemd unit that launches Asterisk and the dialer screens at boot. Its enabled/disabled state tells you whether it starts automatically on the next reboot — it does not describe whether anything is running right now. Do not read `is-active vicidial` as a health signal either: on our lab it reports `inactive` while Asterisk and every dialer screen are running.
- Before you use it
- Run this on the lab host. Neither command starts, stops, or restarts anything; both only report state.
systemctl is-active mariadbsystemctl is-enabled vicidialCaptured demo response · 2026-09-23 21:35 UTC. Any filtering, hidden values or test-only data are identified in the capture label. Select Replay transcript to read the recorded output.
- Success looks like
- The first line should report active — that is a genuine health signal for the database. The second line typically reports enabled, confirming the vicidial unit will run at the next boot; it says nothing about whether anything is running at this moment.
- Stop if
- If MariaDB does not report active, record the result and ask the lab administrator to investigate; Admin may show an error or fail to load data. Do not treat vicidial reporting inactive as a fault by itself — cross-check with the previous section's direct Asterisk query before concluding anything is actually down.
Recorded lab terminal: services
Open to enlarge
Capture details
Read-only observation, not a completed call or routing test. Display trims blank space; enlargement opens the complete original. Removed local SSH client post-quantum negotiation warning from stderr; command stdout preserved.Ready for the next lesson
Continue to the filesystem tour next: the same lab, seen through the files and directories astguiclient reads and writes instead of through its running processes. Keep the session count and service states you recorded here — the filesystem tour occasionally refers back to what a healthy process layer looks like when it explains where each process's own files live.
If anything in this lesson's four checks surprised you — an unexpectedly low session count, an uptime shorter than you expected, a channel or call count above zero on an idle lab, or MariaDB reporting anything other than active — resolve that before moving on. The filesystem tour assumes the processes underneath are healthy; it does not re-check them.
Checks and sources
What was checked
- Every command here is read-only and its expected result is described as a range or a status, never a fixed value, because lab uptime and configuration vary.
- Reviewed read-only SSH observations were added from the ViciBox 12 / SVN 4037 demo on November 4, 2026. Captures show point-in-time state, not successful calling, routing, audio, API writes or recovery.