Inside a running ViciBox lab: processes, screens and Asterisk

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. A detached state is the healthy one here: it means the session is running unattended, with no terminal currently attached to it, which is exactly how a background dialer-control process should look on a lab nobody is actively working inside.

• 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

screen -ls

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.

None of these accepts a call by itself — Asterisk does that — but VICIdial's dialing behavior depends on all of them staying up. 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. That same crontab restarts a missing screen session within a minute, so a single dead session is often self-healing before you would ever notice it from the outside.

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.

• 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

asterisk -rx 'core show uptime'asterisk -rx 'core show channels count'

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.

systemctl is-active mariadbsystemctl is-enabled vicidial

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.