Вопросы Теги

Как удостовериться, что сервер nfs не запущен, пока он не может разрешить имена хостов? (16.10)

Сводка: Есть ли способ удостовериться, что сервер NFS не запущен systemd, пока он не может правильно разрешить клиентские названия машины, указанные в /etc/exports?

Описание проблемы: Я нашел, что доли NFS не сделаны правильно доступными после сервера (работающий 16.10) перезагрузки. Клиенты получают "доступ запрещен сервером" ошибки, до exportfs -ra или service nfs-server restart вручную выполняется на сервере. После этого все работает как ожидалось.

Сервер /etc/exports содержит только:

/mnt/raidarray clientmachine(rw)

где clientmachine имя хоста клиентской машины NFS в локальной сети.

Идентификация задач: вывод systemctl status nfs-server (ниже) ясно дает понять проблему: имя клиента не может быть разрешено в то время, когда сервер NFS был запущен. 

● nfs-server.service - NFS server and services
Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled
Active: active (exited) since Tue 2017-01-17 16:47:38 CST; 26min ago
Main PID: 1520 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/nfs-server.service
Jan 17 16:47:38 servermachine exportfs[1511]: exportfs: Failed to resolve clientmachine
Jan 17 16:47:38 servermachine systemd[1]: Started NFS server and services.

NetworkManager-wait-online.service включен, который я понял подачи для проверки этого network.target (на который nfs-server зависит), не удовлетворен до network-online.target удовлетворен.

Вещи, которые не помогли:

  1. В случае, если я неправильно понял что NetworkManager-wait-online.service делает, я пытался добавить явное After=network-online.target и Wants=network-online.target кому: nfs-server.service. Это ничего не фиксирует. Я вижу, что новая зависимость обнаруживается в systemctl list-dependencies, но определение имен все еще перестало работать при начальной загрузке. Таким образом, это кажется этим network-online.target не гарантирует, что разрешение сетевых имен может произойти.

  2. Некоторый поиск с помощью Google предложил то требование nss-lookup.target гарантировал бы, что сетевое разрешение доступно, но добавление его как a Wants и/или After зависимость к nfs-server.service не чинит вещи также!

  3. Добавление a Wants и/или After зависимость от systemd-resolved.service вместо nss-lookup.target не чинит вещи также.

После добавления всех этих зависимостей, nfs-server запускает очень очень поздно в процессе начальной загрузки (непосредственно перед тем, как настольные вещи входа в систему), но он все еще не может разрешить хосты. На основе systemd-analyze plot, это появляется это nmbd втиснут в это время, но я не знаю, связано ли это.

Конфигурационная информация: Это находится на настольной версии kubuntu 16.10, который является в основном новой установкой.

NetworkManager.service включен и systemd-networkd.service отключен - я не изменил это от значения по умолчанию.

Вот NetworkManager-wait-online сервисное определение:

[Unit]
Description=Network Manager Wait Online
Documentation=man:nm-online(1)
Requisite=NetworkManager.service
After=NetworkManager.service
Before=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q --timeout=30
RemainAfterExit=yes
[Install]
WantedBy=network-online.target

Как обходное решение я мог IP-адреса твердого кода вместо имен хостов в /etc/exports или /etc/hosts, но это кажется несколько хрупким. Существует ли лучший ответ?

РЕДАКТИРОВАНИЕ - Обновление: следуя совету @muru ниже, я пытался делать сценарий для ожидания для разрешения имен хостов - только для наблюдения, сколько времени он берет. Мой сценарий должен ожидать спустя десятки секунд после этого systemd-resolved запускается, прежде чем это сможет на самом деле разрешить хост. Это очень причудливо. Интересно, является ли это на самом деле локальная сетевая проблема? Походит, возможно, на трудно кодированный (и автообновление, возможно, как предложено @mark-stosberg) /etc/exports или /etc/hosts файл гарантирован.

5
задан 19 January 2017 в 08:14

4 ответа

На основе комментария @muru я сделал сценарий Python для ожидания до разрешения DNS: 

import socket
import time
import itertools

TIMEOUT = 30
HOSTS = ['stanford.edu', 'google.com', 'example.com']

def main():
    hosts = itertools.cycle(HOSTS)
    t0 = time.time()
    for host in hosts:
        t = time.time()
        elapsed = t - t0
        if elapsed > TIMEOUT:
            break
        try:
            socket.getaddrinfo(host, None, proto=socket.IPPROTO_TCP)
            print('Resolved {} at t = {}'.format(host, elapsed))
            break
        except socket.gaierror:
            print('Could not resolve {} at t = {}'.format(host, elapsed))
        time.sleep(0.25)
        t = time.time()

if __name__ == '__main__':
    main()

Я сохранил тот сценарий как /etc/systemd/system/nfs-server.service.d/wait_for_dns.py (нужно сделать родительский каталог сначала), и затем работал sudo systemctl edit --full nfs-server, добавление следующего перед другими строками ExecStartPre:

ExecStartPre=/usr/bin/python3 /etc/systemd/system/nfs-server.service.d/wait_for_dns.py

Это хорошо работало, хотя это, конечно, чувствует немного hackish и могло быть улучшено во многих отношениях. (Я в конечном счете просто разочаровался в NFS в этом контексте; это было больше боли, чем это стоило.)

0
ответ дан 23 November 2019 в 10:55

С точки зрения того, что Вы пытаетесь сделать с systemd, Вы уже попытались сделать лучшую вещь, которая должна установить Ваш сервис для запуска после network-online. Я считал много из systemd вопросы, и другие сообщили о проблемах с сетью, не бывшей онлайн полностью, когда они делают это.

я рекомендую идее поместить IP-адреса в /etc/exports или /etc/hosts, как Вы рекомендуете. Это упрощает важную дисковую задачу монтирования во время начальной загрузки.

Для создания системы более устойчивой Вы могли использовать задание крона или systemd таймер, который проверяет периодически, чтобы видеть, изменился ли DNS для интересных хостов. Если так, автоматически обновите /etc/hosts с новыми значениями.

0
ответ дан 23 November 2019 в 10:55

У меня была та же проблема на установке ubuntu 16.04.03 LTS.
exportfs не работал правильно после перезагрузки и таким образом сервер ядра nfs не запускался правильно.
Я пытался добавить сон к случаю запуска в/etc/init.d/nfs-kernel-server, но это не помогло.
Я также попробовал найденный https: некоторых подсказок//discourse.osmc.tv/t/nfs-kernel-server-wont-start-on-boot/5936/7
Я наконец решил проблему путем добавления следующей строки к/etc/rc.local 

systemctl restart nfs-kernel-server
0
ответ дан 23 November 2019 в 10:55

это беспокоило меня несколько недель. Сначала я не понял, почему KODI на моем телевизоре вдруг не видит NFS-ресурсы. И тогда я не мог понять, как это решить, потому что все решения, которые я нашел, не работали 19.04.

Но добавление задания cron с командой 

systemctl restart nfs-kernel-server

в качестве команды после каждой перезагрузки решило эту проблему.

0
ответ дан 3 December 2019 в 20:35

Другие вопросы по тегам:

Похожие вопросы: