priority_paging (Solaris 8 Releases)
Description | This variable sets cachefree to 2 times lotsfree. The Solaris 8 release changes the way file system pages are cached. These changes subsume the priority paging capability. Note - Remove both cachefree and priority_paging settings in the /etc/system file. |
Commitment Level | Obsolete |
Change History | See "priority_paging (Solaris 2.6 and 7 Releases)" for more information. |
priority_paging (Solaris 2.6 and 7 Releases)
tmpfs:tmpfs_minfree
pages_pp_maximum (Pre-Solaris 9 Releases)
Description | Defines the number of pages that the system requires be unlocked. If a request to lock pages would force available memory below this value, that request is refused. |
Data Type | Unsigned long |
Default | Maximum of the triplet (200, tune_t_minarmem + 100, [10% of memory available at boot time]) |
Range | Default value to no more than 20% of physical memory. The systems does no enforcement of this range other than that described in the Validation section. |
Units | Pages |
Dynamic? | Yes, unless dynamic reconfiguration operations that add or delete memory occur. At that point, the value is reset to whatever was provided in the /etc/system file or was calculated. |
Validation | Maximum of the quadruplet (200, tune_t_minarmem + 100, [10% of memory available], and the value from /etc/system). No message is displayed if the value from /etc/system is increased. Done only at boot time. |
When to Change | When memory locking requests or attaching to a shared memory segment with the SHARE_MMU flag fails, yet the amount of memory available seems to be sufficient. Keeping 10% of memory free on a 32-Gbyte system might be excessive. Excessively large values can cause memory locking requests to fail unnecessarily. |
Commitment Level | Unstable |
General Kernel Variables
noexec_user_stack (Solaris 2.6, 7, and 8 Releases)
Description | Introduced in the Solaris 2.6 release to allow the stack to be marked as non-executable. This helps make buffer-overflow attacks more difficult. In the Solaris 2.6 release, the value does not affect threaded applications. All 64-bit Solaris applications effectively make all stacks non-executable irrespective of the setting of this variable. Note - This variable exists on all systems running the Solaris 2.6, 7, or 8 release, but it is only effective on sun4u, sun4m, and sun4d architectures. |
Data Type | Signed integer |
Default | 0 (disabled) |
Range | 0 (disabled), 1 (enabled) |
Units | Toggle (on/off) |
Dynamic? | Yes. Does not affect currently running processes--only those created after the value is set. |
Validation | None |
When to Change | Should be enabled at all times unless applications are deliberately placing executable code on the stack without using mprotect(2) to make the stack executable. |
Commitment Level | Unstable |
General I/O
rlim_fd_cur (Pre-Solaris 7 and the Solaris 7 Release)
Description | "Soft" limit on file descriptors that a single process can have open. A process might adjust its file descriptor limit to any value up to the "hard" limit defined by rlim_fd_max by using the setrlimit() call or issuing the limit command in whatever shell it is running. You do not require superuser privilege to adjust the limit to any value less than or equal to the hard limit. |
Data Type | Signed integer |
Default | 64 |
Range | 1 to MAXINT |
Units | File descriptors |
Dynamic? | No. Loaded into rlimits structure. |
Validation | Compared to rlim_fd_max and if rlim_fd_cur is greater than rlim_fd_max, rlim_fd_cur is reset to rlim_fd_max. |
When to Change | When the default number of open files for a process is not enough. Increasing this value means only that it is possibly not necessary for a program to use setrlimit(2) to increase the maximum number of file descriptors available to it. |
Commitment Level | Unstable |