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
,
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
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
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
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
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
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
.
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
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
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
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
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.
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
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
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
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
* 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
[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
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
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
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
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
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
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 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
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
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
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
28 matches
Mail list logo
