Bug 117251 - rpc.statd is not started on boot by /etc/init.d/nfslock
rpc.statd is not started on boot by /etc/init.d/nfslock
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nfs-utils (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2004-03-01 21:10 EST by ara howard
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:29:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ara howard 2004-03-01 21:10:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
there appears to be a dependancy issue starting /etc/init.d/nfslock on

- rpc.statd is not started on boot, but the /var/lock/subsys/nfslock
file is created.  this suggests a bug in /etc/init.d/functions::daemon

- rpc.statd can be started (with restart) after a normal boot

- prc.statd will be started normally if the run level is moved to, for
example, 99 and the machine is rebooted

all the above suggest a dependancy issue but i cannot say more.  as it
is the failure to start rpc.statd means any application requiring nfs
safe locks (fcntl) will fail with errno ENOLCK.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. reboot
2. change to a nfs mounted directory
3. run any program which uses fctnl based locks, eg

  #include <stdlib.h>
  #include <stdio.h>
  #include <sys/types.h>
  #include <sys/stat.h>
  #include <fcntl.h>
  #include <unistd.h>
  main (argc, argv)
       int argc;
       char **argv;
    char path[42];
    int fd;
    struct flock lock;
    sprintf (&path[0], "nfslockXXXXXX");
    if ((fd = mkstemp (&path[0])) == -1)
        fprintf (stderr, "mkstemp failed with %d\n", fd);
        return EXIT_FAILURE;
    lock.l_type = F_RDLCK;
    lock.l_whence = SEEK_SET;
    lock.l_start = lock.l_len = 0L;
    return(fcntl (fd, F_SETLKW, &lock));

(compile with and run 'a.out || echo 'nfslocking failed!')

Actual Results:  failure

Expected Results:  success

Additional info:

i looked into the script only sofar as to determine that that call to
'daemon' results in a $RETVAL of 0 and so the lock file is touched,
yet no rpc.statd is running.  i assume that rpc.statd was not started
(do not know why) AND that daemon returns ?$==0 for this condition
(which it should not)
Comment 1 Ken Snider 2004-09-24 15:04:36 EDT
I can verify this behaviour as well. for some reason, on boot,
rpc.statd does *not* start, but does write the /var/lock/subsys file.

This is with the RHEL3U3 nfs-utils errata.
Comment 2 Ken Snider 2004-11-24 10:59:10 EST
As you can see, it seems a "start" fails (including at startup), but a
"restart" works!

[root@buildlinux3.dw root]# chkconfig --list | grep nfslock
nfslock         0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@buildlinux3.dw root]# service nfslock status
rpc.statd is stopped
[root@buildlinux3.dw root]# service nfslock start
[root@buildlinux3.dw root]# service nfslock status
rpc.statd is stopped
[root@buildlinux3.dw root]# service nfslock restart
Stopping NFS statd:                                        [FAILED]
Starting NFS statd:                                        [  OK  ]
[root@buildlinux3.dw root]# service nfslock status
rpc.statd (pid 3610) is running...
Comment 3 Steve Dickson 2004-11-26 21:38:08 EST
Is there any type of log message in /var/log/messeags
that explains why statd is failing?
Comment 4 RHEL Product and Program Management 2007-10-19 15:29:30 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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