Description of problem:
When using NIS for username resolution server hangup after shutting down the interface.
Version-Release number of selected component (if applicable):
Using NIS to resolv oracle uid
Steps to Reproduce:
server hang (shutdown take 30 mins / 1 hour ) to stop
Server shuttdown normally
- The workarround is not stopping the network when shutting down the server.
mv K99network k99network
- Some scripts are trying to solve usernames to uids,
The following error appears:
"su: user 238 does not exist"
238 is oracle uid on NIS
Because the network is stopped before than this process, su tries to lookup the uid of oracle but it cant get any response
That is weird, because ypbind should be stopped before network and after ypbind is stopped, glibc shouldn't ask for user information any more. So, either I didn't understand all the consequences or there is something wrong with the ypserv shutting down. I'd definitely need some more information.
Does the link /etc/rc6.d/K73ypbind exist?
Is there any error in the syslog related the ypbind?
Yes, it is!
Attaching files with the output of each command:
Created attachment 883527 [details]
Created attachment 883528 [details]
Created attachment 883529 [details]
Unfortunately this did not help
Also can you post here you /var/log/messages?
customer reports downgrading the initscripts fix the issue
I've downgraded to initscripts-9.03.38-1.el6.x86_64 and it has fixed the
The server now reboots without hanging so it looks like the problem is
somewhere in initscripts.
What else should I ask to the customer ?
I think that the problem described is related to " loopback scope global" problem as described in https://www.centos.org/forums/viewtopic.php?f=16&t=45370
Can you check if the attached patch helps?
Created attachment 895547 [details]
Comment on attachment 895547 [details]
Typo on line
Additionally I may comment that this flush problem probably is due to the fact that not all connections are being closed at the time of network shutdown. I have observed portmapper and rpc.statd connections before entering K90network. Even if nfslock services were not started. Anyway, I think that global scope on localhost flush is a bug that needs to be handled as proposed.
It will be enough with the /var/log/messages in the customer portal case ?
Now the customer has the previous version of the initscripts...
Created attachment 895916 [details]
var log messages*
What is the status of this bug? I too have this issue on 6.5 and found that downgrading to initscripts-9.03.38-1.el6.x86_64 resolved the issue.
FYI proposed patch in comment 29 resolved the problem with initscripts-9.03.40-2.el6.centos.x86_64 package installed.
With your proposed patch i am able to shutdown my network without it hanging and bring it back up.
sorry the proper installed package is initscripts-9.03.40-2.el6.x86_64. I ws unable to copy/paste from the server to my laptop so I googled the package name and it brought up the centos version of the package.
Using your proposed patch in comment 29 I was able to get the network to shutdown properly without it hanging. I do still get a lot of:
do_ypcall: clnt_call: RPC: unable to send; errno = Network is unreachable
errors until the network service starts up but at least its not hanging.
do_ypcall errors are expected of course since ypbind is still running.
Just adding with your proposed fix on boot up i do not get the do_ypcall errors that i displayed above anymore. Prior to the fix I did on boot up and while it was hanging on shutdown.
I think you resolved the issue with that few lines above in comment 29
Now that the patch has been verified, hopefully this will be accepted for initscripts update. As mentioned, global scope on loopback is essentially wrong any NIS just happened to be unclean at shutdown and got caught up in flushing. It didn't helped to me even if I killed the remaining processes before entering interface stopping.
Sorry wrong commit
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.