Skip to main content

Troubleshooting

Common problems and how to fix them.

"Daemon is not running"​

Symptom: hali daemon status says the daemon isn't running, or hali pull can't seed after download.

Fix (user mode)​

hali daemon start

Fix (service mode)​

# Linux
sudo systemctl start halid
sudo systemctl status halid

# Windows
hali service start
hali service status

If the service won't start​

Check the logs:

# Linux
journalctl -u halid -n 50 --no-pager

# Windows
# Check %ProgramData%\Hali\logs\hali.log

Common causes:

  • Port conflict (another process using the daemon's port)
  • Permission denied on data directory
  • Config file is invalid JSON

"Cannot connect to daemon" / IPC errors​

Symptom: CLI commands fail with connection errors even though the daemon is running.

Linux​

# Check if your user is in the hali group
id -nG

# If not:
sudo usermod -aG hali "$USER"
newgrp hali
sudo systemctl restart halid

# Check socket permissions
ls -l /run/hali

If daemon.addr is missing:

# Stop and restart the daemon
hali daemon stop
hali daemon start

Windows​

  • Ensure hali.exe and halid.exe are in the same directory
  • Check %ProgramData%\Hali\daemon.addr exists
  • Restart the service: hali service restart

"Download failed from Hugging Face"​

Symptom: hali pull fails with a network error during download.

Causes and fixes​

  1. HuggingFace is down or rate-limiting — wait and retry. hali does exponential backoff.
  2. Your network blocks HuggingFace — check your firewall/proxy.
  3. The repo or file was deleted — try a different quantization or repo.

Workaround​

If the model exists on your LAN, use LAN-only pull:

hali network seen        # Check if any LAN peer has it
hali network pull <id>   # Download from LAN only

"LAN peers not visible"​

Symptom: hali daemon status shows no entries in LAN AVAILABLE, even though you know another machine has the model.

Step-by-step diagnosis​

1. Confirm the sender is actually seeding:

On the machine that has the model:

hali daemon status

Look for seeding in the SEEDING section. If it says hashing, the torrent metadata isn't ready yet — wait 1–2 minutes.

2. Check HMAC settings (if using authenticated mode):

Both machines must have matching lan_hmac_enabled and lan_hmac_shared_secret:

hali config show | grep lan

3. Check the firewall:

# Linux — ufw
sudo ufw status | grep 4269
sudo ufw allow 4269/udp

# Linux — firewalld
sudo firewall-cmd --list-ports
sudo firewall-cmd --add-port=4269/udp --permanent
sudo firewall-cmd --reload

# Windows
Get-NetFirewallRule | Where-Object { $_.LocalPort -eq 4269 }
New-NetFirewallRule -DisplayName "hali LAN" -Direction Inbound -Protocol UDP -LocalPort 4269 -Action Allow
New-NetFirewallRule -DisplayName "hali LAN Out" -Direction Outbound -Protocol UDP -LocalPort 4269 -Action Allow

4. Verify packets are arriving:

# Linux
sudo tcpdump -ni any udp port 4269

If you see packets but hali doesn't show them, check HMAC settings. If you don't see packets at all:

  • Both machines must be on the same L2 segment (same VLAN / broadcast domain)
  • Multicast must be enabled on the network (some routers/switches block it)
  • Virtual adapters (VPN, Hyper-V, Docker) can interfere — hali handles this automatically, but it's worth checking

5. Check L2 connectivity:

# Both machines should be on the same subnet
ip addr show    # Linux
ipconfig        # Windows

"Firewall blocking hali"​

Windows Defender Firewall​

# Allow hali binaries
New-NetFirewallRule -DisplayName "hali CLI" -Direction Outbound -Program "C:\Program Files\Hali\hali.exe" -Action Allow
New-NetFirewallRule -DisplayName "hali Daemon" -Direction Inbound -Program "C:\Program Files\Hali\halid.exe" -Action Allow

# Allow LAN multicast discovery
New-NetFirewallRule -DisplayName "hali LAN In" -Direction Inbound -Protocol UDP -LocalPort 4269 -Action Allow
New-NetFirewallRule -DisplayName "hali LAN Out" -Direction Outbound -Protocol UDP -LocalPort 4269 -Action Allow

Linux (ufw)​

sudo ufw allow 4269/udp
sudo ufw allow out 4269/udp

Linux (firewalld)​

sudo firewall-cmd --add-port=4269/udp --permanent
sudo firewall-cmd --reload

"Service won't start after install"​

Linux (systemd)​

# Check the unit file
systemctl cat halid

# Check for errors
journalctl -u halid -n 50 --no-pager

# Check directory permissions
ls -ld /var/lib/hali /var/log/hali /run/hali
# All should be owned by hali:hali with mode 2775

Fix permissions if needed:

sudo chown -R hali:hali /var/lib/hali /var/log/hali /run/hali
sudo chmod 2775 /var/lib/hali /var/log/hali /run/hali
sudo systemctl restart halid

Windows (SCM)​

# Check service status
sc query HaliDaemon

# Check event viewer for errors
# Look for "HaliDaemon" in Windows Logs → Application

# Verify the binary exists
Test-Path "C:\Program Files\Hali\halid.exe"

If the service immediately stops, check:

  • Config file is valid JSON at %ProgramData%\Hali\config.json
  • hali.exe and halid.exe are in the same directory
  • No other process is using the daemon's ports

"Export to Ollama doesn't work"​

# Check if Ollama is detected
hali runtime list

# Check the custom path
hali config show | grep ollama

# Set it manually if auto-detection fails
hali config set ollama_models_dir /path/to/.ollama/models

# Re-export
hali export ollama mistral:7b:instruct:q4_k_m

After export, verify:

ollama list    # Should show the model

If Ollama can't find the model, check that the manifest file was created:

ls ~/.ollama/models/manifests/

"Model is corrupted or incomplete"​

Symptom: Ollama or LM Studio fails to load the model.

  1. Check the file integrity:
# Linux/macOS — compare file size with metadata.json
ls -lh ~/.hali/cache/<base>/<size>-<variant>/<quant>/model.gguf
cat ~/.hali/cache/<base>/<size>-<variant>/<quant>/metadata.json | grep size
  1. If sizes don't match, the download was interrupted. Delete and re-download:
rm -rf ~/.hali/cache/<base>/<size>-<variant>/<quant>/
hali pull <model-id>
  1. The daemon's piece hashing also serves as an integrity check — if pieces don't hash correctly, the status will show hashing (never reaching seeding).

"Config file is broken"​

If config.json is corrupted, delete it — hali will regenerate it with defaults on next run:

# Linux
rm ~/.hali/config.json
# or
sudo rm /var/lib/hali/config.json
sudo systemctl restart halid

# Windows
Remove-Item "$env:ProgramData\Hali\config.json"
hali service restart

"Too many models, disk full"​

hali doesn't have built-in cache eviction yet (v0.1). To free space:

# See what's taking space
du -sh ~/.hali/cache/*/*/    # Linux/macOS

# Remove a model
rm -rf ~/.hali/cache/<base>/<size>-<variant>/<quant>/

# Remove the torrent file too
rm ~/.hali/torrents/<infohash>.torrent

# Restart daemon so it stops announcing the removed model
hali service restart

On Windows:

Get-ChildItem "$env:ProgramData\Hali\models" -Recurse | Measure-Object -Property Length -Sum
Remove-Item -Recurse "$env:ProgramData\Hali\models\<base>\<size>-<variant>\<quant>\"
hali service restart

Getting more help​

If you're stuck:

  • Enable debug logging: hali config set debug true && hali service restart
  • Check the logs: journalctl -u halid -n 200 --no-pager (Linux) or %ProgramData%\Hali\logs\hali.log (Windows)
  • Run hali config show — verify your settings
  • Run hali network status — check network capabilities
  • File an issue on GitHub with:
    • Your OS and hali version (hali --version)
    • Debug logs from the daemon
    • The command you ran and the error output