>>> Прошу помочь решить проблему, указать куда ковырять и т.д.
>> Похоже на проблемы с DNS или WINS. Вообще, если WINS вам не
>> нужен (а зачем он нужен в домене?), то лучше бы его
>> отключить, конечно.
>>
>>>|[sam-dom]# wbinfo --all-domains
>>>|failed to call wbcListTrusts: WBC_ERR_WINBIND_NOT_AVAILABLE
> вот такой вывод в моменты наблюдения проблемы.
> из этого могу предположить, что все таки винбинд глючит. тем более, что
> перезапуск DNS'a проблему не решает

Посмотрел исходники Samba — судя по всему, эта проблема возникает при любой ошибке доступа к UNIX-сокету, по которому должен быть доступен winbind. То есть: если сокет не доступен на чтение-запись, или если при чтении-записи происходит ошибка (кроме EAGAIN).

А дальше у меня глаза на лоб вылезли:

                ret = poll(&pfd, 1, 5000);
                // <...>
                if ((ret == 1) && (pfd.revents & (POLLIN|POLLHUP|POLLERR))) {
                        /* Do the Read */
                        int result = read(fd, (char *)buffer + nread,
                              count - nread);
                        if ((result == -1) || (result == 0)) {
                                /* Read failed.  I think the only useful thing we
                                   can do here is just return -1 and fail since the
                                   transaction has failed half way through. */
                                winbind_close_sock(ctx);
                                return -1;
                        }
                        nread += result;
                }

То есть даже если read() (или write(), там похожая ситуация) вернёт -1 + errno=EAGAIN, мы считаем, что жизнь кончена. Да, они используют неблокирующийся ввод-вывод, но работают полностью синхронно — видимо, чтобы выставлять таймауты. Первая мысль была: «как этот код может вообще работать?!». Но, видимо, при небольшом объёме передаваемых или отправляемых данных у них всё помещается в буфер сокета и всё хорошо. Если они всегда передают мало-мало данных, а транзакции в целом включают одну запись и одно чтение, то это даже может работать. Хотя всё равно может какой-нибудь не очевидный лимит вылезти.

К сожалению, wbinfo не сообщает нижележащую ошибку, по которой можно было бы понять, что именно обламывается: lstat/socket/connect/read/write. Думаю, вы можете в проблемный момент попробовать с помощью nc/netcat/socat подключиться к сокету winbind (скорее всего, он где-то в /run живёт). Ну или запустить wbinfo под strace.

Есть вариант, что winbind не успевает принимать подключения (переполнен backlog, его размер равен 5), почему — сложно сказать, но есть предположение, что они таки превращают где-то неблокирующийся ввод-вывод в обычный синхронный. Можно попробовать поизучать вывод от tevent, конечно... Но лучше было бы, думаю, запустить winbind под strace -f.