> 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 an
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
,
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 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.
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
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 s
thing.
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
attem
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.
>
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 t
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
> 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
ainly 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 enou
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
# 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,
And
ate 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
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
* 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
--
pic
[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:
[
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
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 r
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 cou
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
>
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 mor
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
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
>
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
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 looki
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
___
[
28 matches
Mail list logo
