Home » forums » Imported debian.org Mailing Lists » Debian User

Waking up server during boot prevents NFS mounts after upgrade to etch

Tags:

Because my server is not running all the time, clients that want to
mount NFS volumes use a small initscript during boot to wake up the
server if necessary. After upgrading the clients from sarge to etch,
mounting NFS volumes does not work anymore if the server wasn't up already.

The initscript is called /etc/rcS.d/S41wakeupserver during boot, i.e.
after networking and before portmap and mountnfs.sh. It uses ping to
wait until the network is accessible. Then, if ping still fails because
the server does not respond, wakeonlan is used to wake up the server.
Then, again ping is used to wait until the server responds - or the
operation times out.

I understand that in etch, NFS mounts are performed as soon as the
interface becomes available. But disabling asynchronous mounts
(ASYNCMOUNTNFS=no) does not help. It just keeps the clients from waiting
for 90 seconds before giving up on the NFS mounts.

It takes the server about 1 minute to boot. If the server is up before
the client boots, NFS mounts work fine. With or without asynchronous
mounting. So, may be I have some sort of a timing problem?

What has changed from sarge to etch that makes my NFS mounts fail? How
do I have to change my initscript?

Thanks in advance, Malte

--

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Magnoliacom
  • Newsvine
  • Furl
  • Google
  • Yahoo
  • Technorati
0
‹ unable to mount root fs on unknown--block(0,0) Support For ATI Sapphire Radeon Graphics Card ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Waking up server during boot prevents NFS mounts after upgrade t

Submitted by Bob Proulx on Fri, 2007-06-22 18:00.

Malte Forkel wrote:
> After upgrading the clients from sarge to etch, mounting NFS volumes
> does not work anymore if the server wasn't up already.

I think that should be considered a bug. Traditional behavior should
have the clients block waiting for the server to come online and then
continue normally after that. If you agree then please file a bug.

This might help. Are you aware of the NFS mount option 'bg'?

bg
If the first NFS mount attempt times out, retry the mount in the
background. After a mount operation is backgrounded, all
subsequent mounts on the same NFS server will be backgrounded
immediately, without first attempting the mount. A missing mount
point is treated as a timeout, to allow for nested NFS mounts.

This is a traditional method of breaking circular dependencies. But
it might help as a workaround to the behavior that you are reporting.

> It takes the server about 1 minute to boot. If the server is up before
> the client boots, NFS mounts work fine.

Lots of things changed. I did not try to recreate your bad behavior
but it reads like a bug to me.

> With or without asynchronous mounting. So, may be I have some sort
> of a timing problem?

Using sync versus async is completely different and unrelated. That
has to do with the protocol used after the clients have mounted.

Bob

--

»

Waking up server during boot prevents NFS mounts after upgrade t

Submitted by Malte Forkel on Sat, 2007-06-23 13:00.

Bob Proulx schrieb:
> This might help. Are you aware of the NFS mount option 'bg'?
>
> bg
> If the first NFS mount attempt times out, retry the mount in the
> background. After a mount operation is backgrounded, all
> subsequent mounts on the same NFS server will be backgrounded
> immediately, without first attempting the mount. A missing mount
> point is treated as a timeout, to allow for nested NFS mounts.

No, I wasn't. Thanks! After adding the 'bg' option, the NFS mounts work
again. Results depend on ASYNCMOUNTNFS. With ASYNCMOUNTNFS=no, I get

13:26:08 2007: Starting portmap daemon....
13:26:09 2007: mount to NFS server 'spiro' failed.
13:26:09 2007: mount: backgrounding "spiro:/var/lib/video.00"
13:26:09 2007: mount: backgrounding "spiro:/var/lib/video.01"
13:26:09 2007: mount: backgrounding "spiro:/var/lib/video.02"

The volumes get mounted eventually, but too late for a program that is
started later during the init process and wants to scan the mounted volumes.

With ASYNCMOUNTNFS=yes, the etch default, I get

13:48:54 2007: Starting portmap daemon...Already running..
13:48:54 2007: Waiting for /var/lib/video.00...done.
13:49:13 2007: Waiting for /var/lib/video.01...done.
13:49:15 2007: Waiting for /var/lib/video.02...done.

and the volumes are mounted right away. So this is what I do now.

> Using sync versus async is completely different and unrelated. That
> has to do with the protocol used after the clients have mounted.

I guess you are talking about something other than the value of
ASYNCMOUNTNFS, which is what I meant? Sorry, I probably used the wrong
terms.

I'm not quite sure whether to file a big report. In the end its my
initscript that causes the problem. On the other hand, without waking up
server there wouldn't be any mounts at all :-)

Malte

--

»

Waking up server during boot prevents NFS mounts after upgrade t

Submitted by Bob Proulx on Sun, 2007-06-24 23:00.

Malte Forkel wrote:
> No, I wasn't. Thanks! After adding the 'bg' option, the NFS mounts work
> again. Results depend on ASYNCMOUNTNFS.

This is probably related:

http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2006-November/000923.html

"It is useful to disable this on machines with the root file system in
NFS until ifup from ifupdown work proberly in such setup."

I did not research this problem to root cause but on the surface it
appears that it is related to your issue.

> The volumes get mounted eventually, but too late for a program that is
> started later during the init process and wants to scan the mounted volumes.

Right. That is a bad side-effect. Instead the client should block
and wait for the server.

> With ASYNCMOUNTNFS=yes, the etch default, I get
>
> 13:48:54 2007: Starting portmap daemon...Already running..
> 13:48:54 2007: Waiting for /var/lib/video.00...done.
> 13:49:13 2007: Waiting for /var/lib/video.01...done.
> 13:49:15 2007: Waiting for /var/lib/video.02...done.
>
> and the volumes are mounted right away. So this is what I do now.

Glad to hear that the default is the one that works for you.

> >Using sync versus async is completely different and unrelated. That
> >has to do with the protocol used after the clients have mounted.
>
> I guess you are talking about something other than the value of
> ASYNCMOUNTNFS, which is what I meant? Sorry, I probably used the wrong
> terms.

I thought you were talking about the sync/async option. See this
reference for more information.

http://nfs.sourceforge.net/nfs-howto/ar01s05.html#sync_versus_async

> I'm not quite sure whether to file a big report. In the end its my
> initscript that causes the problem. On the other hand, without waking up
> server there wouldn't be any mounts at all :-)

I think this would be covered by the 'initscripts' package. You may
want to look to see if this is already reported in the BTS.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=initscripts;dist=unstable

Bob

--

»

Waking up server during boot prevents NFS mounts after upgrade t

Submitted by Malte Forkel on Tue, 2007-06-26 06:00.

Bob Proulx schrieb:
> This is probably related:
>
> http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2006-November/000923.html
>
I agree. Unfortenately, ASYNCMOUNTNFS=no does not give me quite "the old
init.d/mountnfs.sh behaviour" as advertised in the changelog.

>>> Using sync versus async is completely different and unrelated. That
>>> has to do with the protocol used after the clients have mounted.
>> I guess you are talking about something other than the value of
>> ASYNCMOUNTNFS, which is what I meant? Sorry, I probably used the wrong
>> terms.
>
> I thought you were talking about the sync/async option. See this
> reference for more information.
>
> http://nfs.sourceforge.net/nfs-howto/ar01s05.html#sync_versus_async
>
Now I got it. So sync/async is a server export option while
ASYNCMOUNTNFS is a client init option.

>> I'm not quite sure whether to file a big report. In the end its my
>> initscript that causes the problem. On the other hand, without waking up
>> server there wouldn't be any mounts at all :-)
>
> I think this would be covered by the 'initscripts' package. You may
> want to look to see if this is already reported in the BTS.
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=initscripts;dist=unstable
>
I guess, I'll file a bug report for initscripts. They seem to have a
couple of problems on their hands already at the moment.

BTW: Nice hints on your website, Bob. I now have a .hushlogin :-) And
thanks again for your help.

Malte

--

»

Re: Waking up server during boot prevents NFS mounts after upgra

Submitted by emadwh2 on Fri, 2008-09-05 04:53.

Sorry for double posting

»
Syndicate content