Re: NFS Problems...
On Thu, Jun 05, 2003 at 01:03:17AM +0200, Bernd Walter wrote: > On Wed, Jun 04, 2003 at 02:21:29PM -0700, jle wrote: > > on HTTPD: (/etc/fstab) > > NFSD:/home2 /home nfs rw,bg 0 0 > ed /etc/fstab > /home2 > s/home/home2/ > w > q Don't exactly do this since that would give you > NFSD:/home22 /home nfs rw,bg 0 0 s/home\>/home2 /jed -- Demographic polls show that you have lost credibility across the board. Especially with those 14 year-old Valley girls. pgp0.pgp Description: PGP signature
Re: NFS Problems...
> > [EMAIL PROTECTED]:~ -13:55:06- # cd ~dkdesign > > -su: cd: /home2/dkdesign: No such file or directory > > Not surprising, because you mounted on /home not /home2. There shouldn't BE a /home2 on HTTPD but I figured out what happened. I copied /etc/group /etc/passwd /etc/pwd.db and /etc/master.passwd from NFSD to HTTPD to sync users and passwords and forgot to edit the home dir with vipw. I just did a global search and replace of /home2 to /home and rebuilt the pwd.db and it mounted fine and apache now serves "public_html" from the users shells. However, on reboot it doesn't mount from /etc/fstab, I have to mount it manually for some reason. So now I'm down to the one NFS problem. on NFSD: (/etc/exports) /home2 -maproot=0 -alldirs httpd on HTTPD: (/etc/fstab) NFSD:/home2 /home nfs rw,bg 0 0 mount NFSD:/home2 /home Works fine until I reboot. Shouldn't it mount by itself like it used to? What am I missing now? Why doesn't HTTPD mount NFSD:/home2 on /home when it reboots? TIA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS Problems...
On Wed, Jun 04, 2003 at 02:21:29PM -0700, jle wrote: > I retired my old p200 fbsd 4.4-stable web server and built a newer box for > it. I used to mount the /home2 dir from my nfs server (fbsd 5.1-current) > to /home on the webserver and it used to work fine but now it doesn't > mount /home2 on /home on boot up. I can manually mount it but then it > gets confused and thinks it's mounted on /home2 when it's not. Evidently > something must have changed since 4.4-S because it worked until today. > > on NFSD: (/etc/exports) > /home2 -maproot=0 -alldirs httpd > > on HTTPD: (/etc/fstab) > NFSD:/home2 /home nfs rw,bg 0 0 > > > mount NFSD:/home2 /home > > [EMAIL PROTECTED]:~ -13:55:06- # cd ~dkdesign > -su: cd: /home2/dkdesign: No such file or directory Not surprising, because you mounted on /home not /home2. > [EMAIL PROTECTED]:~ -13:58:45- # cd /home/dkdesign/ > [EMAIL PROTECTED]:/home/dkdesign -14:02:21- # ls -al > drwxr-xr-x 2 dkdesign dkdesign 512 Mar 13 09:15 public_html/ Yes - that's /home, only /home2 is failing... Works as designed. > >From /var/log/httpd-error.log: > [Wed Jun 4 13:56:45 2003] [error] [client xxx.xxx.xxx.xxx] File does not > exist: /home2/dkdesigns/public_html/ > > I don't get it. Any help? ed /etc/fstab /home2 s/home/home2/ w q -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS Problems...
I retired my old p200 fbsd 4.4-stable web server and built a newer box for it. I used to mount the /home2 dir from my nfs server (fbsd 5.1-current) to /home on the webserver and it used to work fine but now it doesn't mount /home2 on /home on boot up. I can manually mount it but then it gets confused and thinks it's mounted on /home2 when it's not. Evidently something must have changed since 4.4-S because it worked until today. on NFSD: (/etc/exports) /home2 -maproot=0 -alldirs httpd on HTTPD: (/etc/fstab) NFSD:/home2 /home nfs rw,bg 0 0 mount NFSD:/home2 /home [EMAIL PROTECTED]:~ -13:55:06- # cd ~dkdesign -su: cd: /home2/dkdesign: No such file or directory [EMAIL PROTECTED]:~ -13:58:45- # cd /home/dkdesign/ [EMAIL PROTECTED]:/home/dkdesign -14:02:21- # ls -al drwxr-xr-x 2 dkdesign dkdesign 512 Mar 13 09:15 public_html/ >From /var/log/httpd-error.log: [Wed Jun 4 13:56:45 2003] [error] [client xxx.xxx.xxx.xxx] File does not exist: /home2/dkdesigns/public_html/ I don't get it. Any help? TIA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS problems with movemail
[-current from 04/21 ] After I upgraded from a current dated approx 04/15 to current from 04/21, my movemail stopped working on NFS mounted partitions (i use XEmacs and VM for mail). I tested it out and it works fine on local partitions. My normal NFS server is a FreeBSD 3.4-stable box. I also tried using a NFS server that was a solaris 2.7 box. Same results. Movemail works fine when the client is a 4.3 RC2 box talking to the 3.4-stable NFS server. [I even compiled movemail from ports in order to check whether this would solve the problem, but no dice] Any ideas? Thanks Viren -- Viren R. Shah Man's Greatest Asset is... ...an unsettled mind To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: we still have NFS problems in -current?
:>
:> I found it. The problem was introduced when we committed the
:> mmap() zero-invalid-areas patch. !...@#$@#$#$%...@%@#%#@ NFS is such
:> a fragile piece of junk!
:
:Why do you say that? :-)
What it come down to is that due to the way m->valid is set, it is possible
for mmap() to believe that a page is entirely valid when, in fact, it
isn't, because partial NFS I/O must set the valid and dirty bits in the
vm_page_t 'inclusively'.
So, for example, if a page contains valid data from offsets 130-4095,
vm_page_t->valid will still be VM_PAGE_BITS_ALL ( 0xFF ) rather then 0xFE.
This causes mmap() to believe that the page is entirely valid when it
isn't.
Before we zerod out invalid areas the 'stale' data from a prior partial
write, e.g. say a write from offset 0 through 120, would stick around in
the buffer. Hence, no crash.
Now the data doesn't necessarily stick around. The write is committed,
the valid bit is clear, the new write to offsets 130-4095 sets the valid
bits again and clears the 'stale' data.
I'm working on a patch. Sigh. I think we may have to implement a
'completely valid' flag for vm_page_t rather then depend on comparing
m->valid against VM_PAGE_BITS_ALL. What a mess.
For now, turn off the mmap zeroing fix. The patch is included below.
-Matt
Matthew Dillon
Index: vm/vm_page.c
===
RCS file: /home/ncvs/src/sys/vm/vm_page.c,v
retrieving revision 1.129
diff -u -r1.129 vm_page.c
--- vm_page.c 1999/04/05 19:38:29 1.129
+++ vm_page.c 1999/04/12 21:22:28
@@ -1491,11 +1491,13 @@
if ((frag = base & ~(DEV_BSIZE - 1)) != base &&
(m->valid & (1 << (base >> DEV_BSHIFT))) == 0
) {
+#if 0
pmap_zero_page_area(
VM_PAGE_TO_PHYS(m),
frag,
base - frag
);
+#endif
}
/*
@@ -1509,11 +1511,13 @@
if ((frag = endoff & ~(DEV_BSIZE - 1)) != endoff &&
(m->valid & (1 << (endoff >> DEV_BSHIFT))) == 0
) {
+#if 0
pmap_zero_page_area(
VM_PAGE_TO_PHYS(m),
endoff,
DEV_BSIZE - (endoff & (DEV_BSIZE - 1))
);
+#endif
}
/*
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: we still have NFS problems in -current?
On Mon, 12 Apr 1999, Matthew Dillon wrote: > :Probably- but this is sure amusing (not!): > : > :Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine: > : > : > : > :cd9660_bmap.o: file not recognized: File format not recognized > :*** Error code 1 > > I found it. The problem was introduced when we committed the > mmap() zero-invalid-areas patch. !...@#$@#$#$%...@%@#%#@ NFS is such > a fragile piece of junk! Why do you say that? :-) Bob Lyon still says: +Date: Mon, 22 Mar 1999 22:00:47 -0800 +From: Bob Lyon +To: mja...@feral.com +Subject: Re: NFS - Will it ever be fixed? (fwd) + + +NFS is perfect. It needs no fixing. (Unless, we mean +"fix" as in what we do to dogs. + +/Bob > > NFS is doing some illegal shit. I'll get a patch out ASAP. Awesome. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: we still have NFS problems in -current?
:Probably- but this is sure amusing (not!): : :Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine: : : : :cd9660_bmap.o: file not recognized: File format not recognized :*** Error code 1 I found it. The problem was introduced when we committed the mmap() zero-invalid-areas patch. !...@#$@#$#$%...@%@#%#@ NFS is such a fragile piece of junk! NFS is doing some illegal shit. I'll get a patch out ASAP. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
we still have NFS problems in -current?
Probably- but this is sure amusing (not!): Compiling a kernel... directory is NFS mounted on a solaris 2.6 machine: cd9660_bmap.o: file not recognized: File format not recognized *** Error code 1 Stop. quarm.feral.com > file cd9660_bmap.o cd9660_bmap.o: MS Windows COFF Unknown CPU Filesystem 1K-blocks UsedAvail Capacity Mounted on bird:/src/freebsd-current/src4124565 1602999 248032139% /usr/src quarm.feral.com > ls -l cd9660_bmap.o -rw-rw-r-- 1 mjacob 100 890 Apr 12 12:45 cd9660_bmap.o quarm.feral.com > rcp bird:/src/freebsd-current/src/sys/compile/QUARM_CHK/cd9660_bmap.o /tmp quarm.feral.com > file /tmp/cd9660_bmap.o /tmp/cd9660_bmap.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped quarm.feral.com > mv cd9660_bmap.o cd9660_bmap.o.SAVE quarm.feral.com > make cd9660_bmap.o cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf ../../isofs/cd9660/cd9660_bmap.c quarm.feral.com > file cd9660_bmap.o cd9660_bmap.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped quarm.feral.com > cmp cd9660_bmap.o cd9660_bmap.o.SAVE quarm.feral.com > file !$ file cd9660_bmap.o.SAVE cd9660_bmap.o.SAVE: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped Hmmm! Ow! Ow! Ow! FreeBSD quarm.feral.com 4.0-CURRENT FreeBSD 4.0-CURRENT #57: Fri Apr 9 20:17:57 PDT 1999 mja...@quarm.feral.com:/freebsd/FreeBSD-current/sys/compile/QUARM i386 This kernel from sources updated April 9 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nfs problems
Alfred Perlstein writes: >This is freebsd following the NFS spec, please read the mount_nfs >man page for the workaround (hint: intr). In my experience the 'intr' filesystem mount option does not always work. As an example, I am often unable to abort from a hung 'df' when a remote NFS server is down. (Even if my current directory is not NFS-mounted.) This might be a problem specific to 'df', though. Ideally 'df' should check to make sure a remote NFS server is responding (via the NFS null procedure) before trying to get any filesystem info for that filesystem. -- Rahul Dhesi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: nfs problems
On Wed, 31 Mar 1999, Thomas Schuerger wrote: > Hi! > > I'm experiencing serious NFS problems, when > a remote NFS directory (also on FreeBSD) mounted on my > machine goes down for whatever reason (e.g. normal > shutdown). From then on, any processes accessing the mounted > NFS directory (e.g. executing ls or even df) will die and stay > non-removable (kill -9 shows no effect on them!) in the system. > If the remote server goes up again, then sometimes these > processes work again. > > I wonder if this is a general problem of NFS or just a > problem with FreeBSD (haven't checked it with non-current > machines). Any ideas/fixes? This is freebsd following the NFS spec, please read the mount_nfs man page for the workaround (hint: intr). Check out the ORA book on NFS and NIS, it's quite good. -Alfred > > > Ciao, > Thomas. > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Alfred Perlstein - Admin, coder, and admirer of all things BSD. -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/4.0-current To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
nfs problems
Hi! I'm experiencing serious NFS problems, when a remote NFS directory (also on FreeBSD) mounted on my machine goes down for whatever reason (e.g. normal shutdown). From then on, any processes accessing the mounted NFS directory (e.g. executing ls or even df) will die and stay non-removable (kill -9 shows no effect on them!) in the system. If the remote server goes up again, then sometimes these processes work again. I wonder if this is a general problem of NFS or just a problem with FreeBSD (haven't checked it with non-current machines). Any ideas/fixes? Ciao, Thomas. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Still NFS Problems
:In the past 3 weeks I've upgraded from 3.0-release, to 3-stable to 4-current :(as of 4 days ago). I've tried nfs v2 and nfs v3. In all of those :circumstances I end up with programs locking due to write problems. : :I'm no good a debugging, so if someone could hold my hand through this :one... : :Basic problem. .nfs798798 files appearing on server, program on client :locks up in STAT 'D' according to top. The problem only occurs on read / :write mounts (duh..). I only have my home partition writable as of right :now. : :The easiest way to replicate it is to compile something large. i.e. make :world from the client machine. Soon I'll just make my home directory read :only too :) Any ideas? fixes? things I can show you? When this happens, run 'dmesg' on the client. Does it report any problems near the end of the system messages? -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Still NFS Problems
In the past 3 weeks I've upgraded from 3.0-release, to 3-stable to 4-current (as of 4 days ago). I've tried nfs v2 and nfs v3. In all of those circumstances I end up with programs locking due to write problems. I'm no good a debugging, so if someone could hold my hand through this one... Basic problem. .nfs798798 files appearing on server, program on client locks up in STAT 'D' according to top. The problem only occurs on read / write mounts (duh..). I only have my home partition writable as of right now. The easiest way to replicate it is to compile something large. i.e. make world from the client machine. Soon I'll just make my home directory read only too :) Any ideas? fixes? things I can show you? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS Problems
>> This reminds me; do we have a utility to reference wmesg strings back >> to the code that sets them, a la TAGS? Would this be useful? > No, and yes respectively. Okay, I've got an early version written. It's got some fairly substantial TODO's, and needs a fair bit of cleanup. I would appreciate any comments anybody has. -cut here- #! /usr/bin/perl -w # Copyright (c) 1999 Joel Ray Holveck. All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright #notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions and the following disclaimer in the #documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $Id$ # NAME # wtags - generate wchan tag file # # SYNOPSIS # wtags [-cegw] [-v] [path] # # DESCRIPTION # wtags scans a 4.4BSD kernel source tree and creates a database # listing all the wchan's which are explicitly specified to # tsleep(9) or similar functions. This is useful for identifying # where in the kernel a process may be hung. # # The source tree to be searched may be specified with path, or # the current directory is used. Subdirectories are always # scanned, and symbolic links are always followed. # # The options are as follows: # # -c Generate ctags(1)-compatible output. Output is appended # to the file "tags" in the current directory. This file # is typically used with vi(1). # # -e Generate etags(1)-compatible output. Output is appended # to the file "TAGS" in the current directory. This file # is typically used with Emacs(1). # # -g Generate gtags(1)-compatible output. Output is appended # to the file "GSYMS" in the current directory. This file # is typically used with the global(1) tags system by # Shigio Yamaguchi, which may be used with vi(1), Emacs(1), # or other systems. # # -w Generate a native file format (described below). This # format is designed to be easily read by humans or machines, # but no utilities currently use it. -w is the default if # no other output format is specified. # # -v Generate warnings for many cases when a possible call to # tsleep(9) or a related function is found, but a wchan # could not be isolated. There are normally many of these # in correct code; one version of wtags produced 83 such # diagnostics on the 4.4BSD-Lite kernel. See DIAGNOSTICS, # below. # # wtags will only recognize string literals for wchan arguments. # A function (such as lf_setlock) which uses a string constant # instead, or one (such as ttread) which uses one of a few known # possibilities selected via :? or another mechanism, may have a # comment such as /* WCHAN: lockf */ on the line in question. # wtags will then use the indicated channel, and ignore any tsleep # call on that line. # # FILES # /sysTraditional kernel source location # WTAGS Default output file, used with -w or if no other # tag file is specified # TAGSEmacs(1) tags output file, used with -e # tagsvi(1) tags file, used with -c # GSYMS global(1) tags file, used with -g # # DIAGNOSTICS # If the -v option is specified, then whenever tsleep (or another # function that uses wchan) is written in the source file, but no # wchan can be found, a diagnostic is printed. These diagnostics # do not always properly describe the issue. # # There is one exception to this: if the item appears to be a # reference to tsleep from within a comment (using a heuristic), # then no diagnostic is printed. # # SEE ALSO # ps(1), etags(1), ctags(1), global(1), tsleep(9), glimpse(1) # # NOTES # wtags was designed under FreeBSD. Any
Re: NFS Problems
On 23 Feb 1999, Joel Ray Holveck wrote: > >> This reminds me; do we have a utility to reference wmesg strings back > >> to the code that sets them, a la TAGS? Would this be useful? > > No, and yes respectively. > > I have the scanner mostly written; there is one bug yet to fix (This > time for sure!). Presently, it creates a single file WTAGS which > contains an easily-read (my man or machine) flat file index. I will > presently be modifying it to generate Emacs's etags format, as well as > ctags, and as soon as I learn it, GSYMS format. > > At the moment, the scanner scans tsleep, asleep, and ttysleep calls. > What other sleep functions can have the wchan specified as a string > literal? There being no robust manner to handle calls with a computed > or dereferenced wchan, such as acquire(), I will allow for a notation > of /* WCHAN: foo */ to cause the appropriate information to be added > to the database. lockinit() takes a wmesg string which is used when a process sleeps on the lock. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS Problems
>> This reminds me; do we have a utility to reference wmesg strings back >> to the code that sets them, a la TAGS? Would this be useful? > No, and yes respectively. I have the scanner mostly written; there is one bug yet to fix (This time for sure!). Presently, it creates a single file WTAGS which contains an easily-read (my man or machine) flat file index. I will presently be modifying it to generate Emacs's etags format, as well as ctags, and as soon as I learn it, GSYMS format. At the moment, the scanner scans tsleep, asleep, and ttysleep calls. What other sleep functions can have the wchan specified as a string literal? There being no robust manner to handle calls with a computed or dereferenced wchan, such as acquire(), I will allow for a notation of /* WCHAN: foo */ to cause the appropriate information to be added to the database. Thanks, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS Problems
On 22 Feb 1999, Joel Ray Holveck wrote: > >> The program on the client side always freezes (top reports it's > >> STAT as 'D'). > > You need to pass the 'l' switch to ps and look at the 'wchan' column to > > see where it's actually stuck. > > This reminds me; do we have a utility to reference wmesg strings back > to the code that sets them, a la TAGS? Would this be useful? > > Thanks, > joelh Ahem: glimpse! :) > > -- > Joel Ray Holveck - jo...@gnu.org >Fourth law of programming: >Anything that can go wrong wi > sendmail: segmentation violation - core dumped > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS Problems
> >> The program on the client side always freezes (top reports it's > >> STAT as 'D'). > > You need to pass the 'l' switch to ps and look at the 'wchan' column to > > see where it's actually stuck. > > This reminds me; do we have a utility to reference wmesg strings back > to the code that sets them, a la TAGS? Would this be useful? No, and yes respectively. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS Problems
>> The program on the client side always freezes (top reports it's >> STAT as 'D'). > You need to pass the 'l' switch to ps and look at the 'wchan' column to > see where it's actually stuck. This reminds me; do we have a utility to reference wmesg strings back to the code that sets them, a la TAGS? Would this be useful? Thanks, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS Problems
> I update 3-Stable nearly weekly, and have been experiencing the same problem > for quite a while now. NFS imports, on the client side appear to be losing > data. When this occurs, I see .nfs78969 files on the server side. These files exist because they've been deleted but not closed; this is probably just an artifact of the program being stuck. > The > program on the client side always freezes (top reports it's STAT as 'D'). You need to pass the 'l' switch to ps and look at the 'wchan' column to see where it's actually stuck. > Are there some switches I should try? I assume (without testing) that > 4-current would also show the same problems as 3-stable. Which is why I > posted here. There have actually been some changes in 4.0 which might affect this, if I understand correctly. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
NFS Problems
I update 3-Stable nearly weekly, and have been experiencing the same problem for quite a while now. NFS imports, on the client side appear to be losing data. When this occurs, I see .nfs78969 files on the server side. The program on the client side always freezes (top reports it's STAT as 'D'). This occurs regularly. I've tried nfsv3 and nfsv2. Read-only imports do not cause this freezing problem. The affected file often ends up being a size of 0. Are there some switches I should try? I assume (without testing) that 4-current would also show the same problems as 3-stable. Which is why I posted here. The server is 3-stable, clients are 3-stable. In fact, they share /usr, /bin, /sbin, /home and /var/db/pkg. Everything is read only except /home. I'd love to get this thing fixed if someone could point me in any direction at all... To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
>Date: Mon, 1 Feb 1999 14:25:03 +1300
>From: Joe Abley
>Never had a problem with it. Just to confirm that amd is not hideously
>broken beyond the point where _some_ people can use it just fine.
Likewise, though nearly all of our NFS activity is among FreeBSD boxen.
And we use NIS for the amd maps:
pau-amma[1] grep amd /etc/rc.conf
amd_enable="YES"# Run amd service with $amd_flags (or NO).
amd_flags="-nr -k i386 -l syslog -x all"
amd_map_program="ypcat -k amd.master"
Such as
pau-amma[2] ypcat -k amd.n
*
host!=${key};os==freebsd3;type:=host;fs:=${autodir}/${rhost}/root;opts:=vers=2,proto=udp,nosuid,grpid,soft,intr
host!=${key};os!=freebsd3;type:=host;fs:=${autodir}/${rhost}/root;opts:=nfsv2,noconn,nosuid,grpid,soft,intr
host==${key};type:=link;fs:=/
/defaults rhost:=${key}
Urrgh... That's a little ugly. Reformatted:
* host!=${key};os==freebsd3;type:=host;fs:=${autodir}/${rhost}/root;\
opts:=vers=2,proto=udp,nosuid,grpid,soft,intr
host!=${key};os!=freebsd3;type:=host;fs:=${autodir}/${rhost}/root;\
opts:=nfsv2,noconn,nosuid,grpid,soft,intr
host==${key};type:=link;fs:=/
/defaults rhost:=${key}
Basically: if this is the host in question, don't even use NFS; let amd
simulate a symlink. Otherwise, use the release-specific incantation to
force the use of NFS V2/UDP.
And "amd.n" is the map we use for the equivalent of the Sun automounter
"/hosts" map.
Putting the "release-specific incantation" stuff in there managed to
shut am-util's whining about "nfsv2" up.
And using the rel. 1.2 of contrib/amd/libamu/mount_fs.c made it quit
spitting out silly messages about "noconn". (Yes, I also sent a copy of
that patch to the am-utils maintainer.)
david
--
David Wolfskill UNIX System Administrator
d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
< said:
> Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
> environments currently involve one of each (4.0 and 3.0), but I can
> certainly say that in none of these test environments does amd work at
> all.
Works just fine on a somewhat older 3.0 (which is still running the
new amd). Believe me, I would have screamed like hell if both my home
directory and my Web server stopped working... So, clearly, the
kernel <-> amd part works, and so does NFSv2 to a SunOS machine (see
below).
woll...@khavrinen$ ps alwwx | fgrep amd
0 138 1 0 2 0 1004 468 select Ss??4:18.35 amd -p -x
noinfo /net /etc/amd.net /home /etc/amd.home
12369 14676 14668 4 -6 0 932 484 piperd S+p20:00.01 fgrep amd
woll...@khavrinen$ cat /etc/amd.net
/defaults type:=host;fs:=${autodir}/root/${rhost};rhost:=${key}
* opts:=rw,grpid,noexec,nosuid
woll...@khavrinen$ cat /etc/amd.home
/defaults sublink:=${key};opts:=rw,soft,intr
* type:=linkx;fs:=/homes
woll...@khavrinen$ ls -l /home
total 2
lrwxrwxrwx 1 root wheel 15 Jan 31 23:25 postgres@ -> /homes/postgres
lrwxrwxrwx 1 root wheel 14 Jan 31 22:23 wollman@ -> /homes/wollman
lrwxrwxrwx 1 root wheel 10 Jan 31 23:25 www@ -> /homes/www
woll...@khavrinen$ cd /net/tower
woll...@khavrinen$ ls
cdrom/ pcfs/
woll...@khavrinen$ cd pcfs
woll...@khavrinen$ mount
/dev/wd0s1a on / (local, writes: sync 195 async 6628)
/dev/wd0s1d on /var (local, writes: sync 26599 async 47055)
/dev/wd0s1e on /usr (local, writes: sync 69 async 5534)
/dev/wd0s1f on /usr/local (NFS exported, local, writes: sync 1325 async 3876)
/dev/wd0s1g on /homes (local, writes: sync 114203 async 287246)
/dev/wd0s1h on /usr/obj (asynchronous, NFS exported, local, noatime, writes:
sync 2 async 0)
/dev/sd0s1d on /usr/src (NFS exported, local, writes: sync 26974 async 33971)
/dev/sd0s1e on /usr/ports (NFS exported, local, writes: sync 14951 async 56478)
procfs on /proc (local)
pid...@khavrinen:/home on /home
pid...@khavrinen:/net on /net
tower:/cdrom on /a/root/tower/cdrom (noexec, nosuid)
tower:/pcfs on /a/root/tower/pcfs (noexec, nosuid)
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
I've been using amd on bleeding-edge current for the past year or so with
no problems - the servers in my case are Solaris 2.5.1 boxes.
I remember becoming extremely confused when I configured my first amd map
file, since there was no coherent documentation to be found at the time, but
I ended up with this (and have kept it ever since):
% grep amd /etc/rc.conf
amd_enable="YES" # Run amd service with $amd_flags (or NO).
amd_flags="-a /a -c 1800 -k i386 -d clear.net.nz -l syslog /home
/etc/amd.home.map /net /etc/amd.net.map"
amd_map_program="NO" # Can be set to "ypcat -k amd.master"
%
% cat /etc/amd.home.map
# auto-mount home directories
/defaults type:=nfs;rfs=/export/${path};rhost:=oms
jableyrhost:=intdev
* opts:=rw,resvport
%
% cat /etc/amd.net.map
# automount /net hierarchies
/defaults opts:=rw,grpid,resvport,nosuid
buddhatype:=link;fs=/
* type:=host;rhost:=${key}
buddha is the local machine; intdev is where my home directory happens to
be (everybody else's is mounted off oms).
Never had a problem with it. Just to confirm that amd is not hideously
broken beyond the point where _some_ people can use it just fine.
Joe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
> Err On all of the machines where I use amd, I don't use -l syslog. > I use -l /tmp/.automsg (or some other filename that lusers aren't likely You're right, that does produce more information. Unfortunatly, not enough to help diagnose the problem. :( I think something more fundamental is broken here since it doesn't even log the requests you make of it. All you get are the startup messages, then silence forever more. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
> I use -l /tmp/.automsg (or some other filename that lusers aren't likely ..snip.. > I've found that am-utils is much more verbose than previous versions of > amd so you may not want to leave it that way permanently ... /var/log/amd.log and add it to /etc/newsyslog.conf. Since this is what I use, I've considered makeing this the default rather than "-l syslog". -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
Of all the gin joints in all the towns in all the world, Jordan K. Hubbard had to walk into mine and say: > > Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE, > > Amd in 3.0 works for many. I won't defend that the new Amd works the > > best with us, but then neither did the old Amd. > > Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test > environments currently involve one of each (4.0 and 3.0), but I can > certainly say that in none of these test environments does amd work at > all. On freefall, for example, it's really simple to demonstrate the > error. First, we start amd: > > # amd -a /net -c 1800 -k i386 -d freebsd.org -l syslog /host /etc/amd.map Err On all of the machines where I use amd, I don't use -l syslog. I use -l /tmp/.automsg (or some other filename that lusers aren't likely to trip over). You get _MUCH_ more information this way. I strongly suggest trying this and observing the results when you try to automount something. I've found that am-utils is much more verbose than previous versions of amd so you may not want to leave it that way permanently, but you can't beat it for troubleshooting. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
"Jordan K. Hubbard" wrote:
> > Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
> > Amd in 3.0 works for many. I won't defend that the new Amd works the
> > best with us, but then neither did the old Amd.
>
> Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
> environments currently involve one of each (4.0 and 3.0), but I can
> certainly say that in none of these test environments does amd work at
> all. On freefall, for example, it's really simple to demonstrate the
> error. First, we start amd:
>
> # amd -a /net -c 1800 -k i386 -d freebsd.org -l syslog /host /etc/amd.map
> # ps ax | grep amd
> 9127 ?? Is 0:00.01 amd -a /net -c 1800 -k i386 -d freebsd.org -l syslo
g
>
> # cat /etc/amd.map
> /defaults type:=host;fs:=${autodir}/${rhost};rhost:=${key}
> * opts:=rw,grpid,resvport,vers=2,proto=udp,nosuid,nodev,intr
>
I added the vers=2 and proto=udp, "just in case", but it wouldn't work
either way. At one point there was: fs:=${autodir}/${rhost}/host, but
that didn't work either (as /host/hub or /host/hub/host).
> # ls /host/bento
> ls: /host/bento: No such file or directory
>
> But no workee at all. Any ideas? Using only FreeBSD boxes and
> udp/ver2 mounts, amd fails to function as far as I can tell.
It would appear the the NFS interface between the kernel and amd is
working otherwise the accesses to /host would hang. But beyond that I
don't know.
Cheers,
-Peter
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
> Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE,
> Amd in 3.0 works for many. I won't defend that the new Amd works the
> best with us, but then neither did the old Amd.
Erm, I haven't tried it between 3.0 and 3.0 boxes because all my test
environments currently involve one of each (4.0 and 3.0), but I can
certainly say that in none of these test environments does amd work at
all. On freefall, for example, it's really simple to demonstrate the
error. First, we start amd:
# amd -a /net -c 1800 -k i386 -d freebsd.org -l syslog /host /etc/amd.map
# ps ax | grep amd
9127 ?? Is 0:00.01 amd -a /net -c 1800 -k i386 -d freebsd.org -l syslog
# cat /etc/amd.map
/defaults type:=host;fs:=${autodir}/${rhost};rhost:=${key}
* opts:=rw,grpid,resvport,vers=2,proto=udp,nosuid,nodev,intr
# df
..
pid9...@freefall:/host 000 100%/host
# ls /host/hub
ls: /host/hub: No such file or directory
# ls /host/bento
ls: /host/bento: No such file or directory
But no workee at all. Any ideas? Using only FreeBSD boxes and
udp/ver2 mounts, amd fails to function as far as I can tell.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
> > Yes, to be consistent with the state of world WRT NFS. Or at least with > > the leader -- Solaris. This has been the default in 3.0-C since the > > am-utils import. > > Yeah, well, amd is a whole other ball of wax. That's clearly broken > in both 3.0-stable and 4.0-current Why is it clearly broken? proto=tcp,vers=3 is what is in 3.0-RELEASE, Amd in 3.0 works for many. I won't defend that the new Amd works the best with us, but then neither did the old Amd. > and we're going to have to revert the last set of changes fairly soon, > it's on my TODO list of things to deal with. I think we need to do more testing in the environments Amd currently gives trouble to determine if the problem is with using TCP or version 3 of NFS. I still question if there still are problems in our NFS (even with hard mounts) implementation. Also, is the problem FreeBSD between two FreeBSD boxes, or a FreeBSD and say Solaris box. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
> Yes, to be consistent with the state of world WRT NFS. Or at least with
> the leader -- Solaris. This has been the default in 3.0-C since the
> am-utils import.
Yeah, well, amd is a whole other ball of wax. That's clearly broken
in both 3.0-stable and 4.0-current and we're going to have to revert
the last set of changes fairly soon, it's on my TODO list of things to
deal with.
> You could easily still be using TCP rather than UDP. Using "proto=X" and
> "vers=Y" you can specify the version and protocol used, independent of
> each other. X={tcp,udp} and Y={2,3}
> "nfsv2" is an synonym for "proto=udp,vers=2".
Yeah, I think that was in fact the problem here.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
> errors on "current" and checked the amd.conf file it was using.
> Version 3 of NFS seemed to be the default (!) for amd
Yes, to be consistent with the state of world WRT NFS. Or at least with
the leader -- Solaris. This has been the default in 3.0-C since the
am-utils import.
> it to version 2 and rebooted both boxes. Still no change. When
You could easily still be using TCP rather than UDP. Using "proto=X" and
"vers=Y" you can specify the version and protocol used, independent of
each other. X={tcp,udp} and Y={2,3}
"nfsv2" is an synonym for "proto=udp,vers=2".
Any bugs you expose would be of interested, of course.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Even more interesting NFS problems..
In article <91639.917702...@zippy.cdrom.com>, Jordan K. Hubbard wrote: > > As of the day before yesterday, I started getting all manner of NFS > errors on "current" and checked the amd.conf file it was using. > Version 3 of NFS seemed to be the default (!) for amd so I changed > it to version 2 and rebooted both boxes. Still no change. Make sure you're using the right syntax in your amd.map file. It changed a few months ago. Use "proto=udp,vers=2". John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Even more interesting NFS problems..
Scenario: Two machines, releng3.freebsd.org (running 3.0-stable) and current.freebsd.org (running 4.0-current). releng3 has all the disk space and is the NFS server. current is an NFS client and uses releng3 for its CVS repository, FTP snapshot stashing area, etc. As of the day before yesterday, I started getting all manner of NFS errors on "current" and checked the amd.conf file it was using. Version 3 of NFS seemed to be the default (!) for amd so I changed it to version 2 and rebooted both boxes. Still no change. When doing things like a cvs update from current using the cvs repo on releng3, I get this: r...@usw2-> cvup U Makefile.inc1 U Makefile.upgrade ? make.out U bin/rm/rm.1 cvs update: cannot open /home/ncvs/src/contrib/groff/devps/HNI,v: RPC struct is bad That latter message is a new one in my experience. Anyone have any ideas? I might also add that this exact same setup worked great back when current.freebsd.org was running 3.0-current and releng3.freebsd.org was releng22.freebsd.org, running 2.2.8-stable. The only thing I changed were the OS versions and now we're also SNAPless. :-( - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
