Something wrong with the deploy script?

[G0nz0uk]

Hello,

So I'm doing a fresh install from here.

git clone https://github.com/initMAX/zabbix-mcp-server.git
cd zabbix-mcp-server
sudo ./deploy/install.sh
sudo nano /etc/zabbix-mcp/config.toml   # fill in your Zabbix URL + API token
sudo systemctl start zabbix-mcp-server
sudo systemctl enable zabbix-mcp-server

The /etc/zabbix-mcp/config.toml doesn't exist after

ls /etc/zabbix-mcp/
assets  tls

I tried running the install script again:

./install.sh
>>> === Zabbix MCP Server - Installation ===

>>> Using python3.12 (Python 3.12.3)
>>> Creating directories...
 ⠋  Upgrading piproot@svr-zabmcp:/home/zabbix_admin/zabbix-mcp-server/deploy# ls /etc/zabbix-mcp/
assets  tls

I'm trying to follow this: https://www.youtube.com/watch?v=ZXClAcTwgys

Thanks

[hermanekt]

Hi @G0nz0uk, thanks for the detailed report - you helped catch two real bugs.

Root cause: the installer's spinner function (spin() in deploy/install.sh) was swallowing background command failures. When pip install failed, wait "$pid" returned non-zero and set -euo pipefail aborted the script before the spinner cleanup, error message, and captured pip output could be printed - that's why you saw the spinner mid-frame followed by your bash prompt with zero diagnostics. So pip was almost certainly failing, you just had no way to see why.

On top of that, cp config.example.toml /etc/zabbix-mcp/config.toml was called after install_package, so a failing pip left you with empty /etc/zabbix-mcp/{assets,tls} and no config to edit either.

Both fixed in 824bafc on main:

1. spin() now uses wait "$pid" || exit_code=$? so set -e is suppressed and the real exit code is captured. Failing commands now print a red >>> Foo - failed (exit N) and dump the captured stdout/stderr between --- command output --- markers.
2. cp config.toml moved before install_package, so the config file is always in place even if pip dies.

Please pull and re-run:

cd zabbix-mcp-server
git pull
sudo ./deploy/install.sh install

The new installer will either succeed, or it will print exactly why pip install is failing on svr-zabmcp (probably DNS, proxy, or no internet to pypi.org). Paste that error output here and we'll help you get it running.

Tested across Ubuntu 24.04, Debian 12, AlmaLinux 9, RHEL 8 and Fedora before merging. Will land in v1.17.

[G0nz0uk]

That ran on a clean install, the only step I had to add at the start which you might want to add or check if it exists is:

apt install python3.12-venv

[hermanekt]

Quick follow-up @G0nz0uk - both fixes from this thread are now shipped and released, so you do not need to run off a branch anymore:

• Your original installer fix (spinner hiding errors + cp config.toml happening after install_package) went out in v1.17 on 2026-04-08.
• Yesterday we also released v1.18 with three more installer / container-side improvements triggered by a separate report in #13: auto first-run admin password for container deployments (printed to docker logs / podman logs), custom report templates now persist across container restarts, and a new --check-config CLI flag for offline config validation without starting the server. Plus a pre-existing bug in tests/installer/run_all.sh that was silently aborting the full 18-distro matrix after the first distro.

To get the new code:

cd zabbix-mcp-server
git fetch origin && git reset --hard origin/main    # or: git checkout v1.18
sudo ./deploy/install.sh update

On the next run, the installer either succeeds cleanly or prints exactly why pip is failing on svr-zabmcp between --- command output --- markers. If it is still broken after the upgrade, paste that error output here and we will help you get it running. Most common causes at this point are DNS / corporate proxy / no outbound internet reaching pypi.org, and the new spinner output will make whichever one it is obvious.

If you happen to be running via podman-compose instead of the bash installer, the container side got a lot better in v1.18 - the full context is in my latest reply on #13 if you want it.

[hermanekt]

Closing this as resolved - the original installer bug shipped in v1.17 (824bafc) and follow-up installer hygiene improvements landed in v1.18 (#13) and v1.30 (#43). If a fresh install ever fails again, please open a new discussion with the install log so we can chase the new failure mode separately. Thanks for the original report - it caught two real bugs at once.