hello brandon here's the bug report: a problem with the nfs server. *Exporting NFS directories... /sbin/runscript.sh: line 13: 6740 Killed /sbin/exportfs -r 1>&2 when i'm running: #/sbin/exportfs -r 1>&2 on the console after the system is started, all exports are exported without errors. i have taken a look at the init script and have seen, that there is a line with 5 sec sleep. i have set this up to 20 secs and then the system starts normal and exports all dirs correct. hanez... ;-)
hello all who have seen this bug or having the same problems, in december last year i had some problems while compiling software. first i thoght it was a memory error but running memtest didn't show me any errors. after asking in the dev mailinglist i got an answer and found out that the problem my kernel is. i don't want to tell more about it because it's "off-topic". i decided to take one RAM out of my system because this was taken from an older computer and couldn't find any other thing that could be the problem. after that i compiled a new kernel and my system was running again without any problems. before i could not compile with any compiler because the system segfaults and every time i ran "emerge rsync" the system segfaults too... now my system is working fine again since two weeks or something like that, so i decided to build my RAM - that is laying around - in the computer again. after building the memory into the computer i started the system and it seems that everything works fine until the moment where gentoo ist trying to export the nfs directories... i have the same problem again, that i have reported here allready and i found no way to export the dirs so i decided to take the RAM out of the computer again and hep, everything is working fine again... i don't know if this is the real problem but i think it is. maybe they did not have the same bus frequency so this maybe could be the problem. i could defenitly say, that my system is running without any errors now. well, this is maybe not the right place to talk about this problem but i have posted the bug, so i only wanna say what things happen on my system... kind regards johannes
I know you are working on some init scripts so maybe you will have a better idea than I did on how to handle this (if it is even still an issue)
The bug seems to manifest when the nfs service was brought down with a lot of connected clients. When it starts, it runs through xtab. If the list in xtab is large, it will take more than the default 5 seconds to clear it. Setting the timeout in the init to 20 should be the only thing required for the fix.
I have fixed the fix of this slightly so the kill command is run in the background and we are only waiting for exportfs to finish, The change is: ebegin "Reloading /etc/exports" $exportfs -r 1>&2 & + pid=$! + ( sleep 30; kill -9 $pid &>/dev/null ) & + wait $pid - ( sleep 30; kill -9 $! &>/dev/null & ) - wait eend $? "Error exporting NFS directories" The only problem (small) is that kill will try to kill a finished process most of the time, but this ok unless you plan on starting 1000's of processes in a few seconds. Stefan
I apologise for commenting on a closed bug, but it seems that this is being approached from the wrong angle. The reason that the delay is required, is because exportfs does (reverse) DNS lookups on hostnames and IPs in /etc/exports, which, if a DNS server takes a long time to respond, can mean that exportfs takes a *very* long time to complete. If you add the IPs or hosts that aren't known to your DNS server, to your /etc/hosts file, exportfs will complete almost immediately. Irrelevant of this, exportfs reads and parses /etc/exports within the first (few) second(s) of execution, so if there is a fatal error, chances are it will happen then. I therefore suggest that the init script runs exportfs, waits for 2-3 seconds, then if it hasn't exited with an error, background exportfs and return success. Waiting for DNS lookups really isn't something I want delaying the bootup of my server. Does this make sense? If so I'll post a patch.
MAL, makes sense to me. Please post a patch and we'll consider taking it
Patch at bug #60027
Ok, closing this one then
