v-update-sys-queue process guard breaks with hestiacp-pluginable

[jmdv-es]

[LLM generated issue]

When hestiacp-pluginable is installed, backups scheduled via GUI or cron never execute. The backup.pipe queue accumulates entries that are never consumed. The GUI shows "a backup is already running" but no backup process exists.

HestiaCP version: 1.9.4
OS: Debian 12 (bookworm) aarch64
Plugin: hestiacp-pluginable v2.0.4

Root cause
The process guard in v-update-sys-queue (around lines 37-43) counts running instances using:

b_task=$(ps auxf | grep -v "grep" | grep "$BIN/v-update-sys-queue backup")
b_task=$(echo "$b_task" | grep -v sudo | wc -l)
if [ "$b_task" -gt 2 ] || [ "$d_task" -gt 2 ]; then
  exit
fi

With hestiacp-pluginable installed, every v-* command is intercepted by /etc/hestiacp/hooks/local.conf, which runs php pluginable.php and then re-invokes the original script via proc_open with bin_actions=1.
This creates a process tree with 4-5 entries all matching the grep pattern:

1. Parent shell
2. Original intercepted v-update-sys-queue backup
3. PHP pluginable.php child
4. proc_open re-invocation with bin_actions=1

The count always exceeds the threshold of 2, so the guard exits before processing the backup pipe.

Steps to reproduce

1. Install hestiacp-pluginable (https://github.com/nickvdyck/hestiacp-pluginable)
2. Schedule a backup via GUI or wait for cron
3. Observe that backup.pipe entries are never consumed
4. Verify with: ps auxf | grep v-update-sys-queue shows nested process tree

Expected behavior
Backups should execute regardless of the pluginable hook system.

Workaround
Replace the ps auxf | grep | wc -l process guard with a PID-based lock file:

LOCK_DIR="$HESTIA/data/queue"
if [ "$queue" = "backup" ] || [ "$queue" = "dns" ]; then
  LOCK_FILE="$LOCK_DIR/$queue.lock"
  if [ -f "$LOCK_FILE" ]; then
    LOCK_PID=$(cat "$LOCK_FILE" 2>/dev/null)
    if [ -n "$LOCK_PID" ] && kill -0 "$LOCK_PID" 2>/dev/null; then
      exit
    fi
    rm -f "$LOCK_FILE"
  fi
  echo $$ > "$LOCK_FILE"
  trap "rm -f '$LOCK_FILE'" EXIT
fi

Additional context
The ps auxf approach for process guarding is fragile in general — any wrapper, hook system, or shell nesting that puts v-update-sys-queue in the command line of parent processes will inflate the count. A lock file mechanism is more robust.

Thank you.

[Steveorevo]

This work around could suffice, however the pluginable project is attempting to make as little modifications to HestiaCP core as possible. I wonder if it would be possible to copy or alias just the v-update-sys-queue script under a different name to a unique one prior to re-invocation, and thus prevent inadvertently matching the grep?