From: Ditang Chen <chendt.fnst@cn.fujitsu.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>,
Steve Dickson <SteveD@redhat.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"yaoxp@cn.fujitsu.com" <yaoxp@cn.fujitsu.com>
Subject: Re: [PATCH]statd: create statdpath dir if specify the "--with-statdpath=xx" parameter in configure nfs-utils source code
Date: Fri, 6 Jun 2014 11:09:14 +0800 [thread overview]
Message-ID: <539130DA.20804@cn.fujitsu.com> (raw)
In-Reply-To: <CAHQdGtSF0662w=p96qxYFqx1snM8RrAE1Qr8b02ajj6iU6Z3Kg@mail.gmail.com>
On 06/05/2014 10:20 PM, Trond Myklebust wrote:
> On Thu, Jun 5, 2014 at 10:15 AM, Steve Dickson <SteveD@redhat.com> wrote:
>> Hey,
>>
>> On 06/05/2014 08:38 AM, Trond Myklebust wrote:
>>> On Thu, Jun 5, 2014 at 4:14 AM, Ditang Chen <chendt.fnst@cn.fujitsu.com> wrote:
>>>> When configure the nfs-utils source code with "--with-statdpath=/foo" parameter,
>>>> #define NSM_DEFAULT_STATEDIR "/foo" will be generated in support/include/config.h file,
>>>> but Makefile will not create "/foo" dir.
>>>>
>>>> Signed-off-by: chendt.fnst@cn.fujitsu.com
>>>> ---
>>>> Makefile.am | 6 +++---
>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Makefile.am b/Makefile.am
>>>> index ae7cd16..5c9ef44 100644
>>>> --- a/Makefile.am
>>>> +++ b/Makefile.am
>>>> @@ -54,10 +54,10 @@ install-data-hook:
>>>> touch $(DESTDIR)$(statedir)/xtab; chmod 644 $(DESTDIR)$(statedir)/xtab
>>>> touch $(DESTDIR)$(statedir)/etab; chmod 644 $(DESTDIR)$(statedir)/etab
>>>> touch $(DESTDIR)$(statedir)/rmtab; chmod 644 $(DESTDIR)$(statedir)/rmtab
>>>> - mkdir -p $(DESTDIR)$(statedir)/sm $(DESTDIR)$(statedir)/sm.bak
>>>> touch $(DESTDIR)$(statedir)/state
>>>> - chmod go-rwx $(DESTDIR)$(statedir)/sm $(DESTDIR)$(statedir)/sm.bak $(DESTDIR)$(statedir)/state
>>>> - -chown $(statduser) $(DESTDIR)$(statedir)/sm $(DESTDIR)$(statedir)/sm.bak $(DESTDIR)$(statedir)/state
>>>> + mkdir -p $(DESTDIR)$(statdpath)/sm $(DESTDIR)$(statdpath)/sm.bak
>>>> + chmod go-rwx $(DESTDIR)$(statdpath)/sm $(DESTDIR)$(statdpath)/sm.bak $(DESTDIR)$(statedir)/state
>>>> + -chown $(statduser) $(DESTDIR)$(statdpath)/sm $(DESTDIR)$(statdpath)/sm.bak $(DESTDIR)$(statedir)/state
>>>>
>>>
>>> The file 'state' is owned by rpc.statd. Isn't it therefore also
>>> subject to the --with-statdpath modifier?
>> --with-statedir and --with-statdpath are basically the same thing.
>> When --with-statdpath is not specified, its set to the --with-statedir
>> value, that's why this these mkdir,chmod and chown were not needed.
>> But I guess if you do want split out the statdpath from the statedir
>> those mkdir,chmod and chown need to happen.
>>
>>
>>>
>>> At one point, the Fedora RPM packager even used to put it in
>>> /var/lib/nfs/statd (as the manpage says it should) although that seems
>>> to be broken now.
>>>
>> It still does... So does RHEL... We have being going that for years...
>> How is that broken?
>>
>
> My nfs-utils rpms on Fedora seem to be creating /var/lib/nfs/state
> instead of putting it in the statd subdirectory.
>
I tested it on RHEL, the file 'state' subject to the --with-statdpath modifier.
nfs-utils rpms on Fedora/RHEL split out the statdpath from the statedir,configure
with '--with-statdpath=/var/lib/nfs/statd', and creating /var/lib/nfs/state file,
but '/var/lib/nfs/state' seems not to be used, the really be used file is
/var/lib/nfs/statd/state.
I‘ll send another patch to fix it.
>
>
next prev parent reply other threads:[~2014-06-06 3:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 8:14 [PATCH]statd: create statdpath dir if specify the "--with-statdpath=xx" parameter in configure nfs-utils source code Ditang Chen
2014-06-05 12:38 ` Trond Myklebust
2014-06-05 14:15 ` Steve Dickson
2014-06-05 14:20 ` Trond Myklebust
2014-06-06 3:09 ` Ditang Chen [this message]
2014-06-06 3:17 ` Ditang Chen
2014-06-17 18:06 ` Steve Dickson
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539130DA.20804@cn.fujitsu.com \
--to=chendt.fnst@cn.fujitsu.com \
--cc=SteveD@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
--cc=yaoxp@cn.fujitsu.com \
/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.
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 NNTP newsgroup(s).