svn commit: r1046879 - in /websites/staging/httpd/trunk/content: ./ dev/debugging.html

[bu...@apache.org]

Author: buildbot
Date: Wed Jun 26 18:32:48 2019
New Revision: 1046879

Log:
Staging update by buildbot for httpd

Modified:
    websites/staging/httpd/trunk/content/   (props changed)
    websites/staging/httpd/trunk/content/dev/debugging.html

Propchange: websites/staging/httpd/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed Jun 26 18:32:48 2019
@@ -1 +1 @@
-1861068
+1862182

Modified: websites/staging/httpd/trunk/content/dev/debugging.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/debugging.html (original)
+++ websites/staging/httpd/trunk/content/dev/debugging.html Wed Jun 26 18:32:48 2019
@@ -473,10 +473,13 @@ memory.</p>
 Solaris, without knowing which httpd child might be the one to die [note:
 it is probably easier to use the MaxClients trick in the first section
 above].
-<code># for pid in</code>ps -eaf | fgrep httpd | cut -d' ' -f4<code>do
-      truss -f -l -t\!all -S SIGSEGV -p $pid 2&amp;gt;&amp;amp;1 | egrep SIGSEGV
-      &amp;amp;
-    done</code> 
+<pre>
+    # for pid in <code>ps -eaf | fgrep httpd | cut -d' ' -f4</code>
+    do
+      truss -f -l -t!all -S SIGSEGV -p $pid 2&gt;&amp;1 | egrep SIGSEGV
+      &amp;
+    done
+</pre>
 The <a href="http://www.dejanews.com/=zzz_maf/getdoc.xp?AN=352257973">undocumented '-S'
 flag</a> to truss
 will halt the process in place upon receipt of a given signal (SIGSEGV in
@@ -486,16 +489,17 @@ this case). At this point you can use:
 and then look at the backtrace as discussed above for <a href="#gdb">gdb</a>.</p>
 <h1 id="sol27">Solaris and coredumps<a class="headerlink" href="#sol27" title="Permanent link">&para;</a></h1>
 <p>On Solaris use <a href="http://docs.sun.com/app/docs/doc/816-5166/coreadm-1m"></a> to
-make <code>setuid()</code> processes actually dump core. By default a setuid() process
+make <code>setuid()</code> processes actually dump core. By default a <code>setuid()</code> process
 does not dump core. This is the reason why httpd servers started as root
 with child processes running as a different user (such as <code>apache</code> ) do not
 coredump even when the
-<a href="http://httpd.apache.org/docs/current/mod/mpm_common.html#coredumpdirectory"></a>
+<a href="http://httpd.apache.org/docs/current/mod/mpm_common.html#coredumpdirectory">CoreDumpDirectory</a>
 directive had been set to an appropriate and writable directory and <strong>
 <code>ulimit -c</code> </strong> has a sufficient size. See also <a href="#crashes">Debugging intermittent
 crashes</a> above.</p>
 <p>Example:
-<code>-bash-3.00# coreadm
+<pre>
+-bash-3.00# coreadm
      global core file pattern: /var/core/core.%f.%p.u%u
      global core file content: default
        init core file pattern: core
@@ -504,7 +508,8 @@ crashes</a> above.</p>
        per-process core dumps: enabled
       global setid core dumps: enabled
 per-process setid core dumps: enabled
-     global core dump logging: disabled</code> </p>
+     global core dump logging: disabled
+</pre></p>
 <h1 id="tcpdump">Getting and analyzing a TCP packet trace<a class="headerlink" href="#tcpdump" title="Permanent link">&para;</a></h1>
 <p>This is too deep a subject to fully describe in this documentation. Here
 are some pointers to useful discussions and tools:</p>