Re: rpc.lockd leaking memory on 6.3
In response to Mark Lastdrager [EMAIL PROTECTED]: Recently we updated our main NFS server to FreeBSD 6.3. This machine serves about 10 netboot clients all running FreeBSD 6.2. Since the upgrade we are having some issues with locking. We tried to avoid running the lockd daemons at all but most software on the netboot clients (Apache, Postfix) refuses to run without it. On the 6.3 server rpc.lockd leaks memory, somewhat less than 1 meg per hour. This means that every few days we need to restart the daemon. This is quite annoying because we need to stop/start rpc.lockd on both the server and the clients in a controlled fashion. In most cases also the daemons using locking need to be restarted. Is this a known issue? I could not find a PR for it. Maybe a workaround? I found some recent posts on the -current list about a complete rewrite of the locking mechanism, will this be ported to 6-STABLE in the future? I can't say whether your issue is know, but I do have a suggested workaround until it can be tracked down and fixed. From the mount_nfs man page: -L Do not forward fcntl(2) locks over the wire. All locks will be local and not seen by the server and likewise not seen by other NFS clients. This removes the need to run the rpcbind(8) service and the rpc.statd(8) and rpc.lockd(8) servers on the client. This has been working acceptably for us for a while. I expect it will work for you unless you have applications that rely on locking for actual shared file access. As far as the actual issue ... sounds like you should open a PR. -- Bill Moran http://www.potentialtech.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
rpc.lockd leaking memory on 6.3
Hi, Recently we updated our main NFS server to FreeBSD 6.3. This machine serves about 10 netboot clients all running FreeBSD 6.2. Since the upgrade we are having some issues with locking. We tried to avoid running the lockd daemons at all but most software on the netboot clients (Apache, Postfix) refuses to run without it. On the 6.3 server rpc.lockd leaks memory, somewhat less than 1 meg per hour. This means that every few days we need to restart the daemon. This is quite annoying because we need to stop/start rpc.lockd on both the server and the clients in a controlled fashion. In most cases also the daemons using locking need to be restarted. Is this a known issue? I could not find a PR for it. Maybe a workaround? I found some recent posts on the -current list about a complete rewrite of the locking mechanism, will this be ported to 6-STABLE in the future? Regards, Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd leaking memory on 6.3
Mark Lastdrager wrote: Hi, Recently we updated our main NFS server to FreeBSD 6.3. This machine serves about 10 netboot clients all running FreeBSD 6.2. Since the upgrade we are having some issues with locking. We tried to avoid running the lockd daemons at all but most software on the netboot clients (Apache, Postfix) refuses to run without it. On the 6.3 server rpc.lockd leaks memory, somewhat less than 1 meg per hour. This means that every few days we need to restart the daemon. This is quite annoying because we need to stop/start rpc.lockd on both the server and the clients in a controlled fashion. In most cases also the daemons using locking need to be restarted. Is this a known issue? I could not find a PR for it. Maybe a workaround? I havent seen a report of this behaviour. I found some recent posts on the -current list about a complete rewrite of the locking mechanism, will this be ported to 6-STABLE in the future? Almost certainly not. Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd stalls
On Sep 7, 2006, at 10:34 AM, Tom Ierna wrote: For the purposes of ease of software and hardware management, I'm attempting to run a set of PXE-booted Client machines as web/db or mail servers. It is perhaps reasonable to run a diskless webserver, especially if it is serving mainly dynamically generated content. Trying to run a database server or mail server without a disk strikes me as a very bad idea. I am surprised that rpc.lockd is holding up well enough to only go down about once a month; simply running the locking tests which come with sendmail used to be enough to cause rpc.lockd to crash... Best of luck, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd stalls
On Thu, Sep 07, 2006 at 01:34:08PM -0400, Tom Ierna wrote: Hello, list. For the purposes of ease of software and hardware management, I'm attempting to run a set of PXE-booted Client machines as web/db or mail servers. The NFS/DHCP/YP servers are running on a 5.4-STABLE Server. I mostly followed the PXE guide when building these systems. All of the disk (except for swap) sits on the master Server (which has a bunch of external drive sleds), and all of the Client machines boot via Gig-E. Client machines are running 5.4-STABLE as well, but it is not compiled with the same kernel configuration as the master Server, as the hardware is slightly different. Client machines share userland with the Server. At the moment I have one Client machine running about 40 domains of web and db, with reasonably low traffic (less than 3Mbit/sec total) and one Client machine booted from the master Server, but not doing anything. Resource utilization on the master Server seems pretty low. Sporadically, there appear to be stalls on some locks with rpc.lockd. rpc.lockd is unreliable in all versions of FreeBSD (although it may be worse in 5.x), see the mailing list archives for extensive discussion of this. Try turning it off and using mount_nfs -L instead to fake the lock traffic (See the manpage). Kris pgpYJqMO1v6e5.pgp Description: PGP signature
Re: rpc.lockd stalls
On Sep 7, 2006, at 1:40 PM, Kris Kennaway wrote: On Thu, Sep 07, 2006 at 01:34:08PM -0400, Tom Ierna wrote: Sporadically, there appear to be stalls on some locks with rpc.lockd. rpc.lockd is unreliable in all versions of FreeBSD (although it may be worse in 5.x), see the mailing list archives for extensive discussion of this. Try turning it off and using mount_nfs -L instead to fake the lock traffic (See the manpage). Kris, Is there a way to note -L via fstab? Since these machines are PXE booted, unmounting and re-mounting with -L will be problematic, and I'd like them to inherit this property at reboot. Thanks, -Tom -- Tom Ierna President Shockergroup, Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd stalls
On Thu, Sep 07, 2006 at 02:12:26PM -0400, Tom Ierna wrote: On Sep 7, 2006, at 1:40 PM, Kris Kennaway wrote: On Thu, Sep 07, 2006 at 01:34:08PM -0400, Tom Ierna wrote: Sporadically, there appear to be stalls on some locks with rpc.lockd. rpc.lockd is unreliable in all versions of FreeBSD (although it may be worse in 5.x), see the mailing list archives for extensive discussion of this. Try turning it off and using mount_nfs -L instead to fake the lock traffic (See the manpage). Kris, Is there a way to note -L via fstab? Since these machines are PXE booted, unmounting and re-mounting with -L will be problematic, and I'd like them to inherit this property at reboot. Yes, use the -o format, see the manpage. Kris pgp9m8FlnRVJi.pgp Description: PGP signature
rpc.lockd stalls
Hello, list. For the purposes of ease of software and hardware management, I'm attempting to run a set of PXE-booted Client machines as web/db or mail servers. The NFS/DHCP/YP servers are running on a 5.4-STABLE Server. I mostly followed the PXE guide when building these systems. All of the disk (except for swap) sits on the master Server (which has a bunch of external drive sleds), and all of the Client machines boot via Gig-E. Client machines are running 5.4-STABLE as well, but it is not compiled with the same kernel configuration as the master Server, as the hardware is slightly different. Client machines share userland with the Server. At the moment I have one Client machine running about 40 domains of web and db, with reasonably low traffic (less than 3Mbit/sec total) and one Client machine booted from the master Server, but not doing anything. Resource utilization on the master Server seems pretty low. Sporadically, there appear to be stalls on some locks with rpc.lockd. These lock stalls exhibit interesting behavior on the Client machines: Slots will fill up on Apache in the W state. SSH login attempts to the client machine (passwd files get some user data via YP) will hang and timeout. when I find a file (via Apache's extended status) which appears to be one of the stalled locks, and I attempt to do anything with the file via a shell on the client machine, such as cat it, that shell will become unresponsive. Any process which is stalled on one of these files cannot be killled. On the server, the only symptom I've witnessed is that rpc.lockd starts using a bit more proc than it usually does. Normal utilization is 0.0, and when the problem is happening, proc might go up to 3.0 or so. cating a file on the Server which appears stalled on the Client, works fine. A stop and start of nfslocking on the server seems to clear things up. Apache on the client will recover on its own, I'm guessing after each stalled lock reaches a timeout. I usually gracefully restart Apache, which forces the recovery to happen faster. As far as timing, it doesn't appear to be consistently periodic. It doesn't appear to be load related - I suffered through a Digg of one of the sites, and while the client machine served more bandwidth that couple of days than it had in a month, this particular problem did not occur. Over the past three months or so, this issue has probably cropped up three or four times. What can I do to troubleshoot this? I would like to add more client machines, but I can't until this problem is resolved. Changing OS builds at this point, unless absolutely necessary, is not something I want to do. Thanks for any insight! -- Tom Ierna President Shockergroup, Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd stalls
On Sep 7, 2006, at 1:44 PM, Chuck Swiger wrote: Trying to run a database server or mail server without a disk strikes me as a very bad idea. This is unfortunate - the client machines I have chosen have no front-panel disk sleds. Hardware administration will be a bear if they each have to have their own disks. Software-wise, I was hoping to have them all share a common Kernel and userland too, so I only have to update software in one place. I am surprised that rpc.lockd is holding up well enough to only go down about once a month; simply running the locking tests which come with sendmail used to be enough to cause rpc.lockd to crash... I will be using qmail, when I get to that stage. qmail is supposed to be rather safe, even over NFS. Best of luck, -- -Chuck Thanks, it sounds like you think I need it :) I'm open to suggestions on a better method of accomplishing my goals. Best, -Tom -- Tom Ierna President Shockergroup, Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd stalls
On Sep 7, 2006, at 11:16 AM, Tom Ierna wrote: On Sep 7, 2006, at 1:44 PM, Chuck Swiger wrote: Trying to run a database server or mail server without a disk strikes me as a very bad idea. This is unfortunate - the client machines I have chosen have no front-panel disk sleds. Hardware administration will be a bear if they each have to have their own disks. Software-wise, I was hoping to have them all share a common Kernel and userland too, so I only have to update software in one place. I can see your reasoning, however, it's not especially difficult to keep many FreeBSD systems updated against a single machine configured to build out new versions of the kernel, userland, and installed ports when needed. [1] The thing is, software like mail servers and the database are usually I/O bound, not CPU-bound; when you get under enough load to matter, usually what you need to do is add more disk spindles and spread DB tables or logfiles or mailspool/queuedir locations amongst the extra disks. I am surprised that rpc.lockd is holding up well enough to only go down about once a month; simply running the locking tests which come with sendmail used to be enough to cause rpc.lockd to crash... I will be using qmail, when I get to that stage. qmail is supposed to be rather safe, even over NFS. Yes, agreed-- qmail + maildir rather than mbox format is probably your best bet for doing operations over NFS. Best of luck, -- -Chuck Thanks, it sounds like you think I need it :) Well, yes. But I wouldn't be unhappy if you found something that works for your needs, even if it isn't what I would recommend myself. At least some of the time, I even learn things from people who configure things strangely from my perspective... I'm open to suggestions on a better method of accomplishing my goals. [1]: Mount /usr/src /usr/obj from the buildserver on each machine, do the update process, and then rsync over or mount /usr/ports/ packages, and use portupgrade or whatever to update or install from the precompiled packages. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd stalls
On Thu, Sep 07, 2006 at 03:19:51PM -0400, Tom Ierna wrote: On Sep 7, 2006, at 2:39 PM, Kris Kennaway wrote: On Thu, Sep 07, 2006 at 02:12:26PM -0400, Tom Ierna wrote: Is there a way to note -L via fstab? Since these machines are PXE booted, unmounting and re-mounting with -L will be problematic, and I'd like them to inherit this property at reboot. Yes, use the -o format, see the manpage. Under the man page for mount_nfs, I have the following: -o Options are specified with a -o flag followed by a comma sepa- rated string of options. See the mount(8) man page for possible options and their meanings. The following NFS specific options are also available: ... Historic -o Options ... lockd Same as not specifying -L. ... It doesn't have any other reference to -L. Are mounts specified in fstab automatically non-locking, or is the man page incorrect? Prefixing with 'no' negates an option. Kris pgpfmX1pSMpew.pgp Description: PGP signature
Re: rpc.lockd stalls
On Sep 7, 2006, at 2:39 PM, Kris Kennaway wrote: On Thu, Sep 07, 2006 at 02:12:26PM -0400, Tom Ierna wrote: Is there a way to note -L via fstab? Since these machines are PXE booted, unmounting and re-mounting with -L will be problematic, and I'd like them to inherit this property at reboot. Yes, use the -o format, see the manpage. Under the man page for mount_nfs, I have the following: -o Options are specified with a -o flag followed by a comma sepa- rated string of options. See the mount(8) man page for possible options and their meanings. The following NFS specific options are also available: ... Historic -o Options ... lockd Same as not specifying -L. ... It doesn't have any other reference to -L. Are mounts specified in fstab automatically non-locking, or is the man page incorrect? Thanks, -Tom -- Tom Ierna President Shockergroup, Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
rpc.lockd snatches all priviledged udp ports
Hi, An NFS server running FreeBSD 4.10 sometimes have the problem that all UDP ports below 1024 are used by rpc.lockd. This is not a high load server, really, it serves and handful workstations and should really cope. Is it so that rpc.lockd needs a port for each file, or else what is happening? I found a discussion on -current from Jan 2004 about this, but I couldn't find that the problem was acutually solved? http://lists.freebsd.org/pipermail/freebsd-current/2004-January/018773.html Seems to be a problem with rebooting clients? BTW, can I easily flush the lock daemon to get some ports back? It seems hard to restart the lock daemon - I once tried but gave up and ended up rebooting the system. There must be a better way? Anyone knows if this is fixed in 6.0? thx Palle ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
rpc.lockd and statd fail to start
Hello! I got this: satsmb# rpc.statd rpc.statd: svc_tli_create: could not open connection for udp6 rpc.statd: svc_tp_create: Could not register prog 100024 vers 1 on udp rpc.statd: cannot create udp service satsmb# rpc.lockd rpc.lockd: unable to register (NLM_PROG, NLM_SM, udp) satsmb# uname -a FreeBSD satsmb.local 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #0: Wed Dec 22 01:59:37 MSK 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SATSMBK i386 I googled and pipermailed, but there are very few references to these messages, and they are unsolved mostly. Below is my kernel config. INET6 was left out, but is it mandatory for rpc services? Both services work okay for me on FreeBSD-4.10 without INET6 compiled into kernel. machine i386 cpu I686_CPU ident SATSMBK options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000# Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC device isa device pci device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver device sc device npx device miibus # MII bus support device rl # RealTek 8129/8139 device vr # VIA Rhine, Rhine II # Pseudo devices. device loop# Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device gif # IPv6 and IPv4 tunneling device bpf # Berkeley packet filter # Additional options option IPFIREWALL option IPFIREWALL_DEFAULT_TO_ACCEPT option DUMMYNET Best wishes, Andrew P. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd and statd fail to start
On Wed, Dec 22, 2004 at 10:50:55PM +0300, Andrew P. wrote: Hello! I got this: satsmb# rpc.statd rpc.statd: svc_tli_create: could not open connection for udp6 rpc.statd: svc_tp_create: Could not register prog 100024 vers 1 on udp rpc.statd: cannot create udp service satsmb# rpc.lockd rpc.lockd: unable to register (NLM_PROG, NLM_SM, udp) Are you running rpcbind? The udp6 warning is not by itself fatal, but the fact that it can't register anything with rpcbind is. Kris pgpuNAw2TkDjS.pgp Description: PGP signature
Re: rpc.lockd and statd fail to start
Kris Kennaway wrote: On Wed, Dec 22, 2004 at 10:50:55PM +0300, Andrew P. wrote: Hello! I got this: satsmb# rpc.statd rpc.statd: svc_tli_create: could not open connection for udp6 rpc.statd: svc_tp_create: Could not register prog 100024 vers 1 on udp rpc.statd: cannot create udp service satsmb# rpc.lockd rpc.lockd: unable to register (NLM_PROG, NLM_SM, udp) Are you running rpcbind? The udp6 warning is not by itself fatal, but the fact that it can't register anything with rpcbind is. Yep, rpcbind solved the problem. Thanks! Wishes, Andrew P. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
[SOLVED] Re: NFS locking issues = rpc.lockd: 100024 RPC: Port mapper failure
* Joan Picanyol [EMAIL PROTECTED] [20040930 19:22]: For some unknow cause my 5.3-BETA6 workstation (calvin) cannot lock files over my NFS mounts to my 4.10 server (grummit). I've been all afternoon trying to sort it out with no luck. My loopback interface was not being started. tks -- pica ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS locking issues = rpc.lockd: 100024 RPC: Port mapper failure
[please honour Mail-Followup-To:, not subscribed] Hi, For some unknow cause my 5.3-BETA6 workstation (calvin) cannot lock files over my NFS mounts to my 4.10 server (grummit). I've been all afternoon trying to sort it out with no luck. Portmapper and rpc.lockd are running on the server: [EMAIL PROTECTED]:~(1)$ uname -sr FreeBSD 4.10-RC [EMAIL PROTECTED]:~(0)$ sockstat | egrep 'portmap|lock' root rpc.lock 1123 udp4 *:614 *:* root rpc.lock 1124 tcp4 *:953 *:* daemon portmap1003 udp4 *:111 *:* daemon portmap1004 tcp4 *:111 *:* root rpc.lock 1125 dgram syslogd[96]:3 And all programs are available from the client: [EMAIL PROTECTED]:~(1)$ rpcinfo -s grummit program version(s) netid(s) service owner 10 2 udp,tcp portmapper unknown 14 2,1 tcp,udp ypserv unknown 15 1,3 tcp,udp mountd unknown 13 3,2 tcp,udp nfs unknown 100021 4,3,1 tcp,udp nlockmgrunknown 100024 1 tcp,udp status unknown [EMAIL PROTECTED]:~(1)$ rpcinfo -T tcp grummit 100024 program 100024 version 1 ready and waiting [EMAIL PROTECTED]:~(0)$ rpcinfo -T udp grummit 100024 program 100024 version 1 ready and waiting [EMAIL PROTECTED]:~(0)$ rpcinfo -T tcp grummit 100021 program 100021 version 1 ready and waiting rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 4 program 100021 version 2 is not available program 100021 version 3 ready and waiting program 100021 version 4 ready and waiting [EMAIL PROTECTED]:~(1)$ rpcinfo -T udp grummit 100021 program 100021 version 1 ready and waiting rpcinfo: RPC: Program/version mismatch; low version = 1, high version = 4 program 100021 version 2 is not available program 100021 version 3 ready and waiting program 100021 version 4 ready and waiting The only issue I can see is the Program/version mismatch, but I have no idea if this could be the cause nor how to solve it. Any insights? tks -- pica ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
rpc.lockd
Hi I've very strange problem with a FreeBSD 5.2.1 sever. I export a filesystem (via nfs) to a linux server, and I've many Mar 15 04:35:28 my_host_name rpc.lockd: process 41144: Broken pipe Mar 15 04:35:28 my_host_name rpc.lockd: process 41144: No such process Anybody can help me ? Regards -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. Heure local/Local time: Mon Mar 15 09:13:48 CET 2004 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd segfault
Selon Dan Nelson [EMAIL PROTECTED]: install -s -o root -g wheel -m 555 rpc.lockd /usr/sbin ^^ This strips the debugging symbols. Run gdb against the version of the binary in the obj/ directory. Allright, so I rebuilt rpc.lockd with: -g and copy the binary to /usr/sbin/rpc.lockd (without stripping it). I can't attache gdb to it because rpc.lockd wouldn't work for clients. So I analysed to core file again and didn't get much info: Core was generated by `rpc.lockd'. Program terminated with signal 11, Segmentation fault. #0 0x0804dd2f in ?? () (gdb) quit Any idea ? Thanks all for your help. Oh, by the way, it does not core dump right away, it does sometimes (from 30 minutes to 12 hours). Regards, Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd segfault
On Saturday 17 January 2004 23:01, Kris Kennaway wrote: Unfortunately that doesn't give any information. You'll need to recompile rpc.lockd with GDB debugging symbols (add -ggdb to CFLAGS). See the developer's handbook on the website for more information about debugging program failures with gdb (specifically, how to obtain a useful backtrace). Well, I recompiled rpc.lockd using -ggdb and -g, but when I launch the following command: $ gdb /usr/sbin/rpc.lockd ... I get: GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd...(no debugging symbols found)... How come no debugging symbols are found ? Here is how I compiled rpc.lockd ( CFLAGS= -g -ggdb -O -pipe ): $ rm -Rf /usr/obj/* $ cd /usr/src/usr.sbin/rpc.lockd $ make clean make obj make depend make all install rm -f nlm_prot_svc.c nlm_prot.h test rpc.lockd kern.o nlm_prot_svc.o lockd.o lock_proc.o lockd_lock.o rpc.lockd.8.gz rpc.lockd.8.cat.gz /usr/obj/usr/src/usr.sbin/rpc.lockd created for /usr/src/usr.sbin/rpc.lockd rpcgen -L -C -m -o nlm_prot_svc.c /usr/include/rpcsvc/nlm_prot.x rm -f .depend mkdep -f .depend -a-I. -I/usr/include/rpcsvc /usr/src/usr.sbin/rpc.lockd/kern.c nlm_prot_svc.c /usr/src/usr.sbin/rpc.lockd/lockd.c /usr/src/usr.sbin/rpc.lockd/lock_proc.c /usr/src/usr.sbin/rpc.lockd/lockd_lock.c echo rpc.lockd: /usr/lib/libc.a /usr/lib/librpcsvc.a /usr/lib/libutil.a .depend cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/kern.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c nlm_prot_svc.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/lockd.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/lock_proc.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/lockd_lock.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -o rpc.lockd kern.o nlm_prot_svc.o lockd.o lock_proc.o lockd_lock.o -lrpcsvc -lutil gzip -cn /usr/src/usr.sbin/rpc.lockd/rpc.lockd.8 rpc.lockd.8.gz install -s -o root -g wheel -m 555 rpc.lockd /usr/sbin install -o root -g wheel -m 444 rpc.lockd.8.gz /usr/share/man/man8 /usr/share/man/man8/lockd.8.gz - /usr/share/man/man8/rpc.lockd.8.gz Thanks a lot for your help. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd segfault
Antoine Jacoutot wrote: On Saturday 17 January 2004 23:01, Kris Kennaway wrote: Unfortunately that doesn't give any information. You'll need to recompile rpc.lockd with GDB debugging symbols (add -ggdb to CFLAGS). See the developer's handbook on the website for more information about debugging program failures with gdb (specifically, how to obtain a useful backtrace). Well, I recompiled rpc.lockd using -ggdb and -g, but when I launch the following command: $ gdb /usr/sbin/rpc.lockd ... I get: GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd...(no debugging symbols found)... How come no debugging symbols are found ? Here is how I compiled rpc.lockd ( CFLAGS= -g -ggdb -O -pipe ): $ rm -Rf /usr/obj/* $ cd /usr/src/usr.sbin/rpc.lockd $ make clean make obj make depend make all install rm -f nlm_prot_svc.c nlm_prot.h test rpc.lockd kern.o nlm_prot_svc.o lockd.o lock_proc.o lockd_lock.o rpc.lockd.8.gz rpc.lockd.8.cat.gz /usr/obj/usr/src/usr.sbin/rpc.lockd created for /usr/src/usr.sbin/rpc.lockd rpcgen -L -C -m -o nlm_prot_svc.c /usr/include/rpcsvc/nlm_prot.x rm -f .depend mkdep -f .depend -a-I. -I/usr/include/rpcsvc /usr/src/usr.sbin/rpc.lockd/kern.c nlm_prot_svc.c /usr/src/usr.sbin/rpc.lockd/lockd.c /usr/src/usr.sbin/rpc.lockd/lock_proc.c /usr/src/usr.sbin/rpc.lockd/lockd_lock.c echo rpc.lockd: /usr/lib/libc.a /usr/lib/librpcsvc.a /usr/lib/libutil.a .depend cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/kern.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c nlm_prot_svc.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/lockd.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/lock_proc.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -c /usr/src/usr.sbin/rpc.lockd/lockd_lock.c cc -g -ggdb -O -pipe -march=pentium3 -I. -I/usr/include/rpcsvc -o rpc.lockd kern.o nlm_prot_svc.o lockd.o lock_proc.o lockd_lock.o -lrpcsvc -lutil gzip -cn /usr/src/usr.sbin/rpc.lockd/rpc.lockd.8 rpc.lockd.8.gz install -s -o root -g wheel -m 555 rpc.lockd /usr/sbin install -s uses strip(1), so all your debugging symbols are erased. the original binary left in-place should have debugging symbols. Gilad. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd segfault
On Sun, Jan 18, 2004 at 02:58:44PM +0100, Antoine Jacoutot wrote: Unfortunately that doesn't give any information. You'll need to recompile rpc.lockd with GDB debugging symbols (add -ggdb to CFLAGS). See the developer's handbook on the website for more information about debugging program failures with gdb (specifically, how to obtain a useful backtrace). $ gdb /usr/sbin/rpc.lockd How come no debugging symbols are found ? install -s -o root -g wheel -m 555 rpc.lockd /usr/sbin ^^ This strips the debugging symbols. Run gdb against the version of the binary in the obj/ directory. e.g cd /usr/src/usr.sbin/rpc.lockd make objdir cd obj gdb ./rpc.lockd Kris pgp0.pgp Description: PGP signature
Re: rpc.lockd segfault
In the last episode (Jan 18), Kris Kennaway said: On Sun, Jan 18, 2004 at 02:58:44PM +0100, Antoine Jacoutot wrote: Unfortunately that doesn't give any information. You'll need to recompile rpc.lockd with GDB debugging symbols (add -ggdb to CFLAGS). See the developer's handbook on the website for more information about debugging program failures with gdb (specifically, how to obtain a useful backtrace). $ gdb /usr/sbin/rpc.lockd How come no debugging symbols are found ? install -s -o root -g wheel -m 555 rpc.lockd /usr/sbin ^^ This strips the debugging symbols. Run gdb against the version of the binary in the obj/ directory. If you add the -g flag to DEBUG_FLAGS instead of directly to CFLAGS, that will tell the install target not to strip the final binaries (see bsd.prog.mk). -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd segfault
On Sunday 18 January 2004 14:59, Gilad Rom wrote: install -s uses strip(1), so all your debugging symbols are erased. the original binary left in-place should have debugging symbols. Thanks you all, it seems to be ok now. I just have to wait for rpc.lockd to core dump again so I could get more information on what's going on. I'll let you know. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
rpc.lockd segfault
Hi, I'm having a problem under FreeBSD-5.2-RELEASE. I mount my users homedir under NFS and need rpc.lockd. Unfortunately, and with no reason nor log, rpc.lockd regularly core dump... Any idea where I should start looking. Thanks. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd segfault
On Saturday 17 January 2004 13:38, Antoine Jacoutot wrote: I'm having a problem under FreeBSD-5.2-RELEASE. I mount my users homedir under NFS and need rpc.lockd. Unfortunately, and with no reason nor log, rpc.lockd regularly core dump... Any idea where I should start looking. Here is more information about my problem, using gdb on thecore file: GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd. (gdb) core rpc.lockd.core Core was generated by `rpc.lockd'. Program terminated with signal 11, Segmentation fault. #0 0x0804dd2f in ?? () I really need help on this issue. Thanks. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd segfault
On Sat, Jan 17, 2004 at 08:27:19PM +0100, Antoine Jacoutot wrote: On Saturday 17 January 2004 13:38, Antoine Jacoutot wrote: I'm having a problem under FreeBSD-5.2-RELEASE. I mount my users homedir under NFS and need rpc.lockd. Unfortunately, and with no reason nor log, rpc.lockd regularly core dump... Any idea where I should start looking. Here is more information about my problem, using gdb on thecore file: Unfortunately that doesn't give any information. You'll need to recompile rpc.lockd with GDB debugging symbols (add -ggdb to CFLAGS). See the developer's handbook on the website for more information about debugging program failures with gdb (specifically, how to obtain a useful backtrace). Kris pgp0.pgp Description: PGP signature
