После обновления nfs-{clients,stats,utils} 1:1.3.2-alt0.4 => 1.1.3.2-alt2 (и попутной починки конфига nodm, который в 0.7-alt3 перестал понимать синтаксис sh в /etc/sysconfig/nodm) пакет NFS неработоспособен без некого nfs-config.service: ========================================================== Feb 7 00:08:32 thinkpad systemd[1]: Cannot add dependency job for unit nfs-config.service, ignoring: Unit nfs-config.service failed to load: No such file or directory. Feb 7 00:08:32 thinkpad systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Feb 7 00:08:32 thinkpad rpc.statd[2680]: Version 1.3.2 starting Feb 7 00:08:32 thinkpad rpc.statd[2680]: Flags: TI-RPC Feb 7 00:08:32 thinkpad rpc.statd[2680]: failed to create RPC listeners, exiting Feb 7 00:08:32 thinkpad systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Feb 7 00:08:32 thinkpad systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Feb 7 00:08:32 thinkpad systemd[1]: Unit rpc-statd.service entered failed state. Feb 7 00:08:32 thinkpad systemd[1]: rpc-statd.service failed. =========================================================
а, да, он в -server попал, нужно бы переложить. во вообще, не в нём дело (написано же -- ignoring). вот это вот по существу: rpc.statd[2680]: failed to create RPC listeners ... что там, ещё один был запущен ?
Может быть, это последствие жесткой перезагрузки машины (см. https://bugzilla.altlinux.org/show_bug.cgi?id=30708), т.к. непосредственно до неё было так: ========================================================== root@thinkpad ~ #journalctl -b -3 -u rpc-statd -- Logs begin at Sat 2013-10-26 10:03:01 KRAT, end at Sat 2015-02-07 02:27:32 KRAT. -- Feb 06 23:28:33 thinkpad.evg-krsk.dyndns.org systemd[1]: Stopping NFS status monitor for NFSv2/3 locking.... Feb 06 23:28:33 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Feb 06 23:28:33 thinkpad.evg-krsk.dyndns.org rpc.statd[31107]: Version 1.3.2 starting Feb 06 23:28:33 thinkpad.evg-krsk.dyndns.org rpc.statd[31107]: Flags: TI-RPC Feb 06 23:28:33 thinkpad.evg-krsk.dyndns.org systemd[1]: Started NFS status monitor for NFSv2/3 locking.. ========================================================== а сразу после жесткой перезагрузки уже так: ========================================================== root@thinkpad ~ #journalctl -b -2 -u rpc-statd -- Logs begin at Sat 2013-10-26 10:03:01 KRAT, end at Sat 2015-02-07 02:27:32 KRAT. -- Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org rpc.statd[1407]: Version 1.3.2 starting Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org rpc.statd[1407]: Flags: TI-RPC Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org rpc.statd[1407]: failed to create RPC listeners, exiting Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org systemd[1]: Unit rpc-statd.service entered failed state. Feb 06 23:32:09 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service failed. ========================================================== далее я разобрался с неработающим nodm, перезагрузился и получилось вот так: ========================================================== root@thinkpad ~ #journalctl -b -1 -u rpc-statd -- Logs begin at Sat 2013-10-26 10:03:01 KRAT, end at Sat 2015-02-07 02:27:32 KRAT. -- Feb 07 00:05:11 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Feb 07 00:05:11 thinkpad.evg-krsk.dyndns.org rpc.statd[1637]: Version 1.3.2 starting Feb 07 00:05:11 thinkpad.evg-krsk.dyndns.org rpc.statd[1637]: Flags: TI-RPC Feb 07 00:05:11 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Feb 07 00:05:11 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Feb 07 00:05:11 thinkpad.evg-krsk.dyndns.org systemd[1]: Unit rpc-statd.service entered failed state. Feb 07 00:05:11 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service failed. Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org rpc.statd[2680]: Version 1.3.2 starting Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org rpc.statd[2680]: Flags: TI-RPC Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org rpc.statd[2680]: failed to create RPC listeners, exiting Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org systemd[1]: Unit rpc-statd.service entered failed state. Feb 07 00:08:32 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service failed. Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org rpc.statd[9643]: Version 1.3.1 starting Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org rpc.statd[9643]: Flags: TI-RPC Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org rpc.statd[9643]: failed to create RPC listeners, exiting Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org systemd[1]: Unit rpc-statd.service entered failed state. Feb 07 01:24:33 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service failed. ========================================================== кстати, насчёт вышеупомянутого бага: очень подозрительно, что systemd уронился как раз на обновлении nfs-clients до 1.3.2-alt2.
Ну т.е. я делал systemctl restart rpc-statd, но это не дало результатов, юнит так и висел в failed. Пришлось откатиться на 1.3.2-alt0.4
что, собственно, происходит, если запустить руками ? /sbin/rpc.statd -F -d --no-notify
systemctl status rpcbind ?
(В ответ на комментарий №4) > что, собственно, происходит, если запустить руками ? > /sbin/rpc.statd -F -d --no-notify =========================================================== root@thinkpad ~ #systemctl status rpcbind * rpcbind.service - RPC bind service Loaded: loaded (/lib/systemd/system/rpcbind.service; static) Active: inactive (dead) [1] 2802 exit 3 systemctl status rpcbind root@thinkpad ~ #systemctl list-units --failed UNIT LOAD ACTIVE SUB DESCRIPTION * rpc-statd.service loaded failed failed NFS status monitor for NFSv2/3 locking. LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 1 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. root@thinkpad ~ #systemctl status rpc-statd * rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Sat 2015-02-07 19:43:26 KRAT; 6min ago Process: 1513 ExecStart=/sbin/rpc.statd --no-notify $STATD_OPTIONS (code=exited, status=1/FAILURE) Feb 07 19:43:26 thinkpad.evg-krsk.dyndns.org rpc.statd[1524]: Version 1.3.2 starting Feb 07 19:43:26 thinkpad.evg-krsk.dyndns.org rpc.statd[1524]: Flags: TI-RPC Feb 07 19:43:26 thinkpad.evg-krsk.dyndns.org rpc.statd[1524]: failed to create RPC listeners, exiting Feb 07 19:43:26 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Feb 07 19:43:26 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Feb 07 19:43:26 thinkpad.evg-krsk.dyndns.org systemd[1]: Unit rpc-statd.service entered failed state. Feb 07 19:43:26 thinkpad.evg-krsk.dyndns.org systemd[1]: rpc-statd.service failed. root@thinkpad ~ #rpc.statd -F -d --no-notify rpc.statd: Version 1.3.2 starting rpc.statd: Flags: No-Daemon Log-STDERR TI-RPC rpc.statd: Local NSM state number: 5 rpc.statd: Failed to open /proc/sys/fs/nfs/nsm_local_state: No such file or directory rpc.statd: Failed to unregister program 100024, version 1 rpc.statd: Effective UID, GID: 29, 29 rpc.statd: Failed to register (statd, 1, udp) rpc.statd: Failed to register (statd, 1, tcp) rpc.statd: svc_tli_create: could not open connection for udp6 rpc.statd: Failed to create listener xprt (statd, 1, udp6) rpc.statd: svc_tli_create: could not open connection for tcp6 rpc.statd: Failed to create listener xprt (statd, 1, tcp6) rpc.statd: failed to create RPC listeners, exiting [1] 2435 exit 1 rpc.statd -F -d --no-notify root@thinkpad ~ # ===========================================================
rpcbind должен быть включен
Кстати, обновление до nfs-clients-1:1.3.2-alt2 100% ведёт к неработоспособности systemd (уже второй раз подряд, #30708). Непонятно, что же он такое страшное делает.
Действительно, enable rpcbind + start rpcbind + restart rpc-statd помогли. Но я не выключал rpcbind в /etc/systemd и не понимаю, почему это работало в alt0.4 и почему если кому-то нужен запущенный rpcbind, он не затребовал это в своём юнит-файле.
"включен" неподходящее слово. он должен быть запущен -- для этого есть socket activation, ч-з multi-user.target -> basic.target -> sockets.target -> rpcbind.socket
Что-то я так и не понял, кто в этой цепочке что сделал не так, что нужное оказалось незапущено в alt2, но видимо запущено в alt0.4 (т.к. монтирование работало).
для работы rpc.statd нужен запущенный rpcbind, причём делать systemctl enable rpcbind не требуется. если же нужно простое монтирование (kerberos не используется, на сервере умеют NFSv4), то ничего из обсуждаемого не нужно вообще.
Я столкнулся с тем, что: 1) После успешной транзакции apt-get dist-upgrade и перезагрузки rpcbind не запущен, rpc-statd в состоянии failed, autofs перестал монтировать шары (один сервер, используется NFSv3). 2) Если сделать start rpcbind И start rpc-stad, через короткий промежуток времени autofs начинает монтировать шары штатно. Для того чтобы при следующей загрузке rpcbind был запущен и успешно запустился rpc-statd, я делаю enable rpcbind. Если же вместо этого откатить пакеты на alt0.4 то при следующей загрузке автомонтирование работает. Я сделал что-то не так или чего-то не сделал?
произошло следующее: наши самописные юниты были заменены на апстримные, при этом: старый nfslock.service хотел (requires) rpcbind.service, новому rpc-statd.service достаточно rpcbind.target, который предоставляется rpcbind.socket. если, как утверждается, socket activation для rpcbind не работает, и нужно явно его включать, то я хотел бы узнать, как этого (не-работает-через-сокет) добиться.
собственно, нелья ли увидеть содержимое (ls) /etc/systemd/system/multi-user.target.wants ?
(В ответ на комментарий №14) > произошло следующее: наши самописные юниты > были заменены на апстримные, при этом: > старый nfslock.service хотел (requires) rpcbind.service, > новому rpc-statd.service достаточно rpcbind.target, который > предоставляется rpcbind.socket. > если, как утверждается, socket activation для rpcbind не работает, > и нужно явно его включать, то я хотел бы узнать, как этого > (не-работает-через-сокет) добиться. обновиться :-) ========================================================= root@thinkpad /etc #ls -lht /etc/systemd/system/multi-user.target.wants total 0 lrwxrwxrwx 1 root root 31 Nov 16 16:39 lxc.service -> /lib/systemd/system/lxc.service lrwxrwxrwx 1 root root 34 Nov 8 15:58 auditd.service -> /lib/systemd/system/auditd.service lrwxrwxrwx 1 root root 36 Sep 14 16:50 thinkfan.service -> /etc/systemd/system/thinkfan.service lrwxrwxrwx 1 root root 41 Aug 22 09:16 zabbix_agentd.service -> /lib/systemd/system/zabbix_agentd.service lrwxrwxrwx 1 root root 36 Jul 31 2014 fail2ban.service -> /lib/systemd/system/fail2ban.service lrwxrwxrwx 1 root root 32 Jul 29 2014 ntpd.service -> /lib/systemd/system/ntpd.service lrwxrwxrwx 1 root root 38 Jul 11 2014 fancontrol.service -> /etc/systemd/system/fancontrol.service lrwxrwxrwx 1 root root 34 Jul 2 2014 xinetd.service -> /lib/systemd/system/xinetd.service lrwxrwxrwx 1 root root 35 Dec 20 2013 rsyslog.service -> /lib/systemd/system/rsyslog.service lrwxrwxrwx 1 root root 35 Oct 23 2013 postfix.service -> /lib/systemd/system/postfix.service lrwxrwxrwx 1 root root 32 Oct 22 2013 gssd.service -> /lib/systemd/system/gssd.service lrwxrwxrwx 1 root root 35 Oct 22 2013 nfslock.service -> /lib/systemd/system/nfslock.service lrwxrwxrwx 1 root root 33 Oct 14 2013 crond.service -> /lib/systemd/system/crond.service lrwxrwxrwx 1 root root 35 Oct 14 2013 anacron.service -> /lib/systemd/system/anacron.service lrwxrwxrwx 1 root root 34 Oct 14 2013 mcelog.service -> /lib/systemd/system/mcelog.service lrwxrwxrwx 1 root root 33 Oct 14 2013 nginx.service -> /lib/systemd/system/nginx.service lrwxrwxrwx 1 root root 32 Oct 14 2013 sshd.service -> /lib/systemd/system/sshd.service lrwxrwxrwx 1 root root 34 Oct 14 2013 autofs.service -> /lib/systemd/system/autofs.service =========================================================
в общем, я не вижу хорошего решения -- блюсти совместимость со старой sysv'шной схемой разбивки по сервисам получается плохо, не соблюдать -- технически сложно (post_service и вот это всё). беру таймаут, а пока могу повторить рекомендацию выключить nfslock/rpcbind, использовать NFSv4 (собственно, нужно прилагать усилия, чтобы его _не_ использовать), заодно выкинуть autofs, systemd'шный аналог вполне справляется. к
Попробую посмотреть касательно NFSv4. Только что имеется ввиду под systemd-шным аналогом? man что?
man systemd.mount, systemd.automount tl,dr вписать в fstab свои шары с добавлением в опции x-systemd.automount вроде этого: host:/path/to/sisyphus /mnt/net/sisyphus nfs ro,noauto,x-systemd.automount 0 0
Дело в следующем. Поумолчанию, клиент монтирует ресурс с опцией lock, и ожидает что сервис rpc.statd работает. Если монтировать с nolock, то этот сервис не нужен, и все должно работать. А вот сервис rpc-statd.service (в прошлом nfslock) не может автостартануть, потому что ему нельзя сделать systemctl enable - в нём отсутствует секция [Install]. Он должен стартовать по зависимостям. Так вот эта зависимость как раз и отсутствует, которая его бы запустила. А запускать его должен nfs-utils.service, т.к. в rpc-statd.service указано PartOf=nfs-utils.service Я предполагаю, что клиент (без установленного пакета с сервером) будет работать, если в него перенести следующие юниты: - nfs-config.service - nfs-utils.service И даже я скорее всего тут не прав, и для автостарта клиента надо использовать systemctl enable nfs-client.target - в нем есть секция [Install] и есть зависимость на rpc-statd-notify.service. И еще в нем комментарий: # Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to # start that on demand if needed. Wants=nfs-blkmap.service rpc-statd-notify.service Но - nfs-config.service - nfs-utils.service все равно лучше перенести в пакет с клиентом.
В р8. nfs-clients-1.3.4-alt1 нет службы nfs-idmapd. В пакете nfs-server есть. Без нее при монтировании Nfs шары владелец отображается 4294967294 вместо имени пользователя домена Если установить пакет nfs-server и вручную запустить службу nfs-idmapd то владелец отображается корректно. Можно добавить эту службу в пакет клиента? подробнее по проблеме на форуме https://forum.altlinux.org/index.php?topic=41811.0
(В ответ на комментарий №21) > В р8. nfs-clients-1.3.4-alt1 > нет службы nfs-idmapd. В пакете nfs-server есть. > Без нее при монтировании Nfs шары владелец отображается 4294967294 вместо имени > пользователя домена > Если установить пакет nfs-server и вручную запустить службу nfs-idmapd то > владелец отображается корректно. Можно добавить эту службу в пакет клиента? > подробнее по проблеме на форуме > https://forum.altlinux.org/index.php?topic=41811.0 Добрый день! Описанная Вами на форуме проблема была решена в задании: http://git.altlinux.org/tasks/216694/logs/events.3.1.log которое находится в состоянии тестирования в отделе качества. Инструкция по использованию FreeIPA Automount NFS будет опубликована на https://www.altlinux.org PS В данном случае используется не nfs-idmapd.service, а nfsidmap(5), а "4294967294" - "nobody". Спасибо за обращение!
У меня больше проблем не наблюдается. Открывайте отдельные баги, если что.
