SVI/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-07-27 16:22:45 -04:00
Code Issues 2.6k Packages Projects Releases 10 Wiki Activity

Unbound Service Fails to Start Due to Timing Issue in Script #614

New Issue
Closed
opened 2025-11-20 04:51:01 -05:00 by saavagebueno · 8 comments
saavagebueno commented 2025-11-20 04:51:01 -05:00
Owner
Copy Link

Originally created by @Drallas on GitHub (Feb 27, 2025).

✅ Have you read and understood the above guidelines?

yes

📜 What is the name of the script you are using?

Unbound

📂 What was the exact command used to execute the script?

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/unbound.sh)"

📝 Provide a clear and concise description of the issue.

I encountered an issue with the unbound.sh script (from ct/unbound.sh) where the Unbound service fails to start during initial setup.

This happens because the script runs systemctl restart unbound (line 65) too quickly after container creation, before the network or systemd is fully initialized. Systemd retries fail with "Start request repeated too quickly," and the service remains down. Manually running systemctl start unbound after a short delay works fine.

⚙️ What settings are you using?

  • Default Settings
  • Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 12

🔄 Steps to reproduce the issue.

run the script provided..

❌ Paste the full error output (if available).

Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xeu unbound.service" for details.

🖼️ Additional context (optional).

Image Image
Originally created by @Drallas on GitHub (Feb 27, 2025). ### ✅ Have you read and understood the above guidelines? yes ### 📜 What is the name of the script you are using? Unbound ### 📂 What was the exact command used to execute the script? bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/unbound.sh)" ### 📝 Provide a clear and concise description of the issue. I encountered an issue with the unbound.sh script (from ct/unbound.sh) where the Unbound service fails to start during initial setup. This happens because the script runs systemctl restart unbound (line 65) too quickly after container creation, before the network or systemd is fully initialized. Systemd retries fail with "Start request repeated too quickly," and the service remains down. Manually running systemctl start unbound after a short delay works fine. ### ⚙️ What settings are you using? - [ ] Default Settings - [x] Advanced Settings ### 🖥️ Which Linux distribution are you using? Debian 12 ### 🔄 Steps to reproduce the issue. run the script provided.. ### ❌ Paste the full error output (if available). Job for unbound.service failed because the control process exited with error code. See "systemctl status unbound.service" and "journalctl -xeu unbound.service" for details. ### 🖼️ Additional context (optional). <img width="1087" alt="Image" src="https://github.com/user-attachments/assets/a48b975c-5f68-4184-875c-f77b291a46b6" /> <img width="885" alt="Image" src="https://github.com/user-attachments/assets/3ed89c10-9b24-4b9f-826a-ec3d28427f4f" />
saavagebueno added the bug label 2025-11-20 04:51:01 -05:00
saavagebueno commented 2025-11-20 04:51:02 -05:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Feb 27, 2025):

Image
can't reproduce the problem

@tremor021 commented on GitHub (Feb 27, 2025): ![Image](https://github.com/user-attachments/assets/ae013ca2-7845-4f5d-9add-ee3173c52683) can't reproduce the problem
saavagebueno commented 2025-11-20 04:51:02 -05:00
Author
Owner
Copy Link

@Drallas commented on GitHub (Feb 27, 2025):

I had this on two occasions; after starting the service manually, Unbound works fine!
So it might be fine for you and many others, but it's not fail proof all the time.

@Drallas commented on GitHub (Feb 27, 2025): I had this on two occasions; **after starting the service manually, Unbound works fine**! So it might be fine for you and many others, but it's not fail proof all the time.
saavagebueno commented 2025-11-20 04:51:02 -05:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Feb 27, 2025):

You have a error with corrupt template in one of the screenshots, which indicates you have issues with your host. It has nothing to do with the script, because it installs everything just fine on all my nodes, it doesn't pick when its going to break. There must be a reason why something is stopping it from working correctly, and its almost always something on the user side

If you have another node to test it on, do it.

@tremor021 commented on GitHub (Feb 27, 2025): You have a error with corrupt template in one of the screenshots, which indicates you have issues with your host. It has nothing to do with the script, because it installs everything just fine on all my nodes, it doesn't pick when its going to break. There must be a reason why something is stopping it from working correctly, and its almost always something on the user side If you have another node to test it on, do it.
saavagebueno commented 2025-11-20 04:51:02 -05:00
Author
Owner
Copy Link

@Drallas commented on GitHub (Feb 27, 2025):

You have a error with corrupt template in one of the screenshots, which indicates you have issues with your host. It has nothing to do with the script, because it installs everything just fine on all my nodes, it doesn't pick when its going to break. There must be a reason why something is stopping it from working correctly, and its almost always something on the user side

If you have another node to test it on, do it.

Template get successfully downloaded:

zstd: can't stat /var/lib/vz/template/cache/debian-12-standard_12.7-1_amd64.tar.zst
such file or directory -- ignored
Template debian-12-standard_12.7-1_amd64.tar.zst not found in storage or seems
to be corrupted. Redownloading
**Template download successful.**

Install runs normal, until the red part in the 2nd screenshot.

@Drallas commented on GitHub (Feb 27, 2025): > You have a error with corrupt template in one of the screenshots, which indicates you have issues with your host. It has nothing to do with the script, because it installs everything just fine on all my nodes, it doesn't pick when its going to break. There must be a reason why something is stopping it from working correctly, and its almost always something on the user side > > If you have another node to test it on, do it. Template get successfully downloaded: ``` zstd: can't stat /var/lib/vz/template/cache/debian-12-standard_12.7-1_amd64.tar.zst such file or directory -- ignored Template debian-12-standard_12.7-1_amd64.tar.zst not found in storage or seems to be corrupted. Redownloading **Template download successful.** ``` Install runs normal, until the red part in the 2nd screenshot.
saavagebueno commented 2025-11-20 04:51:02 -05:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Feb 27, 2025):

test again

@MickLesk commented on GitHub (Feb 27, 2025): test again
saavagebueno commented 2025-11-20 04:51:03 -05:00
Author
Owner
Copy Link

@Drallas commented on GitHub (Feb 27, 2025):

test again

Same behaviour.

@Drallas commented on GitHub (Feb 27, 2025): > test again Same behaviour.
saavagebueno commented 2025-11-20 04:51:03 -05:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Feb 27, 2025):

Then its not an Timing issue. I cant reproduce and have build in an sleep timer

@MickLesk commented on GitHub (Feb 27, 2025): Then its not an Timing issue. I cant reproduce and have build in an sleep timer
saavagebueno commented 2025-11-20 04:51:03 -05:00
Author
Owner
Copy Link

@Drallas commented on GitHub (Feb 28, 2025):

I left this here for others facing the same issue. After manually starting Unbound, it runs perfectly. This happened to me three times. My Proxmox node uses <2% CPU and <20% memory, with no issues with running lXC’s or other helper scripts. Happy to test further if there’s a code change.

@Drallas commented on GitHub (Feb 28, 2025): I left this here for others facing the same issue. After manually starting Unbound, it runs perfectly. This happened to me three times. My Proxmox node uses <2% CPU and <20% memory, with no issues with running lXC’s or other helper scripts. Happy to test further if there’s a code change.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
🛑 Failure to comply with the guidelines
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
Implemented in VED waiting push to Main
in project pipeline
invalid
investigation
json
maintenance
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/ProxmoxVE#614
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?