Repository navigation
dependency-check [pve] #861
Description
Activity
hey guys!
first of all, amazing work!!im having a issue with this script, team, or probably is a problem between the pc and the chair
im having a clog up systemlog because fo the script, should it behave like that to be running?
during the install, no errors whatsoever
i can access the config file on the respective etc/default path but for now i want to do it in all my 3 lxc as a testam I doing something wrong?
- Please add check for existing hookscript on container/vm and prompt to replace or not.
- Prompt for location if multiple snippet storage locations are determined.
Hookscript uninstall leaves stale config entries prevents all LXCs from starting.
After running --uninstall and rebooting, all LXC containers failed to start with:
TASK ERROR: hookscript error for on pre-start: script 'local:snippets/dependency-check.sh' does not existThe uninstall process removes the hookscript file from /var/lib/vz/snippets/, but it does not remove the hookscript: line from each VM/LXC config. This leaves Proxmox referencing a non‑existent script, which blocks startup for every affected guest.
Steps to Reproduce:
- Install the dependency-check hook system (--install).
- Allow it to apply hookscript entries to existing LXCs/VMs.
- Run --uninstall.
- Reboot the Proxmox node.
- Attempt to start any LXC.
The uninstall process removes:
- /var/lib/vz/snippets/dependency-check.sh
- systemd units
- applicator scripts
…but does not remove the hookscript reference from:
- /etc/pve/lxc/.conf
- /etc/pve/qemu-server/.conf
Seems Proxmox refuses to start any guest when the hookscript path is invalid.
Additional Notes:
Before uninstalling, the watcher service caused heavy pct and pvestatd activity, repeatedly calling:- pct config
- pct status
This created high CPU usage and elevated system temperatures. Removing the hookscript entries resolved both the startup failures and the excessive CPU load.
THIS SHIT CAN'T BE DELETED VIA --uninstall COMMAND!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Using even more exclamation marks makes you seem even more credible
Using even more exclamation marks makes you seem even more credible
Using even more useless words makes you seem even more useless
This was a great idea. I don't believe it was the correct approach.
The script has been around for almost a year and I’ve never received any feedback. So I don’t know whether anyone has actually used it or not.
to be completely honest, I've been using it on a cluster
there's a lot of issues on that use case scenario but, for one node only, it was flawless
as another person stated, using "--uninstall" does nothing for some reason
when looking at the logs at the time I found an alternative, that I do not record what I did at that moment now LOL, and removed manually from across all of my nodes
but it is a great dependecy check ✅
I used it for about 2.5 months. Played around with it, got to know it. I left some feedback. I really needed something like this, and I can't believe no one else jumped on board.
I did some research of my own and found there is another technique to do the same thing without all the calls to pct config/stats. Which is what really opted me out.
From what I gathered, the dependency‑check hookscript tried to delay VM/LXC startup until another host or port was available, but doing this at the Proxmox node level caused heavy pct/pvestatd load and created high system usage.
From my research, I found the Proxmox‑friendly solution is to handle dependency waits inside the guest using a small systemd “wait‑for‑dependency” unit. This would create a one-shot service at the LXC/VM level, not node level, therefore eliminating the need to poll anything pct related.
I haven't tried it in practice yet. I intend too.
Name of the Script
dependency-check
📋 Script Details
✍️ Description
For me, it has always been a pain to ensure that a VM or container is only started when another VM or service is up.
Start delays are extremely flaky and inefficient. This script helps solve that.
It's a hookscript that runs on pre-start and waits for all referenced storages to be active. Additionally, it supports tags such as dep_ping_<hostname_or_ip> to wait until a IP is reachable and dep_tcp_<hostname_or_ip>_ to wait until a TCP port is open.
#792