SVI/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-05-13 03:32:10 -04:00
Code Issues 2.6k Packages Projects Releases 10 Wiki Activity

[PR #1265] [MERGED] Check lxc maxkeys #2918

New Issue
Closed
opened 2025-11-20 05:32:31 -05:00 by saavagebueno · 0 comments
saavagebueno commented 2025-11-20 05:32:31 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/community-scripts/ProxmoxVE/pull/1265
Author: @cricalix
Created: 1/5/2025
Status: ✅ Merged
Merged: 1/6/2025
Merged by: @MickLesk

Base: dev_maxkeys ← Head: check-lxc-maxkeys

📝 Commits (2)

  • 0cb6274 Detect when cryptographic maxkeys or maxbytes is approached, providing guidance
  • c127a09 Fix path to sysctl file

📊 Changes

1 file changed (+40 additions, -0 deletions)

View changed files

📝 misc/build.func (+40 -0)

📄 Description

✍️ Description

The Linux kernel has an allocation of space for storing cryptographic keys - this allocation is measured in both counts and bytes. Root has a distinct limit from regular users. When the UID used by Proxmox to run containers reaches either limit, the container will fail to start, or encounter other problems.

The limits are available in /proc, as well as the usage on a per-user basis.

This PR adds a new check function to the build.func library, and calls the function in install_script after the other check functions.

The check function does some simple integer threshold calculation to detect when either limit is close to being breached, and then provides guidance on how to resolve the problem. I am assuming that a file in /etc/sysctl/conf.d will not be touched by Proxmox upgrades (versus modifying the sysctl.conf file, which dpkg will probably clobber).

The recommended value is a simple doubling of what's present, since anything else would require calling bc to do the math and then dancing with printf to throw away floating point values.

The OP in #1258 encountered this with a mere 40 containers running.

My testing shows that creating a container uses a varying number of keys.

  • debian.sh 27 keys
  • ubuntu.sh: 30 keys
  • alpine.sh: 1 key
  • docker.sh: 32 keys

At a guess, docker containers will use even more keys if more than one docker image is running in the container.

🛠️ Type of Change

Please check the relevant options:

  • Bug fix (non-breaking change that resolves an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change unexpectedly)
  • New script (a fully functional and thoroughly tested script or set of scripts)

✅ Prerequisites

The following steps must be completed for the pull request to be considered:

  • Self-review performed (I have reviewed my code to ensure it follows established patterns and conventions.)
  • Testing performed (I have thoroughly tested my changes and verified expected functionality.)
  • Documentation updated (I have updated any relevant documentation)

📋 Additional Information (optional)

I extracted the core logic to a standalone shell script, and override the values detected by reading the data out of /proc. Both messages were triggered as expected.

root@pve:~# bash  foo.sh
  ✖  Kernel key limits problem (count) detected.
  ✖   Your PVE node is close to the key limit of 200; this will cause problems when starting containers.
  ✖   Add or update /etc/sysctl/conf.d/98-community-scripts.conf, setting kernel.keys.maxkeys=400

  ✖  Kernel key limits problem (bytes) detected.
  ✖   Your PVE node is close to the key bytes limit of 3000; this will cause problems when starting containers.
  ✖   Add or update /etc/sysctl/conf.d/98-community-scripts.conf, setting kernel.keys.maxbytes=6000

You can pick values other than the suggested ones. After creating or updating the recommended 
configuration file, run   service procps force-reload   and retry this script.

I then copied the branch over to the pve node, updated debian.sh to directly source build.func from the filesystem instead of via curl, set the maxkeys to 100 and
image

Finally, I created the file based on the instructions, ran the command as documented, and maxkeys in /proc shows the new value I picked (3000).

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/community-scripts/ProxmoxVE/pull/1265 **Author:** [@cricalix](https://github.com/cricalix) **Created:** 1/5/2025 **Status:** ✅ Merged **Merged:** 1/6/2025 **Merged by:** [@MickLesk](https://github.com/MickLesk) **Base:** `dev_maxkeys` ← **Head:** `check-lxc-maxkeys` --- ### 📝 Commits (2) - [`0cb6274`](https://github.com/community-scripts/ProxmoxVE/commit/0cb6274f4e517b77b6c7d90920997ebfaa81962b) Detect when cryptographic maxkeys or maxbytes is approached, providing guidance - [`c127a09`](https://github.com/community-scripts/ProxmoxVE/commit/c127a0928e18cf67840c5ab6bced8c4328150b7c) Fix path to sysctl file ### 📊 Changes **1 file changed** (+40 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `misc/build.func` (+40 -0) </details> ### 📄 Description ## ✍️ Description The Linux kernel has an allocation of space for storing cryptographic keys - this allocation is measured in both counts and bytes. Root has a distinct limit from regular users. When the UID used by Proxmox to run containers reaches either limit, the container will fail to start, or encounter other problems. The limits are available in /proc, as well as the usage on a per-user basis. This PR adds a new `check` function to the `build.func` library, and calls the function in `install_script` after the other `check` functions. The check function does some simple integer threshold calculation to detect when either limit is close to being breached, and then provides guidance on how to resolve the problem. I am assuming that a file in /etc/sysctl/conf.d will not be touched by Proxmox upgrades (versus modifying the sysctl.conf file, which dpkg will probably clobber). The recommended value is a simple doubling of what's present, since anything else would require calling `bc` to do the math and then dancing with printf to throw away floating point values. The OP in #1258 encountered this with a mere 40 containers running. My testing shows that creating a container uses a varying number of keys. * debian.sh 27 keys * ubuntu.sh: 30 keys * alpine.sh: 1 key * docker.sh: 32 keys At a guess, docker containers will use even more keys if more than one docker image is running in the container. - - - - Related Issue: #1258 --- ## 🛠️ Type of Change Please check the relevant options: - [ ] Bug fix (non-breaking change that resolves an issue) - [X] New feature (non-breaking change that adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change unexpectedly) - [ ] New script (a fully functional and thoroughly tested script or set of scripts) --- ## ✅ Prerequisites The following steps must be completed for the pull request to be considered: - [X] Self-review performed (I have reviewed my code to ensure it follows established patterns and conventions.) - [X] Testing performed (I have thoroughly tested my changes and verified expected functionality.) - [ ] ~Documentation updated (I have updated any relevant documentation)~ --- ## 📋 Additional Information (optional) I extracted the core logic to a standalone shell script, and override the values detected by reading the data out of /proc. Both messages were triggered as expected. ``` root@pve:~# bash foo.sh ✖ Kernel key limits problem (count) detected. ✖ Your PVE node is close to the key limit of 200; this will cause problems when starting containers. ✖ Add or update /etc/sysctl/conf.d/98-community-scripts.conf, setting kernel.keys.maxkeys=400 ✖ Kernel key limits problem (bytes) detected. ✖ Your PVE node is close to the key bytes limit of 3000; this will cause problems when starting containers. ✖ Add or update /etc/sysctl/conf.d/98-community-scripts.conf, setting kernel.keys.maxbytes=6000 You can pick values other than the suggested ones. After creating or updating the recommended configuration file, run service procps force-reload and retry this script. ``` I then copied the branch over to the pve node, updated debian.sh to directly source build.func from the filesystem instead of via curl, set the maxkeys to 100 and ![image](https://github.com/user-attachments/assets/9f67cb09-0d7d-446a-ae6d-c0071da56e91) Finally, I created the file based on the instructions, ran the command as documented, and maxkeys in /proc shows the new value I picked (3000). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
saavagebueno added the pull-request label 2025-11-20 05:32:31 -05:00
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 pull-request
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#2918
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?