From: Peter Sherwood (petersherwood@microway.com)
Date: Tue Oct 01 2002 - 17:19:09 EDT
Long ago (actually, on: Sat, 4 Mar 2000), this dialogue occurred in the mailing list:
SUMMARY: fsck allocation error
Ann Cantelow -- Sat, 4 Mar 2000 23:33:26 +0100 (MET)
Hi.
My problem was this error, when trying to fsck a file system after a power
failure:
/sbin/ufs_fsck /dev/rrz0c
** /dev/rrz0c
cannot alloc 200256002 bytes for lncntp
Many thanks to Steve Hancock, who sent the below solution, saying that
there is likely a shortage of per-process memory for fsck to work with.
I increased that to some 350 Mbytes and rebooted, but still got the same
error. The disk set just had a few days of news binaries on it, so I ran
newfs on it, to avoid interrupting other processes going on on the machine
with further reboots. There were no problems to fsck the disk set after
that, so we're ok for now.
Best,
Ann Cantelow
From: Steve Hancock <shancock@zk3.dec.com>
-----------------------------------------------
The lncntp is a structure used by fsck to internally perform some
bookkeeping while it is doing its job. It looks like it could not
allocate enough memory for it to begin the fsck process. I can think
of two reasons why this could happen:
1) You have eager mode swapping enabled and you don't have enough
virtual memory (physical memory+swap) to allocate it.
2) Your process limit is too small. The default process data size limit
is 128MB, so I would say this is your problem. You can work around this
by upping this limit in your shell, or in sysconfitab. The latter
would require a reboot. For example:
# sysconfig -q proc per_proc_data_size
proc:
per_proc_data_size = 134217728
So, edit sysconfitab to alter it and reboot.
-------------------------------------------------
What I am hoping is that someone who isn't as rusty on UNIX as I,
can reveal how one might:
"... work around this by upping this limit in your shell, ..."
as I would rather not change "the per_proc_data_size = 134217728" since
1) I am working remotely
2) would prefer to not have to change kernel settings
3) have the customer have to catch potential kernel or boot errors
4) get them all accurately back to me (if they exist).
those who have gone through this once, will identify fully ;-)
Many thanks in advance
-- Peter Sherwood <petersherwood@microway.com> Technical Support Direct: 508-732-5542 Main: 508-746-7341 Fax: 508-746-4678 Microway, Inc. - "Technology You Can Count On" http://www.microway.com/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:54 EDT