On 11/01/2016 03:55 PM, NeilBrown wrote: > 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@xxxxxxxx> >>> --- >>> >>> 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. This makes sense... > > >> >> >>> >>> 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. Thanks! > >> >> 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 :-( I'll figure this out... steved. > > Thanks, > NeilBrown > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
