ls: 0653-340 There is not enough memory available now.
Kevin Campbell
ls.
Platform
PSeries650 / PSeries690
AIX 5.1
maintenance level 4
64bit OS
There is plenty of physical memory available however I get the following
error:
ls: 0653-340 There is not enough memory available now.
Any ideas out there?
Thanks in advance
FlossyFloss
Usually that means that your user id is running a process that is using
up too much memory
and/or the setting in your /etc/security/limits for rss (real memory) is
too low for what
you are trying to do.
--
--Flossy
###########################
Cooler than a polar bear's
toe-nails....
--Big Boi
Outkast
###########################
Andreas Schulze
news:Xns94A86F4CF47E...@207.225.159.7...
Hallo Kevin,
the error message has nothing to do with your available memory. Try to mount
without using ACLs, e.g.
# mount -vnfs -o noacl ....
Actually this should be default for 5L.
HTH,
Andreas
F. Michael Orr
> Kevin Campbell wrote:
>> Very strange error running over an NFS mounted filesystem trying to do an
>> ls.
>>
>> Platform
>> PSeries650 / PSeries690
>> AIX 5.1
>> maintenance level 4
>> 64bit OS
>>
>> There is plenty of physical memory available however I get the following
>> error:
>> ls: 0653-340 There is not enough memory available now.
>>
>>
>> Any ideas out there?
>> Thanks in advance
>
> Usually that means that your user id is running a process that is using
> up too much memory
> and/or the setting in your /etc/security/limits for rss (real memory) is
> too low for what
> you are trying to do.
I believe there was also an APAR for this problem, at least on 5.2L. Go
to the pSeries Information Center and search for it.
rens
amount of pages available for immediate use. check the docs on the
vmm tuning guide...
rens
Kevin Campbell <kpc...@qwest.net> wrote in message news:<Xns94A86F4CF47E...@207.225.159.7>...
Steve Nottingham
Have you tried increasing ARG/ENV list ? "smitty chgsys" or "chdev -l
sys0 -a ncargs=<new value>" This is the max size of the ARG/ENV list
in 4k blocks. It might help, it might not.
Steve
Andreas Schulze
news:c2pb1j$dq...@news-1.bank.dresdner.net...
I talked to a colleague who experienced the same problem and by comparison
we figured out three combinations of that particular error (leading to the
error message: 0653-340 There is not enough memory available now) on 64Bit
AIX 5.1/5.2 systems:
NFS Server 5.2.0.0 ML0/ML1 - NFS Client 5.1.0.0 ML0-ML3
-> use -o noacl option when mounting
-> or install APAR IY44190 (Abstract: nfs acl's fail on 64 bit kernel )
NFS Server 5.2.0.0 ML2 - NFS Client 5.1.0.0 ML0-ML3
-> includes APAR IY44190 already i.e. error should not occur.
NFS Server 5.2.0.0 ML2 - NFS Client 5.1.0.0 ML4/ML5 (Linux Clients fail with
diff. error message)
-> install APAR IY47101
(Abstract: JFS2 READDIR() CAN BEHAVE UNPREDICTABLY)
Mind: this little listing might not be complete. While the APAR's abstracts
don't seem to have anything in common (nonetheless lead to the same error
message) problems might be caused by 64 Bit AIX / JFS2 (still not being as
mature as 32 Bit / JFS).
HTH,
Andreas
Stephane GASSIES
That message arrives only when you call "ls" with arguments
(e.g. ls * | some command ...).
You already got an answer about increasing memory for arguments
(see Steve Nottingham's answer).
Most of time, you could make that error message disappear by rewriting
the "ls" statment.
e.g.: replace ls *.Z by ls | grep '\.Z$'
As the list of files is no more part of the command line, you will
not have "memory for command line" problems.
Regards,
Stephane
--
Ce message a ete poste via la plateforme Web club-Internet.fr
This message has been posted by the Web platform club-Internet.fr
Andreas Schulze
"Stephane GASSIES" <sgas...@club-internet.fr> schrieb im Newsbeitrag
news:200442-145...@foorum.com...
>
> That message arrives only when you call "ls" with arguments
> (e.g. ls * | some command ...).
>
Hi Stephane,
AFAIK the message arrives on several different occasions. To give another
example with the cp command:
# mount -vnfs -o acl server:/nfshome /mnt
# cd /mnt/johndoe
# cp -p .profile /tmp/.profile.test
cp: .profile: There is not enough memory available now.
#
Mind that the write fails even while trying to copy to a completely
different (local) filesystem. Now for comparison the same commands without
ACLs activated:
# mount -vnfs server:/nfshome /mnt
# cd /mnt/johndoe
# cp -p .profile /tmp/.profile.test
# cd ~
# umount /mnt
#
The same happens when trying to use vi to open a file. So no doubt there
are occasions when you can solve the problem by increasing memory for
arguments as Steve Nottingham suggested but that does hardly apply to all
cases when you encounter that error message. To me it appears that all
errors seem to have in common that they happen on nfs mounted filesystems.
Regards,
Andreas
Stephane GASSIES
Good to know that tis message can arrive because of NFS access.
The IBM documentation talks a bit about that (http://publib16.boulder.ibm.
com/doc_link/en_US/a_doc_lib/aixbman/commadmn/nfs_intro.htm#jtn370sall)
Part of it :
Although NFS supports access control lists (ACLs), they are no longer used as
the default. To use access control lists with NFS, use the acl option with the
NFS -o flag, as shown in the following example:
mount -o acl
This support is handled by an RPC program that exchanges information about ACLs
between clients and servers. The ACL support does not change the NFS protocol
specification; it is a separate function.
The operating system adds ACLs to the regular file system. Since the normal NFS
protocol does not support ACLs, they cannot be seen by normal NFS clients and
unexpected behavior can result. A user on an NFS client might presume access to
a file after looking at the permission bits, but the permissions could have been
altered by the ACL associated with the file. Permissions on a server are
enforced by the server according to the ACL on the server. Therefore, a user on
the client machine could receive a permissions error.
End of part.
Maybe your error message is what they call "unexpected behavior" ?
Question: do you know if the FS type (on the NFS server) accessed supprts ACLs?
Bests regards,
Andreas Schulze
>
>
Hi Stephane,
> Good to know that tis message can arrive because of NFS access.
>
> The IBM documentation talks a bit about that (http://publib16.boulder.ibm.
> com/doc_link/en_US/a_doc_lib/aixbman/commadmn/nfs_intro.htm#jtn370sall)
>
> Part of it :
> Although NFS supports access control lists (ACLs), they are no longer used
as
> the default.
Yes, that's what I hinted to in my first post to this thread when I assumed
ACLs would apply to the OPs problem. His description (AIX 5.2, NFS and
reading access via ls) sounded somewhat familiar to what I experienced
before. Btw. if the OP still follows this thread I wonder if he could
possibly post for both NFS server and client an oslvel -r and what solved
his problem in the end? Maybe we get another, completely different solution.
[some snipped]
>
> Maybe your error message is what they call "unexpected behavior" ?
Well, I think the abstract of APAR IY44190 speaks for itself: "nfs acl's
fail on 64 bit kernel" Clearly that does not sound as if it was an expected
behaviour and as the APAR wasn't initiated by us there must have been
someone else hit by that problem before :-(
What really annoyed me was that the error message returned in 5.1.0.0 ML05:
a simple read access (e.g. an ls...) to a jfs2 fs failed with the very same
error message (from AIX Client, making access impossible and making Linux
clients fail, too). In this case the abstract for APAR 47101 says "jfs2
readdir() can behave unpredictably" which also does not sound as it if
worked as designed - or does it? :-) Btw. thanks to Gerwin for pointing that
out to me.
>
> Question: do you know if the FS type (on the NFS server) accessed supprts
ACLs?
AIX 5.2 JFS2? It should ;-)
>
> Bests regards,
> Stephane
>
Regards,
Andreas
Terry Polzin
I have had some similar problems with the 64-bit kernel -- install
ML05 it contains a new 64-bit kernel.
no mail
>> There is plenty of physical memory available however I get the following
>> error:
>> ls: 0653-340 There is not enough memory available now.
>>
> I have had some similar problems with the 64-bit kernel -- install
> ML05 it contains a new 64-bit kernel.
I haven't played with large segemtn etc... but this isn't another
incarnation of a maxperm problem again ?
Do you do a lot of I/O on your system ?
Do you get your problem even just a fresh reboot of the box ?
I just run into a situation where the I/O buffering and caching would eat
up all our available memory, and setting maxperm = maxclient = 7 and
minperm = 5 fixed it.
Run vmtune -a, and grep for numperm. If this is really high, then that
might be your problem.
Yves.
----
http://www.cuug.ab.ca/~dorfsmay
http://www.SollerS.ca