Почему Fedora запускала rpc-statd-notify.service, а не rpc-statd.service?
Вы можете запустить вашу программу как пакетное задание, например. используя здесь документ :
batch << EOJ
./yourprogram some $ARGUMENTS
EOJ
Если программа уже была запущена интерактивно, я не вижу общего безотказного решения; например, потому что эта программа может позже начать использовать system(3) (например. system("$EDITOR /tmp/somefile.txt");....) какое-нибудь клиентское приложение X11, или какое-нибудь интерактивное приложение, использующее tty(4)
Если вы можете улучшить эту программу, вы могли бы рассмотреть возможность иметь некоторые аргументы программы, позволяющие вызвать daemon(3)
Вы могли бы также использовать какой-нибудь терминальный менеджер, например screen(1) и т.д....
Судя по всему, mount.nfsпри необходимости организует запуск rpc-statd.serviceпо требованию. Предположительно, это позволяет избежать запуска rpc.statdна клиентах NFSv4, поэтому это означает отсутствие ненужного использования ресурсов и т. д.
$ systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
[Unit]
Description=NFS client services
Before=remote-fs-pre.target
Wants=remote-fs-pre.target
# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
Wants=rpc-statd-notify.service
# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service rpc-svcgssd.service gssproxy.service
[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.target
Похоже, что отсутствие rpc-statdвызовет видимый сбой на клиентах NFS. Таким образом, это будет замечено администратором и исправлено до того, как возникнут какие-либо малозаметные проблемы с блокировкой.
Jul 08 17:24:20 mount[957]: mount.nfs: rpc.statd is not running but is required for remote locking. Jul 08 17:24:20 mount[957]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
https://forums.fedoraforum.org/showthread.php?292563-rpc-statd-starting-after-some-nfs-mounts
Напротив, отсутствующих rpc-statd-notifyможно было легко не заметить,и это может вызвать нежелательные эффекты (устаревшие блокировки )на сервере. Так что, может быть, неплохо иметь что-то, что побуждает его включать...
Похоже, официальной документации Redhat по запуску NFSv3 больше не существует (и Google тоже не очень помогает ). Старые документы в любом случае традиционно включают в себя включение множества служб, и демон rpc.statd, как правило, упоминается как часть этого.
Но я подозреваю, что это несоответствие означает, что люди, скорее всего, включат rpc -statd и упустят необходимость включения rpc -statd -notify. Тем более что похоже, что в прежние времена служба, которая запускала rpc -statd, могла сама выполнять бит уведомления -. Я вижу, что rpc -statd.service устанавливает RPC_STATD_NO_NOTIFY=1.
Таким образом, если nfs-client.targetне запускается автоматически, и в документации нет упоминания об этом как об одной из включенных служб, вышеизложенное кажется слабым оправданием. И это может быть лучше объяснено тем, что он просто стар, заброшен и неряшлив.
Хотя и это не кажется очень убедительным ответом. Должно быть, в какой-то момент была определенная причина для , а не , позволяющая rpc.statd выполнять часть уведомлений самостоятельно.
Note: the sm-notify command contains a check to ensure it runs only once after each system reboot. This prevents spurious reboot notification if rpc.statd restarts without the [--no-notify] option.