1

The title says all. anyway, I just upgraded my server from 14.04 LTS to 16.04 LTS and I realized the sudo runs too much slower than 14.04.

I strace'd and got following result:

$ sudo strace sudo true

---------------------------- snip -------------------------------

...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 9
bind(9, {sa_family=AF_INET, sin_port=htons(722), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(723), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(724), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(725), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(726), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(727), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(728), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(729), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(730), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(731), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(732), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(733), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(734), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(735), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(736), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(737), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(738), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
bind(9, {sa_family=AF_INET, sin_port=htons(739), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
...

---------------------------- snip -------------------------------

The sudo command itself succeeded, it just took too long time, like 5 sec.

The port range is 512-1023, seems it tries to bind privilege port for something like guarantee it is having superuser privilege.

And after the sudo succeeded, netstat -an shows:

---------------------------- snip -------------------------------

...
tcp        0      0 192.168.0.10:959     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:910     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:932     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:34470   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:966     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:903     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:875     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:45452   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:970     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:907     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:41063   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:45659   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:948     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:50370   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:56145   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:929     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:909     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:33648   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:33556   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:55209   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:975     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:969     192.168.0.1:617      TIME_WAIT  
tcp        0      0 192.168.0.10:35903   192.168.0.1:111      TIME_WAIT  
tcp        0      0 192.168.0.10:888     192.168.0.1:617      TIME_WAIT  
...

---------------------------- snip -------------------------------

Where 192.168.0.10 is my server and 192.168.0.1 is the NIS server.

When I stop the ypbind on my server and runs the sudo, no more useless bind(2) and no more TIME_WAIT between my server and NIS server are observed.

I can't stop the ypbind and I want my old agile sudo speed back so bad B)

What can I do?

Thank you

Videonauth
  • 33,815
Taverna Unci
  • 21

2 Answers2

1

I had the same issue using NIS groups and users. Each user authentication is painfully slow. You can as well tcpdump the traffic between the client and the NIS server and see an unusual storm of packets going on between the two for like a minute in my case.

I went to play with the config and had the idea of switching the config a la redhat and it completely change the behaviour of the auth, login, sudo very fast. Just remove the "+::::" from /etc/passwd, /etc/shadow, /etc/group and the nsswitch.conf file to change the following lines :

passwd:         files nis
group:          files nis
shadow:        files nis

Tell me how it goes.

blablabla
  • 11
1

We ran into the same behaviour after upgrading a couple of systems to 16.04 LTS. We use compat mode with NIS to selectively choose, via +@netgroup and +user in /etc/passwd, who from the larger NIS domain may access our systems.

My co-worker - who should get all the credit, but doesn't do the StackExchange thing - found a workaround that lets you keep compat mode and the ability to use +@netgroup and +user in /etc/passwd. Leave the compat mode for passwd and shadow, but use "files nis" for group in /etc/nsswitch.conf:

passwd:    compat
shadow:    compat
group:     files nis

"compat" mode for /etc/group is equivalent to "files nis" if all you want to do is include the entire NIS group map.

Would be interested in hearing whether this works for your situation.

Jon Kuroda
  • 11