When encountering the error su: cannot set user id: Resource temporarily unavailable with PAM logs showing Unable to change UID to 500 temporarily, this typically indicates a system resource limitation preventing user switching. Let's analyze the key components:

# Sample error from /var/log/secure
su: pam_keyinit(su-l:session): Unable to change UID to 500 temporarily
su: pam_unix(su-l:session): session opened for user adtech by root(uid=0)

While the user process count (25) appears well below the max user processes limit (1024), other limits may be involved:

# Checking system-wide limits
cat /proc/sys/kernel/threads-max
cat /proc/sys/vm/max_map_count
cat /proc/sys/kernel/pid_max

In this case, the issue was caused by a Java service (Nexus) running as the adtech user. The critical evidence was found in the JVM logs:

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)

This indicates the process hit the maximum number of threads allowed, which affects the entire user session.

Here are specific actions to resolve this issue:

# 1. Increase system thread limits temporarily
echo 1200000 > /proc/sys/kernel/threads-max

# 2. Set user-specific limits in /etc/security/limits.conf
adtech soft nproc 20480
adtech hard nproc 40960

# 3. For Java applications, add JVM parameters
export JAVA_OPTS="-Xmx1024m -Xms512m -XX:MaxMetaspaceSize=256m"

Implement these monitoring scripts to catch issues early:

#!/bin/bash
# Monitor user resource usage
watch -n 60 "ps -u adtech -L | wc -l"

# Alternative using /proc
count_threads() {
  find /proc/[0-9]*/task -maxdepth 0 -type d | wc -l
}

For long-term stability, modify these system files:

# /etc/sysctl.conf additions
kernel.threads-max = 1200000
vm.max_map_count = 600000
kernel.pid_max = 4194304

# Apply changes
sysctl -p

---

When attempting to switch users in Linux using su or SSH into a specific account, you might encounter the frustrating error:

su: cannot set user id: Resource temporarily unavailable

From the /var/log/secure logs, we can see more details:

su: pam_keyinit(su-l:session): Unable to change UID to 500 temporarily
su: pam_unix(su-l:session): session opened for user adtech by root(uid=0)

At first glance, this appears to be a resource limitation issue. Let's examine the key areas to investigate:

# Check user limits
ulimit -a

# Count processes for the user
ps -U username | wc -l

# Verify user entry
getent passwd username

In our case, the user adtech showed:

adtech:x:500:502::/home/adtech:/bin/bash

Through investigation, we identified a Java process that was the root cause:

adtech   12901     1  0 08:58 ?        00:00:00 /home/adtech/nexus/bin/../bin/jsw/linux-x86-64/wrapper
adtech   12903 12901  1 08:58 ?        00:00:24 java -Dsun.net.inetaddr.ttl=3600 [...]

Killing this process resolved the immediate issue, but we needed to understand why it happened.

The Java process logs revealed the true problem:

jvm 1    | Server daemon died!
jvm 1    | java.lang.OutOfMemoryError: unable to create new native thread

This indicates the process hit the maximum number of threads allowed for the user.

Here are several approaches to prevent this issue:

# Increase user process limits (temporary)
ulimit -u 4096

# Permanent solution - edit /etc/security/limits.conf
echo "adtech hard nproc 4096" >> /etc/security/limits.conf

# For systemd services, create override:
mkdir -p /etc/systemd/system/nexus.service.d/
echo -e "[Service]\nLimitNPROC=4096" > /etc/systemd/system/nexus.service.d/limits.conf
systemctl daemon-reload

Implement these monitoring solutions:

# Cron job to monitor process count
*/5 * * * * root [ $(ps -u adtech --no-headers | wc -l) -gt 1000 ] && /usr/sbin/sendmail admin@example.com

For Java applications, add these JVM parameters:

-XX:ParallelGCThreads=4 
-XX:ConcGCThreads=2 
-Djdk.lang.processReaperUseDefaultStackSize=true