Date: Fri, 1 Jun 2001 03:02:11 -0700 (PDT) From: Jean-Luc.Richier@imag.fr To: freebsd-gnats-submit@FreeBSD.org Subject: misc/27810: rpc.statd can loop Message-ID: <200106011002.f51A2B403059@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 27810
>Category: misc
>Synopsis: rpc.statd can loop
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Jun 01 03:10:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Jean-Luc Richier
>Release: FreeBSD5.0 current
>Organization:
IMAG
>Environment:
FreeBSD lagavulin.imag.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Wed May 30 20:25:18 MEST 2001
>Description:
When a host restarts after a crash, its rpc.statd daemon contacts
rpc.statd on other machines to inform them of recovery. But in some
cases the other machine (when FreeBSD) does not answer, therefore the
first rpc.statd deamon tries forever (24h) to make contact. This causes syslog
syslog error messages:
Jun 1 11:15:36 lagavulin rpc.statd: Failed to contact rpc.statd at host lagavulin.imag.fr
Jun 1 11:16:26 lagavulin rpc.statd: Failed to contact rpc.statd at host lagavulin.imag.fr
Jun 1 11:18:06 lagavulin last message repeated 2 times
Jun 1 11:27:26 lagavulin last message repeated 9 times
This bug is in all FreeBSD releases, but with the apparition of
nfs locking in FreeBSD5.0, rpc.statd is now useful to run
>How-To-Repeat:
This is a test run, but I saw the problem first on real cases.
On a FreeBSD machine (say xxx.imag.fr), compile the test rpc.statd
program
cd /usr/src/usr.sbin/rpc.statd
cc -o test test.c -lrpcsvc
Do the following sequence
- kill any running rpc.statd, rpc.lockd
- rm /var/db/statd.status
- rpc.statd
- /usr/src/usr.sbin/rpc.statd/test xxx.imag.fr
- kill rpc.statd
- rpc.statd
Now you can see two rpc.statd processes running, and messages appear in
/var/log/messages after a few minutes
>Fix:
The problem is that the rpc server function sm_notify_1 in
usr/src/usr.sbin/rpc.statd/procs.c can return void, FALSE (that is NULL)
or &dummy pointer. But if the returned value is NULL the server
dispatcher does not send an answer, and the client will retry forever
To correct: sm_notify_1 should always return a dummy pointer
I suggest the patch
(There is one case in which return(NULL) may be correct, it is the case
of fork error, for future recovery )
*** usr.sbin/rpc.statd/procs.c.DIST Sat Aug 28 06:47:17 1999
--- usr.sbin/rpc.statd/procs.c Fri Jun 1 11:55:58 2001
***************
*** 314,329 ****
{
/* Never heard of this host - why is it notifying us? */
syslog(LOG_ERR, "Unsolicited notification from host %s", arg->mon_name);
! return;
}
lp = hp->monList;
! if (!lp) return (FALSE); /* We know this host, but have no */
/* outstanding requests. */
pid = fork();
if (pid == -1)
{
syslog(LOG_ERR, "Unable to fork notify process - %s", strerror(errno));
! return;
}
if (pid) return (&dummy); /* Parent returns */
--- 314,329 ----
{
/* Never heard of this host - why is it notifying us? */
syslog(LOG_ERR, "Unsolicited notification from host %s", arg->mon_name);
! return (&dummy);
}
lp = hp->monList;
! if (!lp) return (&dummy); /* We know this host, but have no */
/* outstanding requests. */
pid = fork();
if (pid == -1)
{
syslog(LOG_ERR, "Unable to fork notify process - %s", strerror(errno));
! return (NULL); /* no answer, the client will retry */
}
if (pid) return (&dummy); /* Parent returns */
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106011002.f51A2B403059>