Hello again,
The problem reported in my first letter, quoted below, has been solved.
I do not know the "why" of it well enough to pass on to this list, but
I can at least state the "how" it was fixed and the source of the problem.
SUMMARY:
--------
Problem: various programs would receive kill signals and make ambiguous
complaints like, "mmap failed: Not enough space", and others. X, vim,
inn, infobot, among many programs would not run as any user.
Solution: in reading the man page for mmap(2), I read this part of the
section explaining return values for the call:
ENOMEM The MAP_FIXED option was specified and the
range [addr, addr + len) exceeds that allowed
for the address space of a process.
The MAP_FIXED option was not specified and
there is insufficient room in the address
space to effect the mapping.
The composite size of len plus the lengths of
all previous mmappings exceeds RLIMIT_VMEM
(see getrlimit(2)).
Then I remembered that the previous weekend I had been working on a
mini-shell using rksh and it's builtin for menus, supplemented by an
?ksh-specific portion of /etc/profile, a global ENV file and some
autoloaded functions. In /etc/profile, outside of the ?ksh-specific
settings, I had listed global ulimit statements for everything -
including a limit on virtual memory. So, it seems that many larger
user processes were affected by this limit. The errors are gone now,
inn runs and so does everything else.
I don't know why it took a week before this affected the system, it
was not rebooted during that time. I should have been tipped of by
the fact that some suid "safe-user" programs were running fine, having
only sourced /etc/suid_profile. Ah well, all seems fine now.
Thanks again,
--Rick
Thanks for your consideration.
On Sat, Sep 05, 1998 at 06:28:00PM -0700, Rick Robino wrote:
> Greetings,
>
> I have just run into something I've never seen before - after killing an
> X session (X11R63) on my SPARC5, all(?) my mmap applications seem to have
> lost their linking with their shared libs and will not run. The box has 1
> sun4u, 170 MHz, and is running Solaris 2.6 patched up to date (980305),
> including opewnin patches.
>
> Naturally X and innd won't run, and other programs too. All give errors
> like this:
>
> [rrobino@flea:~ ]$vi file
> ld.so.1: /usr/local/bin/vim: fatal: /lib/libm.so.1: mmap failed: Not enough spac
> e
> Killed
>
> I have also seen messages which state "no such file or directory" for
> shared libs that do exist. Sometimes kill signals 8 and 9 are reported,
> and of those sometimes there are complaints about the kill argument
> count being out of range. Nothing on this system has been changed other
> than killing the X server (load was too high, I was lazy and at home),
> which had no problems before that. I had not applied any patches in at
> least a month, but caught up and applied all missing patches yesterday.
>
> After I reran ldd as root, at least viewing my list of environmment
> variables stopped spewing garbage control characters. There is no
> value for LD_LIBRARY_PATH in my environment. I don't know what else
> to do, but I am glad that not everything that needs virtual memory
> at this point.
>
> I have 128MB RAM, and none(!) is being used for swap. I am not using any
> volume management at all. Here is my df -k:
>
> Filesystem kbytes used avail capacity Mounted on
> /dev/dsk/c0t3d0s0 1015695 264464 749539 27% /
> /dev/dsk/c0t3d0s6 720199 345306 373993 49% /usr
> /proc 0 0 0 0% /proc
> fd 0 0 0 0% /dev/fd
> swap 325804 16 325788 1% /tmp
> /dev/dsk/c0t1d0s7 700407 319220 380312 46% /usr/openwin
> /dev/dsk/c0t1d0s1 1290143 839414 447504 66% /opt
> /dev/dsk/c0t2d0s0 523939 133618 389273 26% /opt/news
> /dev/dsk/c0t2d0s1 476483 439515 36015 93% /opt/src
> /dev/dsk/c0t2d0s6 476483 246477 229053 52% /var/ftp
> /dev/dsk/c0t2d0s7 474963 430402 43611 91% /home
>
> Those files in /tmp are:
>
> drwxrwxrwt 4 sys sys 388 Sep 5 18:22 .
> drwxr-xr-x 33 root root 1024 Sep 5 13:25 ..
> -rw-rw-rw- 1 root root 3 Sep 5 13:25 .MsmServer.lock
> drwxrwxrwx 2 root root 107 Sep 5 13:25 .pcmcia
> drwxrwxrwt 2 root root 161 Sep 5 13:24 .rpc_door
> -rw-rw-rw- 1 root root 3 Sep 5 13:25 ContentManager.lock
> -rw-rw-r-- 1 root sys 5156 Sep 5 13:24 ps_data
> srwxrwxrwx 1 root root 0 Sep 5 13:24 psb_back_socket
> srwxrwxrwx 1 root root 0 Sep 5 13:24 psb_front_socket
>
> I have no idea what is going on here, but it quite strange to me. Yes,
> those are the real perms on those lock files, and no, I don't even know
> why I'm too lazy not to run that stupid content manager thing (I use wu).
>
> My last piece of info is this snippet of vmstat:
>
> [rrobino@flea:/opt/apache/share/cgi-bin ]$vmstat 1 3
> procs memory page disk faults cpu
> r b w swap free re mf pi po fr de sr f0 s1 s2 s3 in sy cs us sy id
> 0 0 0 328836 74048 0 18 1 0 0 0 0 0 0 0 1 18 138 39 2 2 97
> 0 0 0 327800 71336 0 8 0 0 0 0 0 0 0 0 0 13 87 39 1 1 98
> 0 0 0 327800 71336 0 0 0 0 0 0 0 0 0 0 0 22 85 44 0 0 100
>
>
> I hope this is enough information and that someone else has seen this before.
> Let me know if you need more, I will post a detailed summary. It may be
> worth noting that this is not a production box, just my own workstation where
> I prototype alot of new implementations.
>
> TIA for your help,
>
> --Rick
> ^^^^^^^^^^^^^^
> Rick Robino mailto:rrobino@gstis.net
> Manager, Internet Operations, GST/Whole Earth http://www.gstis.net
> Portland: v. (503) 416-1517 f. (503) 416-1555 p. (503) 703-0728
--
^^^^^^^^^^^^^^
Rick Robino mailto:rrobino@gstis.net
Manager, Internet Operations, GST/Whole Earth http://www.gstis.net
Portland: v. (503) 416-1517 f. (503) 416-1555 p. (503) 703-0728
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:48 CDT