starred/ProxmoxVE

Fork 0

mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-04-25 09:15:59 +03:00

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

New issue

Closed

opened 2026-02-26 13:32:21 +03:00 by kerem · 0 comments

kerem commented

2026-02-26 13:32:21 +03:00

Owner

📋 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.

Related Issue: #1258

🛠️ 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

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>

kerem

2026-02-26 13:32:21 +03:00

closed this issue
added the
pull-request
label

kerem referenced this issue

2026-02-26 13:35:44 +03:00

[PR #3084] [MERGED] openwrt: fix typo netmask #4122

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ProxmoxVE#3084

No description provided.

Rows
Columns