From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 39708@debbugs.gnu.org
Subject: bug#39708: nfs-service-type broken: rpc.mountd respawns too quickly
Date: Sat, 07 Mar 2020 22:19:35 -0500 [thread overview]
Message-ID: <8736aj7cu0.fsf@gmail.com> (raw)
In-Reply-To: <87a75azxu2.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 22 Feb 2020 12:05:25 +0100")
Hello Ludovic!
Ludovic Courtès <ludo@gnu.org> writes:
> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> The rpc.mountd service, one of the required services for
>> nfs-service-type, respawns the process quickly until disabled.
>
> Does /var/log/messages contain hints?
herd restart nfs
Service nfs has been stopped.
Service rpc.mountd is currently disabled.
Service nfs depends on rpc.mountd.
Service nfs could not be started.
root@hurd ~# herd stop rpc.mountd
root@hurd ~# herd enable rpc.mountd
Enabled service rpc.mountd.
root@hurd ~# herd status rpc.mountd
Status of rpc.mountd:
It is stopped.
It is enabled.
Provides (rpc.mountd).
Requires (rpc.statd).
Conflicts with ().
Will be respawned.
Last respawned on Sat Mar 07 21:56:43-0500 2020.
root@hurd ~# herd restart nfs
Service nfs is not running.
Service rpc.mountd has been started.
Service nfs has been started.
And then, in /var/log/messages:
Mar 7 21:56:4--8<---------------cut here---------------start------------->8---
Mar 7 22:06:45 localhost shepherd[1]: Service nfs has been stopped.
Mar 7 22:06:45 localhost shepherd[1]: Service rpc.mountd is currently disabled.
Mar 7 22:06:45 localhost shepherd[1]: Service nfs depends on rpc.mountd.
Mar 7 22:06:45 localhost shepherd[1]: Service nfs could not be started.
Mar 7 22:07:05 localhost shepherd[1]: Enabled service rpc.mountd.
Mar 7 22:07:15 localhost shepherd[1]: Service nfs is not running.
Mar 7 22:07:15 localhost shepherd[1]: Service rpc.mountd has been started.
Mar 7 22:07:15 localhost shepherd[1]: Service nfs has been started.
Mar 7 22:07:15 localhost rpc.mountd[25270]: Version 2.4.2 starting
Mar 7 22:07:15 localhost shepherd[1]: Respawning rpc.mountd.
Mar 7 22:07:15 localhost shepherd[1]: Service rpc.mountd has been started.
Mar 7 22:07:15 localhost rpc.mountd[25272]: Version 2.4.2 starting
Mar 7 22:07:15 localhost shepherd[1]: Respawning rpc.mountd.
Mar 7 22:07:15 localhost shepherd[1]: Service rpc.mountd has been started.
Mar 7 22:07:15 localhost rpc.mountd[25274]: Version 2.4.2 starting
Mar 7 22:07:15 localhost shepherd[1]: Respawning rpc.mountd.
Mar 7 22:07:15 localhost shepherd[1]: Service rpc.mountd has been started.
Mar 7 22:07:15 localhost rpc.mountd[25276]: Version 2.4.2 starting
Mar 7 22:07:15 localhost shepherd[1]: Respawning rpc.mountd.
Mar 7 22:07:15 localhost shepherd[1]: Service rpc.mountd has been started.
Mar 7 22:07:15 localhost rpc.mountd[25278]: Version 2.4.2 starting
Mar 7 22:07:15 localhost shepherd[1]: Respawning rpc.mountd.
Mar 7 22:07:15 localhost shepherd[1]: Service rpc.mountd has been started.
Mar 7 22:07:15 localhost rpc.mountd[25280]: Version 2.4.2 starting
Mar 7 22:07:15 localhost shepherd[1]: Service rpc.mountd has been disabled.
Mar 7 22:07:15 localhost shepherd[1]: (Respawning too fast.)
--8<---------------cut here---------------end--------------->8---
> Is rpc.statd running?
herd status rpc.statd
Status of rpc.statd:
It is started.
Running value is 348.
It is enabled.
Provides (rpc.statd).
Requires (rpcbind-daemon).
Conflicts with ().
Will be respawned.
root@hurd ~# pidof rpc.statd
348
So, yes :-)
> Could it be that all these services need to depend on ‘loopback’?
I don't think so, because attempting to restart those services in a
state where the network is live and a loopback interface exists
(127.0.0.1 pings) doesn't change the outcome. Or am I misunderstanding
something?
An interesting fact is that every time 'herd restart rpc.mountd' is run,
the number of running processes of rpc.mountd goes up:
--8<---------------cut here---------------start------------->8---
herd enable rpc.mountd && herd start rpc.mountd && pidof rpc.mountd | wc -w
Enabled service rpc.mountd.
Service rpc.mountd has been started.
6
root@hurd ~# herd enable rpc.mountd && herd start rpc.mountd && pidof rpc.mountd | wc -w
Enabled service rpc.mountd.
Service rpc.mountd has been started.
12
root@hurd ~# herd enable rpc.mountd && herd start rpc.mountd && pidof rpc.mountd | wc -w
Enabled service rpc.mountd.
Service rpc.mountd has been started.
13
root@hurd ~# herd enable rpc.mountd && herd start rpc.mountd && pidof rpc.mountd | wc -w
Enabled service rpc.mountd.
Service rpc.mountd has been started.
19
root@hurd ~# herd enable rpc.mountd && herd start rpc.mountd && pidof rpc.mountd | wc -w
Enabled service rpc.mountd.
Service rpc.mountd has been started.
20
root@hurd ~# herd enable rpc.mountd && herd start rpc.mountd && pidof rpc.mountd | wc -w
Enabled service rpc.mountd.
Service rpc.mountd has been started.
26
--8<---------------cut here---------------end--------------->8---
So, to me it seems to be a problem with Shepherd: it erroneously thinks
the process has died and restart it, while in reality it is still
running fine.
Running the rpc.mountd command manually doesn't exhibit any issue, as I
mentioned in my original report.
Thanks for the help!
Maxim
next prev parent reply other threads:[~2020-03-08 3:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 3:58 bug#39708: nfs-service-type broken: rpc.mountd respawns too quickly Maxim Cournoyer
2020-02-22 11:05 ` Ludovic Courtès
2020-03-08 3:19 ` Maxim Cournoyer [this message]
2020-03-08 3:41 ` Maxim Cournoyer
2020-03-08 4:03 ` Maxim Cournoyer
2020-03-08 4:27 ` Maxim Cournoyer
2020-03-08 11:13 ` Ludovic Courtès
2020-03-08 14:37 ` Maxim Cournoyer
2020-03-08 14:43 ` Ludovic Courtès
2020-03-08 16:59 ` Ricardo Wurmus
2020-03-08 17:29 ` Maxim Cournoyer
2020-03-08 5:39 ` Maxim Cournoyer
2020-03-08 11:21 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8736aj7cu0.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=39708@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).