На наших серверах, работающих под управлением CentOS 6 x86_64, мы наблюдаем много необычной активности с rpc.statd. У нас есть rpc.statd настроен для работы на статическом порту через /etc/sysconfig/nfs:
MOUNTD_PORT=892
STATD_PORT=662
QUOTAD_PORT=875
И это приводит к rpc.statd работает и прослушивает этот порт, как ожидалось:
# ps -fe | grep rpc.statd | grep 662
rpcuser 23129 1 0 Apr30 ? 00:00:00 rpc.statd -p 662
Странно то, что в этой системе есть также множество других rpc.statd экземпляры, работающие с --no-notify флаг:
rpcuser 808 1 0 02:23 ? 00:00:00 rpc.statd --no-notify
rpcuser 2052 1 0 07:17 ? 00:00:00 rpc.statd --no-notify
rpcuser 3558 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 5787 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 6499 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 8834 1 0 03:21 ? 00:00:00 rpc.statd --no-notify
rpcuser 9661 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 13702 1 0 00:08 ? 00:00:00 rpc.statd --no-notify
rpcuser 14813 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 15375 1 0 08:39 ? 00:00:00 rpc.statd --no-notify
rpcuser 15376 1 0 04:26 ? 00:00:00 rpc.statd --no-notify
rpcuser 19782 1 0 09:36 ? 00:00:00 rpc.statd --no-notify
rpcuser 20491 1 0 05:36 ? 00:00:00 rpc.statd --no-notify
rpcuser 23136 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 23320 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 26145 1 0 10:10 ? 00:00:00 rpc.statd --no-notify
rpcuser 26480 1 0 06:24 ? 00:00:00 rpc.statd --no-notify
rpcuser 26598 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
rpcuser 26821 1 0 01:15 ? 00:00:00 rpc.statd --no-notify
rpcuser 28255 1 0 Apr30 ? 00:00:00 rpc.statd --no-notify
Также странно то, что один из этих процессов, по-видимому, узурпировал исходный rpc.statd что касается rpcbind. Бег rpcinfo отчеты о статистике по следующим портам:
# rpcinfo -p
...
100024 1 udp 34322 status
100024 1 tcp 41686 status
Они соответствуют PID 26145 (который, как вы видите, является одним из rpc.statd экземпляры в приведенном выше выводе из ps).
Это не было бы проблемой, если бы все работало, но вчера в системе начались проблемы с монтированием NFS ... любая попытка смонтировать новую файловую систему приведет к:
mount.nfs: mount system call failed
Убивая все rpc.statd services «решили» проблему, но мы не понимаем, что здесь происходит. Мы никогда не видели такого поведения в наших системах CentOS 5 с аналогичной конфигурацией.
Что ж, похоже, это частично наша вина, а частично ошибка в RedHat. authconfig команда. Наша конфигурация Puppet вызвала authconfig --updateall запускаться каждый час. В этом не было необходимости, но обычно проблем быть не должно ... кроме authconfig перезапускает rpcbind служба.
Начать сначала rpcbind заставляет его забыть обо всех службах, которые были зарегистрированы в нем. Пока authconfig затем перезапустит службы, связанные с NIS, это приведет к ситуации, когда rpc.statd все еще работает, но больше не зарегистрирован в rpcbind - что делает его фактически невидимым с точки зрения приложений, которые пытаются найти его через rpcbind.
Я исправил нашу конфигурацию Puppet, чтобы она больше не звонила authconfig вот так, и я открыл ошибку 818246 с RedHat.