Re: [PATCH nfs-utils] nfs-server-generator: avoid using external services.

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]

On Wed, Nov 02 2016, Steve Dickson wrote:

> Hello,
>
> On 10/13/2016 02:50 AM, NeilBrown wrote:
>> 
>> nfs-server-generator is run very early when a lot of services
>> are not yet started, so it mustn't depend on them.
>> Currently it can try to use hostname lookup and syslog.
>> 
>> Hostname-lookup is not needed, as we don't use the host issue,
>> and sending message to stderr is sufficient for the generator.
>> 
>> Disabling syslog is easy - call a function that sets a static variable.
>> 
>> Disabling hostname lookup isn't quite so easy, so add a static variable
>> which can be set to disable it.
>> 
>> Signed-off-by: NeilBrown <neilb@suse.com>
>> ---
>> 
>> hi,
>>  I contemplated passing another arg to export_read() and export_d_read()
>>  to resolve this, but it didn't seem worth it.
>> 
>>  Is this approach OK to people?
> It's not the most eloquent interface I've 
> ever seen... ;-) 
>
> What are the failures this is fixing? When a
> hostname lookup is done what happens? Failure
> hangs stopping the server from coming up?

 I never actually reproduced it myself, but I think that when hostname
 lookup failed (possibly after a timeout) it tried to log an error via
 syslog and writing to syslog blocked indefinitely.
 The systemd.generator manpage explicitly rules out trying to talk to
 syslog.


>
>  
>> 
>> Thanks,
>> NeilBrown
>> 
>> 
>>  support/export/export.c        | 12 ++++++++++--
>>  support/include/exportfs.h     |  1 +
>>  systemd/nfs-server-generator.c |  4 ++++
>>  3 files changed, 15 insertions(+), 2 deletions(-)
>> 
>> diff --git a/support/export/export.c b/support/export/export.c
>> index 0b8a858c2c74..c65dc8807a4e 100644
>> --- a/support/export/export.c
>> +++ b/support/export/export.c
>> @@ -67,6 +67,14 @@ static void warn_duplicated_exports(nfs_export *exp, struct exportent *eep)
>>  	}
>>  }
> If we do have to stay with this approach, 
> I definitely think comment explaining
> why its needed and what it does.

That's sensible.  I'll resend with some nice friendly comments.

>
> Finally, on an unrelated issue I'm seeing 
> SELinux preventing nfs-server-generator from 
> accessing nfs-server.service.d/order-with-mounts.conf
> because of a labeling issue. I guess the label
> should be nfsd_unit_file_t not systemd_unit_file_t

I wouldn't know about that :-(

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]