When experiencing sudo hangs on CentOS 5, the symptoms typically manifest as:

$ sudo ls
# After password entry, hangs for ~60 seconds
# Eventually executes or times out

The delay occurs between authentication and command execution, regardless of SELinux state. This suggests the issue lies deeper in the system's authentication pipeline.

First, enable debug logging in sudo:

$ sudo visudo
# Add at top:
Defaults logfile=/var/log/sudo_debug.log
Defaults debug

Then check these critical components:

1. DNS Resolution:

$ time host $(hostname)
$ cat /etc/hosts
# Ensure proper localhost resolution

2. PAM Configuration:

$ ls -la /etc/pam.d/sudo
$ grep -r pam_ /etc/pam.d/

Option 1: Disable reverse DNS in sudoers

$ sudo visudo
# Add line:
Defaults !fqdn

Option 2: Modify PAM stack

# Edit /etc/pam.d/sudo
# Comment out or modify problematic modules like:
# auth sufficient pam_ldap.so

Option 3: Network timeout adjustment

$ sudo sysctl -w net.ipv4.tcp_keepalive_time=60
$ sudo sysctl -w net.ipv4.tcp_keepalive_probes=3

For persistent cases, use strace:

$ strace -o /tmp/sudo_trace -ff sudo ls
$ grep -i 'connect\|timeout' /tmp/sudo_trace*

Check for NSS-related delays:

$ time getent passwd $USER
$ time getent group $USER

For production systems, consider adding these to /etc/sysctl.conf:

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3

And in /etc/sudoers:

Defaults timestamp_timeout=15
Defaults !requiretty

---

When executing basic commands like sudo ls, the system hangs for exactly 60 seconds before completing. This behavior persists regardless of SELinux status (enabled/disabled) and occurs after authentication but before command execution.

CentOS 5's default sudo configuration may attempt reverse DNS lookups. Check your /etc/nsswitch.conf:

hosts:      files dns

Add these lines to /etc/sudoers:

Defaults    fqdn
Defaults    !requiretty
Defaults    !dns

Examine PAM configuration in /etc/pam.d/sudo:

auth       include      system-auth
account    include      system-auth
session    include      system-auth

Test with minimal PAM configuration:

auth       required     pam_permit.so
account    required     pam_permit.so
session    required     pam_permit.so

Check for network dependencies in sudo operation:

strace -o sudo_trace.log sudo ls

Key things to look for in the trace:

connect(3, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)

Test with direct UID switching:

su -c "ls" root

If this works instantly, confirms sudo-specific issue

Monitor authentication logs in real-time:

tail -f /var/log/secure | grep sudo

Expected successful auth message:

Jul 10 15:30:01 localhost sudo:    user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/ls

Check Name Service Cache Daemon status:

service nscd status
chkconfig --list nscd

Test with NSCD temporarily disabled:

service nscd stop
sudo ls

Use systemtap for deeper analysis:

stap -e 'probe syscall.connect.return { 
  if (execname() == "sudo") printf("%s %s\\n", name, argstr) 
}'

If timeouts persist, implement workarounds:

alias fastsudo='sudo -A'

With accompanying /etc/sudoers.d/fastsudo:

Defaults    !tty_tickets
Defaults    timestamp_timeout=30