From 97ce1c4e4de7b4a6a0c1bb58f4a9f37462f25261 Mon Sep 17 00:00:00 2001 From: doc-claw-bot Date: Tue, 23 Jun 2026 08:31:17 +0000 Subject: [PATCH 1/4] docs: clarify no-sudo limits behavior --- tiup/tiup-cluster-no-sudo-mode.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index ddd5c857f6a36..222c8555cca0f 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -40,6 +40,8 @@ This document takes the `tidb` user as an example. EOF ``` + Because TiDB services in no-sudo mode are managed by the per-user `systemd` instance (`user@.service`), the limits in `/etc/security/limits.conf` are applied when `user@.service` starts. If you change `/etc/security/limits.conf` after `user@.service` is already running, restart `user@.service` or reboot the target machine before you deploy or restart TiDB services. Otherwise, the new limits might not take effect for the TiDB services. + 2. Start the `systemd user` mode for the `tidb` user on each target machine. This step is required and do not skip it. 1. Use the `tidb` user to set the `XDG_RUNTIME_DIR` environment variable. @@ -51,11 +53,13 @@ This document takes the `tidb` user as an example. source ~/.bashrc.d/systemd ``` - 2. Use the `root` user to start the user service. + 2. Use the `root` user to start the user service. If `user@${uid}.service` is already running after you update `/etc/security/limits.conf`, run `systemctl restart user@${uid}.service` to apply the new limits. ```shell $ uid=$(id -u tidb) # Get the ID of the tidb user $ systemctl start user@${uid}.service + # If user@${uid}.service is already running after you update /etc/security/limits.conf, run: + $ systemctl restart user@${uid}.service $ systemctl status user@${uid}.service user@1000.service - User Manager for UID 1000 Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset> From b6d2256d6752b14ebe524087193d3b93ff1140b5 Mon Sep 17 00:00:00 2001 From: doc-claw-bot Date: Tue, 23 Jun 2026 08:47:43 +0000 Subject: [PATCH 2/4] docs: clarify no-sudo limit verification --- tiup/tiup-cluster-no-sudo-mode.md | 38 +++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index 222c8555cca0f..f30660fdc5943 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -40,7 +40,7 @@ This document takes the `tidb` user as an example. EOF ``` - Because TiDB services in no-sudo mode are managed by the per-user `systemd` instance (`user@.service`), the limits in `/etc/security/limits.conf` are applied when `user@.service` starts. If you change `/etc/security/limits.conf` after `user@.service` is already running, restart `user@.service` or reboot the target machine before you deploy or restart TiDB services. Otherwise, the new limits might not take effect for the TiDB services. + In no-sudo mode, TiDB services are managed by each user's own `systemd` instance (`user@.service`). The settings in `/etc/security/limits.conf` might be applied through PAM when `user@.service` starts, but the effective file descriptor limit still depends on the resource limits obtained by that user `systemd` instance itself. On some systems, even after you configure `/etc/security/limits.conf`, the `Max open files` value of `user@.service` might still be lower than what TiDB requires. 2. Start the `systemd user` mode for the `tidb` user on each target machine. This step is required and do not skip it. @@ -53,13 +53,11 @@ This document takes the `tidb` user as an example. source ~/.bashrc.d/systemd ``` - 2. Use the `root` user to start the user service. If `user@${uid}.service` is already running after you update `/etc/security/limits.conf`, run `systemctl restart user@${uid}.service` to apply the new limits. + 2. Use the `root` user to start the user service. ```shell $ uid=$(id -u tidb) # Get the ID of the tidb user $ systemctl start user@${uid}.service - # If user@${uid}.service is already running after you update /etc/security/limits.conf, run: - $ systemctl restart user@${uid}.service $ systemctl status user@${uid}.service user@1000.service - User Manager for UID 1000 Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset> @@ -78,7 +76,37 @@ This document takes the `tidb` user as an example. └─3358 /usr/bin/pulseaudio --daemonize=no --log-target=journal ``` - 3. Execute `systemctl --user`. If no errors occur, it indicates that the `systemd user` mode has started successfully. + If you update `/etc/security/limits.conf` after `user@${uid}.service` is already running, restart `user@${uid}.service` before you deploy or restart TiDB services so that the user `systemd` instance reloads the updated resource limits. Restarting `user@${uid}.service` stops all user services managed by that user. If the cluster is already running, stop it gracefully first or perform this operation during a maintenance window. + + ```shell + $ uid=$(id -u tidb) # Get the ID of the tidb user + $ systemctl restart user@${uid}.service + ``` + + 3. Check the effective `Max open files` value of the running `user@${uid}.service`. + + ```shell + $ uid=$(id -u tidb) + $ pid=$(systemctl show "user@${uid}.service" --property MainPID --value) + $ grep "Max open files" "/proc/${pid}/limits" + ``` + + If the `Max open files` value is still lower than what TiDB requires, configure a system-level drop-in for `user@${uid}.service`, then restart the service and check the effective value again. + + 4. Use the `root` user to configure `LimitNOFILE` for `user@${uid}.service`. + + ```shell + $ uid=$(id -u tidb) + $ install -d -m 0755 "/etc/systemd/system/user@${uid}.service.d" + $ cat <<'EOF' > "/etc/systemd/system/user@${uid}.service.d/limit-nofile.conf" + [Service] + LimitNOFILE=1000000 + EOF + $ systemctl daemon-reload + $ systemctl restart user@${uid}.service + ``` + + 5. Execute `systemctl --user`. If no errors occur, it indicates that the `systemd user` mode has started successfully. 3. Use the `root` user to execute the following command to enable lingering for the systemd user `tidb`. From 071177bcd068667eacc25f6dbb930d08978bc2f4 Mon Sep 17 00:00:00 2001 From: doc-claw-bot Date: Tue, 23 Jun 2026 08:53:49 +0000 Subject: [PATCH 3/4] docs: clarify no-sudo limit threshold --- tiup/tiup-cluster-no-sudo-mode.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index f30660fdc5943..1e61007a0b276 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -76,7 +76,7 @@ This document takes the `tidb` user as an example. └─3358 /usr/bin/pulseaudio --daemonize=no --log-target=journal ``` - If you update `/etc/security/limits.conf` after `user@${uid}.service` is already running, restart `user@${uid}.service` before you deploy or restart TiDB services so that the user `systemd` instance reloads the updated resource limits. Restarting `user@${uid}.service` stops all user services managed by that user. If the cluster is already running, stop it gracefully first or perform this operation during a maintenance window. + If you update `/etc/security/limits.conf` after `user@${uid}.service` is already running, restart `user@${uid}.service` before you deploy or restart TiDB services so that the user `systemd` instance reloads the updated resource limits. Restarting `user@${uid}.service` stops all systemd user services managed by that user. If the cluster is already running, stop it gracefully first or perform this operation during a maintenance window. ```shell $ uid=$(id -u tidb) # Get the ID of the tidb user @@ -91,9 +91,9 @@ This document takes the `tidb` user as an example. $ grep "Max open files" "/proc/${pid}/limits" ``` - If the `Max open files` value is still lower than what TiDB requires, configure a system-level drop-in for `user@${uid}.service`, then restart the service and check the effective value again. + If the `Hard Limit` value in the previous output is lower than `1000000`, continue to the next step and use the `root` user to configure `LimitNOFILE` for `user@${uid}.service`. - 4. Use the `root` user to configure `LimitNOFILE` for `user@${uid}.service`. + 4. If the `Hard Limit` value in the previous output is lower than `1000000`, use the `root` user to configure `LimitNOFILE` for `user@${uid}.service`. ```shell $ uid=$(id -u tidb) @@ -106,7 +106,9 @@ This document takes the `tidb` user as an example. $ systemctl restart user@${uid}.service ``` - 5. Execute `systemctl --user`. If no errors occur, it indicates that the `systemd user` mode has started successfully. + After you configure the drop-in and restart the service, repeat Step 3 to confirm that the effective `Max open files` value now meets the requirement. + + 5. Use the `tidb` user to execute `systemctl --user`. If no errors occur, it indicates that the `systemd` user service mode for the `tidb` user has started successfully. 3. Use the `root` user to execute the following command to enable lingering for the systemd user `tidb`. From 3aa521bd8a14dae755a7821b5a01f5da93bd62e9 Mon Sep 17 00:00:00 2001 From: doc-claw-bot Date: Tue, 23 Jun 2026 09:00:57 +0000 Subject: [PATCH 4/4] docs: show limits header in no-sudo check --- tiup/tiup-cluster-no-sudo-mode.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index 1e61007a0b276..ca65dd90b34b6 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -88,11 +88,9 @@ This document takes the `tidb` user as an example. ```shell $ uid=$(id -u tidb) $ pid=$(systemctl show "user@${uid}.service" --property MainPID --value) - $ grep "Max open files" "/proc/${pid}/limits" + $ grep -E '^(Limit|Max open files)' "/proc/${pid}/limits" ``` - If the `Hard Limit` value in the previous output is lower than `1000000`, continue to the next step and use the `root` user to configure `LimitNOFILE` for `user@${uid}.service`. - 4. If the `Hard Limit` value in the previous output is lower than `1000000`, use the `root` user to configure `LimitNOFILE` for `user@${uid}.service`. ```shell