#30707 – Непонятки с работой под systemd

Bug 30707 - Непонятки с работой под systemd

Summary: Непонятки с работой под systemd

Status:	CLOSED WORKSFORME

Alias:	None

Product:	Sisyphus
Classification:	Development
Component:	nfs-clients (show other bugs)
Version:	unstable
Hardware:	all Linux

Importance:	P3 normal
Assignee:	Sergey Bolshakov
QA Contact:	qa-sisyphus

URL:
Keywords:	systemd

Depends on:
Blocks:	32420
	Show dependency tree

Reported:	2015-02-06 21:10 MSK by Evgenii Terechkov
Modified:	2018-12-05 16:06 MSK (History)
CC List:	4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description

Evgenii Terechkov 2015-02-06 21:10:17 MSK

После обновления 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.
=========================================================

Comment 1

Sergey Bolshakov 2015-02-06 22:20:14 MSK

а, да, он в -server попал, нужно бы переложить.
во вообще, не в нём дело (написано же -- ignoring).
вот это вот по существу:
rpc.statd[2680]: failed to create RPC listeners ...
что там, ещё один был запущен ?

Comment 2

Evgenii Terechkov 2015-02-06 22:43:57 MSK

Может быть, это последствие жесткой перезагрузки машины (см. 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.

Comment 3

Evgenii Terechkov 2015-02-06 23:04:01 MSK

Ну т.е. я делал systemctl restart rpc-statd, но это не дало результатов, юнит так и висел в failed.

Пришлось откатиться на 1.3.2-alt0.4

Comment 4

Sergey Bolshakov 2015-02-06 23:11:51 MSK

что, собственно, происходит, если запустить руками ?
/sbin/rpc.statd -F -d --no-notify

Comment 5

Sergey Bolshakov 2015-02-06 23:27:42 MSK

systemctl status rpcbind ?

Comment 6

Evgenii Terechkov 2015-02-07 15:54:59 MSK

(В ответ на комментарий №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 ~ #
===========================================================

Comment 7

Sergey Bolshakov 2015-02-07 16:02:51 MSK

rpcbind должен быть включен

Comment 8

Evgenii Terechkov 2015-02-07 16:11:52 MSK

Кстати, обновление до nfs-clients-1:1.3.2-alt2 100% ведёт к неработоспособности
systemd (уже второй раз подряд, #30708). Непонятно, что же он такое страшное
делает.

Comment 9

Evgenii Terechkov 2015-02-07 16:20:18 MSK

Действительно, enable rpcbind + start rpcbind + restart rpc-statd помогли. Но я не выключал rpcbind в /etc/systemd и не понимаю, почему это работало в alt0.4 и почему если кому-то нужен запущенный rpcbind, он не затребовал это в своём юнит-файле.

Comment 10

Sergey Bolshakov 2015-02-07 16:38:37 MSK

"включен" неподходящее слово.
он должен быть запущен -- для этого есть socket activation,
ч-з multi-user.target -> basic.target -> sockets.target -> rpcbind.socket

Comment 11

Evgenii Terechkov 2015-02-07 16:58:58 MSK

Что-то я так и не понял, кто в этой цепочке что сделал не так, что нужное оказалось незапущено в alt2, но видимо запущено в alt0.4 (т.к. монтирование работало).

Comment 12

Sergey Bolshakov 2015-02-07 17:47:00 MSK

для работы rpc.statd нужен запущенный rpcbind,
причём делать systemctl enable rpcbind не требуется.
если же нужно простое монтирование (kerberos не используется,
на сервере умеют NFSv4), то ничего из обсуждаемого
не нужно вообще.

Comment 13

Evgenii Terechkov 2015-02-07 18:43:17 MSK

Я столкнулся с тем, что:

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 то при следующей загрузке автомонтирование работает.

Я сделал что-то не так или чего-то не сделал?

Comment 14

Sergey Bolshakov 2015-02-07 19:28:00 MSK

произошло следующее: наши самописные юниты
были заменены на апстримные, при этом:
старый nfslock.service  хотел (requires) rpcbind.service,
новому rpc-statd.service достаточно rpcbind.target, который
предоставляется rpcbind.socket.
если, как утверждается,  socket activation для rpcbind не работает,
и нужно явно его включать, то я хотел бы узнать, как этого
(не-работает-через-сокет) добиться.

Comment 15

Sergey Bolshakov 2015-02-07 19:43:35 MSK

собственно, нелья ли увидеть содержимое (ls)
/etc/systemd/system/multi-user.target.wants ?

Comment 16

Evgenii Terechkov 2015-02-07 19:48:03 MSK

(В ответ на комментарий №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
=========================================================

Comment 17

Sergey Bolshakov 2015-02-08 00:12:29 MSK

в общем, я не вижу хорошего решения -- блюсти совместимость
со старой sysv'шной схемой разбивки по сервисам получается плохо,
не соблюдать -- технически сложно (post_service и вот это всё).
беру таймаут, а пока могу повторить рекомендацию выключить
nfslock/rpcbind, использовать NFSv4 (собственно, нужно прилагать
усилия, чтобы его _не_ использовать), заодно выкинуть autofs,
systemd'шный аналог вполне справляется.

к

Comment 18

Evgenii Terechkov 2015-02-08 07:24:15 MSK

Попробую посмотреть касательно NFSv4.

Только что имеется ввиду под systemd-шным аналогом? man что?

Comment 19

Sergey Bolshakov 2015-02-08 12:30:33 MSK

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

Comment 20

Alexey Shabalin 2015-06-01 21:55:19 MSK

Дело в следующем.
Поумолчанию, клиент монтирует ресурс с опцией 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
все равно лучше перенести в пакет с клиентом.

Comment 21

dezzzm 2018-11-12 05:11:25 MSK

В р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

Comment 22

Stanislav Levin 2018-12-05 11:20:56 MSK

(В ответ на комментарий №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".

Спасибо за обращение!

Comment 23

Evgenii Terechkov 2018-12-05 16:06:12 MSK

У меня больше проблем не наблюдается. Открывайте отдельные баги, если что.