The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: answer/para
Context English State
Go into single-user mode and then back to multi-user mode:
<prompt>#</prompt> <userinput>shutdown now</userinput>
<prompt>#</prompt> <userinput>return</userinput>
<prompt>#</prompt> <userinput>exit</userinput>
I tried to update my system to the latest <emphasis>-STABLE</emphasis>, but got <emphasis>-BETA<replaceable>x</replaceable></emphasis>, <emphasis>-RC</emphasis> or <emphasis>-PRERELEASE</emphasis>! What is going on?
Short answer: it is just a name. <emphasis>RC</emphasis> stands for <quote>Release Candidate</quote>. It signifies that a release is imminent. In FreeBSD, <emphasis>-PRERELEASE</emphasis> is typically synonymous with the code freeze before a release. (For some releases, the <emphasis>-BETA</emphasis> label was used in the same way as <emphasis>-PRERELEASE</emphasis>.)
Long answer: FreeBSD derives its releases from one of two places. Major, dot-zero, releases, such as 9.0-RELEASE are branched from the head of the development stream, commonly referred to as <link linkend="current">-CURRENT</link>. Minor releases, such as 6.3-RELEASE or 5.2-RELEASE, have been snapshots of the active <link linkend="stable">-STABLE</link> branch. Starting with 4.3-RELEASE, each release also now has its own branch which can be tracked by people requiring an extremely conservative rate of development (typically only security advisories).
When a release is about to be made, the branch from which it will be derived from has to undergo a certain process. Part of this process is a code freeze. When a code freeze is initiated, the name of the branch is changed to reflect that it is about to become a release. For example, if the branch used to be called 6.2-STABLE, its name will be changed to 6.3-PRERELEASE to signify the code freeze and signify that extra pre-release testing should be happening. Bug fixes can still be committed to be part of the release. When the source code is in shape for the release the name will be changed to 6.3-RC to signify that a release is about to be made from it. Once in the RC stage, only the most critical bugs found can be fixed. Once the release (6.3-RELEASE in this example) and release branch have been made, the branch will be renamed to 6.3-STABLE.
For more information on version numbers and the various Subversion branches, refer to the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/releng/article.html">Release Engineering</link> article.
I tried to install a new kernel, and the <citerefentry><refentrytitle>chflags</refentrytitle><manvolnum>1</manvolnum></citerefentry> failed. How do I get around this?
Short answer: the security level is greater than 0. Reboot directly to single-user mode to install the kernel.
Long answer: FreeBSD disallows changing system flags at security levels greater than 0. To check the current security level:
<prompt>#</prompt> <userinput>sysctl kern.securelevel</userinput>
The security level cannot be lowered in multi-user mode, so boot to single-user mode to install the kernel, or change the security level in <filename>/etc/rc.conf</filename> then reboot. See the <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for details on <literal>securelevel</literal>, and see <filename>/etc/defaults/rc.conf</filename> and the <citerefentry><refentrytitle>rc.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> manual page for more information on <filename>rc.conf</filename>.
I cannot change the time on my system by more than one second! How do I get around this?
Short answer: the system is at a security level greater than 1. Reboot directly to single-user mode to change the date.
Long answer: FreeBSD disallows changing the time by more that one second at security levels greater than 1. To check the security level:
The security level cannot be lowered in multi-user mode. Either boot to single-user mode to change the date or change the security level in <filename>/etc/rc.conf</filename> and reboot. See the <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for details on <literal>securelevel</literal>, and see <filename>/etc/defaults/rc.conf</filename> and the <citerefentry><refentrytitle>rc.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> manual page for more information on <filename>rc.conf</filename>.
Why is <command>rpc.statd</command> using 256 MB of memory?
No, there is no memory leak, and it is not using 256 MB of memory. For convenience, <command>rpc.statd</command> maps an obscene amount of memory into its address space. There is nothing terribly wrong with this from a technical standpoint; it just throws off things like <citerefentry><refentrytitle>top</refentrytitle><manvolnum>1</manvolnum></citerefentry> and <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
<citerefentry><refentrytitle>rpc.statd</refentrytitle><manvolnum>8</manvolnum></citerefentry> maps its status file (resident on <filename>/var</filename>) into its address space; to save worrying about remapping the status file later when it needs to grow, it maps the status file with a generous size. This is very evident from the source code, where one can see that the length argument to <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> is <literal>0x10000000</literal>, or one sixteenth of the address space on an IA32, or exactly 256 MB.
Why can I not unset the <literal>schg</literal> file flag?
The system is running at securelevel greater than 0. Lower the securelevel and try again. For more information, see <link linkend="securelevel">the <acronym>FAQ</acronym> entry on securelevel</link> and the <citerefentry><refentrytitle>init</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page.
What is <literal>vnlru</literal>?
<literal>vnlru</literal> flushes and frees vnodes when the system hits the <varname>kern.maxvnodes</varname> limit. This kernel thread sits mostly idle, and only activates when there is a huge amount of RAM and users are accessing tens of thousands of tiny files.
What do the various memory states displayed by <command>top</command> mean?
<literal>Active</literal>: pages recently statistically used.
<literal>Inactive</literal>: pages recently statistically unused.
<literal>Laundry</literal>: pages recently statistically unused but known to be dirty, that is, whose contents needs to be paged out before they can be reused.
<literal>Free</literal>: pages without data content, which can be immediately reused.
<literal>Wired</literal>: pages that are fixed into memory, usually for kernel purposes, but also sometimes for special use in processes.
Pages are most often written to disk (sort of a VM sync) when they are in the laundry state, but active or inactive pages can also be synced. This depends upon the CPU tracking of the modified bit being available, and in certain situations there can be an advantage for a block of VM pages to be synced, regardless of the queue they belong to. In most common cases, it is best to think of the laundry queue as a queue of relatively unused pages that might or might not be in the process of being written to disk. The inactive queue contains a mix of clean and dirty pages; clean pages near the head of the queue are reclaimed immediately to alleviate a free page shortage, and dirty pages are moved to the laundry queue for deferred processing.
There are some other flags (e.g., busy flag or busy count) that might modify some of the described rules.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: answer/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/faq.pot, string 621