diff options
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/config/chapter.sgml')
| -rw-r--r-- | en_US.ISO8859-1/books/handbook/config/chapter.sgml | 92 |
1 files changed, 44 insertions, 48 deletions
diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.sgml b/en_US.ISO8859-1/books/handbook/config/chapter.sgml index 1db6cec9df..8d396b81bc 100644 --- a/en_US.ISO8859-1/books/handbook/config/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/config/chapter.sgml @@ -341,21 +341,18 @@ such as <filename role="package">mail/postfix</filename> or <filename role="package">www/apache13</filename> are just two of the many software packages which may be started during system - initialization. Thus it is only fair that an explanation be - provided on the procedures available for working with third - party software, in the rare cases something goes wrong and the - application does not start up properly.</para> + initialization. This section explains the procedures available + for starting third party software.</para> <para>In &os;, most included services, such as &man.cron.8;, are started through the system start up scripts. These scripts may - different depending on &os; or vendor version; however, the most + differ depending on &os; or vendor version; however, the most important aspect to consider is that their start up configuration can be handled through simple startup scripts.</para> - <para>Since the advent of rcNG, it became clear that system - initialization for third party utilities could be simplified. - For years applications would drop a simple start up script into - the <filename role="directory">/usr/local/etc/rc.d</filename> + <para>Before the advent of rcNG, applications would drop a + simple start up script into the + <filename role="directory">/usr/local/etc/rc.d</filename> directory which would be read by the system initialization scripts. These scripts would then be executed during the latter stages of system start up.</para> @@ -364,17 +361,16 @@ old configuration style into the new system, the fact remains that some third party utilities still require a script simply dropped into the aforementioned directory. The subtle differences - in the scripts depend whether or not rcNG is being used. Any - version of &os; prior to 5.1 will not require the extra bit of - configuration; indeed, in almost all cases the soon to be - recognized script would do just fine.</para> + in the scripts depend whether or not rcNG is being used. Prior + to &os; 5.1 the old configuration style is used and in + almost all cases a new style script would do just fine.</para> <para>While every script must meet some minimal requirements, most of the time these requirements are &os; version agnostic. Each script must have a <filename>.sh</filename> extension appended to the end and every script must be executable by the system. The latter may be achieved by using - the <command>chmod</command> and setting the unique permissions + the <command>chmod</command> command and setting the unique permissions of <literal>755</literal>. There should also be, at minimal, an option to <literal>start</literal> the application and an option to <literal>stop</literal> the application.</para> @@ -490,14 +486,14 @@ run_rc_command "$1"</programlisting> utility from the ports collection with a configuration line appended to the <filename>/etc/inetd.conf</filename> file, or uncommenting one of the current configuration lines. Working - with <command>inetd</command> and its configuration is + with <application>inetd</application> and its configuration is described in depth in the <link linkend="network-inetd">inetd</link> section.</para> <para>In some cases, it may be more plausible to use the &man.cron.8; daemon to start system services. This approach has a number of advantages because <command>cron</command> runs - these processes as the <command>crontab</command>'s file + these processes as the <filename>crontab</filename>'s file owner. This allows regular users to start and maintain some applications.</para> @@ -546,13 +542,13 @@ run_rc_command "$1"</programlisting> <note> <para>User crontabs allow individual users to schedule tasks without the - need for root privileges. Commands in a user's crontab run with the + need for <username>root</username> privileges. Commands in a user's crontab run with the permissions of the user who owns the crontab.</para> <para>The <username>root</username> user can have a user crontab just like any other user. This one is different from <filename>/etc/crontab</filename> (the system crontab). Because of the - system crontab, there's usually no need to create a user crontab + system crontab, there is usually no need to create a user crontab for <username>root</username>.</para> </note> @@ -2512,19 +2508,19 @@ device_probe_and_attach: cbb0 attach returned 12</screen> </listitem> <listitem> - <para>The &man.dmesg.8; output after <quote>boot - <option>-v</option></quote>, including any error messages + <para>The &man.dmesg.8; output after <command>boot + -v</command>, including any error messages generated by you exercising the bug.</para> </listitem> <listitem> - <para>The &man.dmesg.8; output from <quote>boot - <option>-v</option></quote> with <acronym>ACPI</acronym> + <para>The &man.dmesg.8; output from <command>boot + -v</command> with <acronym>ACPI</acronym> disabled, if disabling it helps fix the problem.</para> </listitem> <listitem> - <para>Output from <quote>sysctl hw.acpi</quote>. This is also + <para>Output from <command>sysctl hw.acpi</command>. This is also a good way of figuring out what features your system offers.</para> </listitem> @@ -2626,27 +2622,27 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <literal>S4</literal><acronym>OS</acronym> is implemented entirely by the operating system.</para> - <para>Start by checking <command>sysctl</command> - <option>hw.acpi</option> for the suspend-related items. Here - are the results for my Thinkpad:</para> + <para>Start by checking <command>sysctl hw.acpi</command> + for the suspend-related items. Here + are the results for a Thinkpad:</para> - <screen>hw.acpi.supported_sleep_state: S3 S4 S5</screen> - <screen>hw.acpi.s4bios: 0</screen> + <screen>hw.acpi.supported_sleep_state: S3 S4 S5 +hw.acpi.s4bios: 0</screen> - <para>This means that I can use <command>acpiconf -s</command> + <para>This means that we can use <command>acpiconf -s</command> to test <literal>S3</literal>, <literal>S4</literal><acronym>OS</acronym>, and <literal>S5</literal>. If <option>s4bios</option> was one - (<literal>1</literal>), I would have + (<literal>1</literal>), we would have <literal>S4</literal><acronym>BIOS</acronym> support instead of <literal>S4</literal> <acronym>OS</acronym>.</para> <para>When testing suspend/resume, start with <literal>S1</literal>, if supported. This state is most - likely to work since it doesn't require much driver support. + likely to work since it does not require much driver support. No one has implemented <literal>S2</literal> but if you have - it, it's similar to <literal>S1</literal>. The next thing + it, it is similar to <literal>S1</literal>. The next thing to try is <literal>S3</literal>. This is the deepest <acronym>STR</acronym> state and requires a lot of driver support to properly reinitialize your hardware. If you have @@ -2658,15 +2654,15 @@ device_probe_and_attach: cbb0 attach returned 12</screen> your kernel as possible. If it works, you can narrow down which driver is the problem by loading drivers until it fails again. Typically binary drivers like - <filename>nvidia.ko</filename>, <application>X11</application> + <filename>nvidia.ko</filename>, X11 display drivers, and <acronym>USB</acronym> will have the most problems while Ethernet interfaces usually work fine. If you - can load/unload the drivers ok, you can automate this by + can properly load/unload the drivers, you can automate this by putting the appropriate commands in <filename>/etc/rc.suspend</filename> and <filename>/etc/rc.resume</filename>. There is a commented-out example for unloading and loading a driver. Try - setting <option>hw.acpi.reset_video</option> to zero (0) if + setting <option>hw.acpi.reset_video</option> to zero (<literal>0</literal>) if your display is messed up after resume. Try setting longer or shorter values for <option>hw.acpi.sleep_delay</option> to see if that helps.</para> @@ -2674,7 +2670,7 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <para>Another thing to try is load a recent Linux distribution with <acronym>ACPI</acronym> support and test their suspend/resume support on the same hardware. If it works - on Linux, it's likely a &os; driver problem and narrowing down + on Linux, it is likely a &os; driver problem and narrowing down which driver causes the problems will help us fix the problem. Note that the <acronym>ACPI</acronym> maintainers do not usually maintain other drivers (e.g sound, @@ -2715,7 +2711,7 @@ device_probe_and_attach: cbb0 attach returned 12</screen> system appears hung, try breaking to <acronym>DDB</acronym> (<keycombo action="simul"><keycap>CTRL</keycap> <keycap>ALT</keycap><keycap>ESC</keycap></keycombo> on - console) and type <option>show interrupts</option>.</para> + console) and type <literal>show interrupts</literal>.</para> <para>Your best hope when dealing with interrupt problems is to try disabling <acronym>APIC</acronym> support with @@ -2730,11 +2726,11 @@ device_probe_and_attach: cbb0 attach returned 12</screen> are the top priority to be fixed. The first step is to isolate the steps to reproduce the panic (if possible) and get a backtrace. Follow the advice for enabling - <option>options DDB</option> and setting up a serial console + <literal>options DDB</literal> and setting up a serial console (see <xref linkend="serialconsole-ddb">) or setting up a &man.dump.8; partition. You can get a backtrace in <acronym>DDB</acronym> with - <option>tr</option>. If you have to handwrite the + <literal>tr</literal>. If you have to handwrite the backtrace, be sure to at least get the lowest five (5) and top five (5) lines in the trace.</para> @@ -2748,10 +2744,10 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <sect3> <title>System Powers Up After Suspend or Shutdown</title> <para>First, try setting - <option>hw.acpi.disable_on_poweroff=</option><quote>0</quote> + <literal>hw.acpi.disable_on_poweroff="0"</literal> in &man.loader.conf.5;. This keeps <acronym>ACPI</acronym> from disabling various events during the shutdown process. - Some systems need this value set to <quote>1</quote> (the + Some systems need this value set to <literal>1</literal> (the default) for the same reason. This usually fixes the problem of a system powering up spontaneously after a suspend or poweroff.</para> @@ -2814,13 +2810,13 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <acronym>ACPI</acronym> work without any user intervention. At this point, however, we are still developing workarounds for common mistakes made by the <acronym>BIOS</acronym> vendors. - The Microsoft interpreter (<filename>acpi.sys</filename> and + The µsoft; interpreter (<filename>acpi.sys</filename> and <filename>acpiec.sys</filename>) does not strictly check for adherence to the standard, and thus many <acronym>BIOS</acronym> - vendors who only test <acronym>ACPI</acronym> under Windows + vendors who only test <acronym>ACPI</acronym> under &windows; never fix their <acronym>ASL</acronym>. We hope to continue to identify and document exactly what non-standard behavior is - allowed by Microsoft's interpreter and replicate it so &os; can + allowed by µsoft;'s interpreter and replicate it so &os; can work without forcing users to fix the <acronym>ASL</acronym>. As a workaround and to help us identify behavior, you can fix the <acronym>ASL</acronym> manually. If this works for you, @@ -2836,10 +2832,10 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <title>_OS dependencies</title> <para>Some <acronym>AML</acronym> assumes the world consists of - various Windows versions. You can tell &os; to claim it is + various &windows; versions. You can tell &os; to claim it is any <acronym>OS</acronym> to see if this fixes problems you may have. An easy way to override this is to set - <option>hw.acpi.osname</option>=<quote>Windows 2001</quote> + <literal>hw.acpi.osname="Windows 2001"</literal> in <filename>/boot/loader.conf</filename> or other similar strings you find in the <acronym>ASL</acronym>.</para> </sect3> @@ -2907,9 +2903,9 @@ acpi_dsdt_name="/boot/DSDT.aml"</programlisting> page.</para> <para>Debugging output is not enabled by default. To enable it, - add <option>options ACPI_DEBUG</option> to your kernel config + add <literal>options ACPI_DEBUG</literal> to your kernel configuration file if <acronym>ACPI</acronym> is compiled into the kernel. You can - add <option>ACPI_DEBUG=1</option> to your + add <literal>ACPI_DEBUG=1</literal> to your <filename>/etc/make.conf</filename> to enable it globally. If it is a module, you can recompile just your <filename>acpi.ko</filename> module as follows:</para> |