/usr/share/doc/libapache2-mod-perl2-doc/docs/2.0/user/handlers/server.html is in libapache2-mod-perl2-doc 2.0.8+httpd24-r1449661-6ubuntu2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 | <?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rev="made" href="mailto:root@localhost" />
</head>
<body style="background-color: white">
<ul id="index">
<li><a href="#NAME">NAME</a></li>
<li><a href="#Description">Description</a></li>
<li><a href="#Server-Life-Cycle">Server Life Cycle</a>
<ul>
<li><a href="#Startup-Phases-Demonstration-Module">Startup Phases Demonstration Module</a></li>
<li><a href="#PerlOpenLogsHandler">PerlOpenLogsHandler</a></li>
<li><a href="#PerlPostConfigHandler">PerlPostConfigHandler</a></li>
<li><a href="#PerlChildInitHandler">PerlChildInitHandler</a></li>
<li><a href="#PerlChildExitHandler">PerlChildExitHandler</a></li>
</ul>
</li>
<li><a href="#Apache-Command-line-Commands">Apache Command-line Commands</a></li>
<li><a href="#mod_perl-Startup">mod_perl Startup</a>
<ul>
<li><a href="#Start-Immediately-Restarts">Start Immediately Restarts</a></li>
<li><a href="#When-Does-perl-Start-To-Run">When Does perl Start To Run</a></li>
<li><a href="#Startup-File">Startup File</a></li>
<li><a href="#Dealing-with-Restarts">Dealing with Restarts</a></li>
</ul>
</li>
<li><a href="#Maintainers">Maintainers</a></li>
<li><a href="#Authors">Authors</a></li>
</ul>
<h1 id="NAME">NAME</h1>
<p>Server Life Cycle Handlers</p>
<h1 id="Description">Description</h1>
<p>This chapter discusses server life cycle and the mod_perl handlers participating in it.</p>
<h1 id="Server-Life-Cycle">Server Life Cycle</h1>
<p>The following diagram depicts the Apache 2.0 server life cycle and highlights which handlers are available to mod_perl 2.0:</p>
<img src="server_life_cycle.gif" width="561" height="537"
align="middle" alt="server life cycle"><br><br>
<p>Apache 2.0 starts by parsing the configuration file. After the configuration file is parsed, the <code>PerlOpenLogsHandler</code> handlers are executed if any. After that it's a turn of <code>PerlPostConfigHandler</code> handlers to be run. When the <i>post_config</i> phase is finished the server immediately restarts, to make sure that it can survive graceful restarts after starting to serve the clients.</p>
<p>When the restart is completed, Apache 2.0 spawns the workers that will do the actual work. Depending on the used MPM, these can be threads, processes or a mixture of both. For example the <i>worker</i> MPM spawns a number of processes, each running a number of threads. When each child process is started <code>PerlChildInitHandler</code> handlers are executed. Notice that they are run for each starting process, not a thread.</p>
<p>From that moment on each working thread processes connections until it's killed by the server or the server is shutdown.</p>
<h2 id="Startup-Phases-Demonstration-Module">Startup Phases Demonstration Module</h2>
<p>Let's look at the following example that demonstrates all the startup phases:</p>
<pre><code> #file:MyApache2/StartupLog.pm
#----------------------------
package MyApache2::StartupLog;
use strict;
use warnings;
use Apache2::Log ();
use Apache2::ServerUtil ();
use Fcntl qw(:flock);
use File::Spec::Functions;
use Apache2::Const -compile => 'OK';
my $log_path = catfile Apache2::ServerUtil::server_root,
"logs", "startup_log";
my $log_fh;
sub open_logs {
my ($conf_pool, $log_pool, $temp_pool, $s) = @_;
$s->warn("opening the log file: $log_path");
open $log_fh, ">>$log_path" or die "can't open $log_path: $!";
my $oldfh = select($log_fh); $| = 1; select($oldfh);
say("process $$ is born to reproduce");
return Apache2::Const::OK;
}
sub post_config {
my ($conf_pool, $log_pool, $temp_pool, $s) = @_;
say("configuration is completed");
return Apache2::Const::OK;
}
sub child_init {
my ($child_pool, $s) = @_;
say("process $$ is born to serve");
return Apache2::Const::OK;
}
sub child_exit {
my ($child_pool, $s) = @_;
say("process $$ now exits");
return Apache2::Const::OK;
}
sub say {
my ($caller) = (caller(1))[3] =~ /([^:]+)$/;
if (defined $log_fh) {
flock $log_fh, LOCK_EX;
printf $log_fh "[%s] - %-11s: %s\n",
scalar(localtime), $caller, $_[0];
flock $log_fh, LOCK_UN;
}
else {
# when the log file is not open
warn __PACKAGE__ . " says: $_[0]\n";
}
}
my $parent_pid = $$;
END {
my $msg = "process $$ is shutdown";
$msg .= "\n". "-" x 20 if $$ == $parent_pid;
say($msg);
}
1;</code></pre>
<p>And the <i>httpd.conf</i> configuration section:</p>
<pre><code> <IfModule prefork.c>
StartServers 4
MinSpareServers 4
MaxSpareServers 4
MaxClients 10
MaxRequestsPerChild 0
</IfModule>
PerlModule MyApache2::StartupLog
PerlOpenLogsHandler MyApache2::StartupLog::open_logs
PerlPostConfigHandler MyApache2::StartupLog::post_config
PerlChildInitHandler MyApache2::StartupLog::child_init
PerlChildExitHandler MyApache2::StartupLog::child_exit</code></pre>
<p>When we perform a server startup followed by a shutdown, the <i>logs/startup_log</i> is created if it didn't exist already (it shares the same directory with <i>error_log</i> and other standard log files), and each stage appends to that file its log information. So when we perform:</p>
<pre><code> % bin/apachectl start && bin/apachectl stop</code></pre>
<p>the following is getting logged to <i>logs/startup_log</i>:</p>
<pre><code> [Sun Jun 6 01:50:06 2004] - open_logs : process 24189 is born to reproduce
[Sun Jun 6 01:50:06 2004] - post_config: configuration is completed
[Sun Jun 6 01:50:07 2004] - END : process 24189 is shutdown
--------------------
[Sun Jun 6 01:50:08 2004] - open_logs : process 24190 is born to reproduce
[Sun Jun 6 01:50:08 2004] - post_config: configuration is completed
[Sun Jun 6 01:50:09 2004] - child_init : process 24192 is born to serve
[Sun Jun 6 01:50:09 2004] - child_init : process 24193 is born to serve
[Sun Jun 6 01:50:09 2004] - child_init : process 24194 is born to serve
[Sun Jun 6 01:50:09 2004] - child_init : process 24195 is born to serve
[Sun Jun 6 01:50:10 2004] - child_exit : process 24193 now exits
[Sun Jun 6 01:50:10 2004] - END : process 24193 is shutdown
[Sun Jun 6 01:50:10 2004] - child_exit : process 24194 now exits
[Sun Jun 6 01:50:10 2004] - END : process 24194 is shutdown
[Sun Jun 6 01:50:10 2004] - child_exit : process 24195 now exits
[Sun Jun 6 01:50:10 2004] - child_exit : process 24192 now exits
[Sun Jun 6 01:50:10 2004] - END : process 24192 is shutdown
[Sun Jun 6 01:50:10 2004] - END : process 24195 is shutdown
[Sun Jun 6 01:50:10 2004] - END : process 24190 is shutdown
--------------------</code></pre>
<p>First of all, we can clearly see that Apache always restart itself after the first <i>post_config</i> phase is over. The logs show that the <i>post_config</i> phase is preceded by the <i>open_logs</i> phase. Only after Apache has restarted itself and has completed the <i>open_logs</i> and <i>post_config</i> phase again, the <i>child_init</i> phase is run for each child process. In our example we have had the setting <code>StartServers=4</code>, therefore you can see four child processes were started.</p>
<p>Finally you can see that on server shutdown, the <i>child_exit</i> phase is run for each child process and the <code>END {}</code> block is executed by the parent process and each of the child processes. This is because that <code>END</code> block was inherited from the parent on fork.</p>
<p>However the presented behavior varies from MPM to MPM. This demonstration was performed using prefork mpm. Other MPMs like winnt, may run <i>open_logs</i> and <i>post_config</i> more than once. Also the END blocks may be run more times, when threads are involved. You should be very careful when designing features relying on the phases covered in this chapter if you plan support multiple MPMs. The only thing that's sure is that you will have each of these phases run at least once.</p>
<p>Apache also specifies the <i>pre_config</i> phase, which is executed before the configuration files are parsed, but this is of no use to mod_perl, because mod_perl is loaded only during the configuration phase.</p>
<p>Now let's discuss each of the mentioned startup handlers and their implementation in the <code>MyApache2::StartupLog</code> module in detail.</p>
<h2 id="PerlOpenLogsHandler"><code>PerlOpenLogsHandler</code></h2>
<p>The <i>open_logs</i> phase happens just before the <i>post_config</i> phase.</p>
<p>Handlers registered by <code>PerlOpenLogsHandler</code> are usually used for opening module-specific log files (e.g., httpd core and mod_ssl open their log files during this phase).</p>
<p>At this stage the <code>STDERR</code> stream is not yet redirected to <i>error_log</i>, and therefore any messages to that stream will be printed to the console the server is starting from (if such exists).</p>
<p>This phase is of type <code><a>RUN_ALL</a></code>.</p>
<p>The handler's configuration scope is <code><a>SRV</a></code>.</p>
<p><b>Arguments</b></p>
<p>The <i>open_logs</i> handler is passed four arguments: the configuration pool, the logging stream pool, the temporary pool and the main server object.</p>
<p>The pool arguments are:</p>
<ul>
<li><p><code>$conf_pool</code> is the main process sub-pool, therefore its life-span is the same as the main process's one. The main process is a sub-pool of the global pool.</p>
</li>
<li><p><code>$log_pool</code> is a global pool's sub-pool, therefore its life-span is the same as the Apache program's one.</p>
<p>META: what is it good for if it lives the same life as conf pool?</p>
</li>
<li><p><code>$temp_pool</code> is a <code>$conf_pool</code> subpool, created before the config phase, lives through the open_logs phase and get destroyed after the post_config phase. So you will want to use that pool for doing anything that can be discarded before the requests processing starts.</p>
</li>
</ul>
<p>All three pool arguments are instances of <code><a>APR::Pool</a></code>.</p>
<p><code>$s</code> is the base server object (an instance of <code><a>Apache2::ServerRec</a></code>).</p>
<p><b>Return</b></p>
<p>The handler should return <code><a>Apache2::Const::OK</a></code> if it completes successfully.</p>
<p><b>Examples</b></p>
<pre><code> sub open_logs {
my ($conf_pool, $log_pool, $temp_pool, $s) = @_;
$s->warn("opening the log file: $log_path");
open $log_fh, ">>$log_path" or die "can't open $log_path: $!";
my $oldfh = select($log_fh); $| = 1; select($oldfh);
say("process $$ is born to reproduce");
return Apache2::Const::OK;
}</code></pre>
<p>In our example the handler opens a log file for appending and sets the filehandle to unbuffered mode. It then logs the fact that it's running in the parent process.</p>
<p>As you've seen in the example this handler is configured by adding to the top level of <i>httpd.conf</i>:</p>
<pre><code> PerlOpenLogsHandler MyApache2::StartupLog::open_logs</code></pre>
<p>This handler can be executed only by the main server. If you want to traverse the configured virtual hosts, you can accomplish that using a simple loop. For example to print out the configured port numbers do:</p>
<pre><code> use Apache2::ServerRec ();
# ...
sub open_logs {
my ($conf_pool, $log_pool, $temp_pool, $s) = @_;
my $port = $s->port;
warn "base port: $port\n";
for (my $vs = $s->next; $vs; $vs = $vs->next) {
my $port = $vs->port;
warn "vhost port: $port\n";
}
return Apache2::Const::OK;
}</code></pre>
<h2 id="PerlPostConfigHandler"><code>PerlPostConfigHandler</code></h2>
<p>The <i>post_config</i> phase happens right after Apache has processed the configuration files, before any child processes were spawned (which happens at the <i>child_init</i> phase).</p>
<p>This phase can be used for initializing things to be shared between all child processes. You can do the same in the startup file, but in the <i>post_config</i> phase you have an access to a complete configuration tree (via <code><a>Apache2::Directive</a></code>).</p>
<p>This phase is of type <code><a>RUN_ALL</a></code>.</p>
<p>The handler's configuration scope is <code><a>SRV</a></code>.</p>
<p><b>Arguments</b></p>
<p>Arguments are exactly as for <code><a href="#C_PerlOpenLogsHandler_">PerlOpenLogsHandler</a></code>.</p>
<p><b>Return</b></p>
<p>If the handler completes successfully it should return <code><a>Apache2::Const::OK</a></code>.</p>
<p><b>Examples</b></p>
<p>In our <code><a href="#Startup_Phases_Demonstration_Module">MyApache2::StartupLog</a></code> example we used the <i>post_config()</i> handler:</p>
<pre><code> sub post_config {
my ($conf_pool, $log_pool, $temp_pool, $s) = @_;
say("configuration is completed");
return Apache2::Const::OK;
}</code></pre>
<p>As you can see, its arguments are identical to the <i><a href="#C_PerlOpenLogsHandler_">open_logs</a></i> phase's handler. In this example handler we don't do much, but logging that the configuration was completed and returning right away.</p>
<p>As you've seen in the example this handler is configured by adding to <i>httpd.conf</i>:</p>
<pre><code> PerlPostConfigHandler MyApache2::StartupLog::post_config</code></pre>
<p>Everything that applies to <code><a href="#C_PerlOpenLogsHandler_">PerlOpenLogsHandler</a></code> identically applies to this handler.</p>
<p>The <code><a>add_version_component()</a></code> includes another useful example.</p>
<h2 id="PerlChildInitHandler"><code>PerlChildInitHandler</code></h2>
<p>The <i>child_init</i> phase happens immediately after the child process is spawned. Each child process (not a thread!) will run the hooks of this phase only once in their life-time.</p>
<p>In the prefork MPM this phase is useful for initializing any data structures which should be private to each process. For example <code>Apache::DBI</code> pre-opens database connections during this phase and <code>Apache2::Resource</code> sets the process' resources limits.</p>
<p>This phase is of type <code><a>VOID</a></code>.</p>
<p>The handler's configuration scope is <code><a>SRV</a></code>.</p>
<p><b>Arguments</b></p>
<p>The <i>child_init()</i> handler is passed two arguments: the child process pool (<code><a>APR::Pool</a></code>) and the server object (<code><a>Apache2::ServerRec</a></code>).</p>
<p><b>Return</b></p>
<p>If the handler completes successfully it should return <code><a>Apache2::Const::OK</a></code>.</p>
<p><b>Examples</b></p>
<p>In our <code><a href="#Startup_Phases_Demonstration_Module">MyApache2::StartupLog</a></code> example we used the <i>child_init()</i> handler:</p>
<pre><code> sub child_init {
my ($child_pool, $s) = @_;
say("process $$ is born to serve");
return Apache2::Const::OK;
}</code></pre>
<p>The example handler logs the pid of the child process it's run in and returns.</p>
<p>As you've seen in the example this handler is configured by adding to <i>httpd.conf</i>:</p>
<pre><code> PerlChildInitHandler MyApache2::StartupLog::child_init</code></pre>
<h2 id="PerlChildExitHandler"><code>PerlChildExitHandler</code></h2>
<p>Opposite to the <i>child_init</i> phase, the <i>child_exit</i> phase is executed before the child process exits. Notice that it happens only when the process exits, not the thread (assuming that you are using a threaded mpm).</p>
<p>This phase is of type <code><a>RUN_ALL</a></code>.</p>
<p>The handler's configuration scope is <code><a>SRV</a></code>.</p>
<p><b>Arguments</b></p>
<p>The <i>child_exit()</i> handler accepts two arguments: the child process pool (<code><a>APR::Pool</a></code>) and the server object (<code><a>Apache2::ServerRec</a></code>).</p>
<p><b>Return</b></p>
<p>If the handler completes successfully it should return <code><a>Apache2::Const::OK</a></code>.</p>
<p><b>Examples</b></p>
<p>In our <code><a href="#Startup_Phases_Demonstration_Module">MyApache2::StartupLog</a></code> example we used the <i>child_exit()</i> handler:</p>
<pre><code> sub child_exit {
my ($child_pool, $s) = @_;
say("process $$ now exits");
return Apache2::Const::OK;
}</code></pre>
<p>The example handler logs the pid of the child process it's run in and returns.</p>
<p>As you've seen in the example this handler is configured by adding to <i>httpd.conf</i>:</p>
<pre><code> PerlChildExitHandler MyApache2::StartupLog::child_exit</code></pre>
<h1 id="Apache-Command-line-Commands">Apache Command-line Commands</h1>
<p>Some notes on how Apache start/restart Apache commands affect mod_perl.</p>
<p>META: not sure this is the best place for this section, but start some notes here.</p>
<p>Apache re-parses <i>httpd.conf</i> at least once for <b>each</b> of the following commands (and will run any mod_perl code found in it).</p>
<dl>
<dt id="httpd--k-start">httpd -k start</dt>
<dd>
<p>No special issues here.</p>
<p>Apache start and immediately restarts itself.</p>
</dd>
<dt id="httpd--k-restart">httpd -k restart</dt>
<dd>
<p>This will abort any processed requests and restart the server.</p>
<p>All kind of problems could be encountered here, including segfaults and other kind of crashes. This is because when the <code>SIGTERM</code> signal is sent, things in process will be aborted.</p>
<p>Avoid using this method.</p>
<p>Alternatively <code>httpd -k restart</code> can be executed <code>kill -HUP HTTPD_PID</code>.</p>
</dd>
<dt id="httpd--k-graceful">httpd -k graceful</dt>
<dd>
<p>No issues here. Apache starts and restarts itself just like with <code>start</code>, but it waits for the existing requests to finish before killing them.</p>
<p>Alternatively <code>httpd -k graceful</code> can be executed <code>kill -USR1 HTTPD_PID</code>.</p>
</dd>
<dt id="httpd--k-stop">httpd -k stop</dt>
<dd>
<p>Similarly to <code>httpd -k restart</code> you may encounter all kind of issues here, due to the <code>SIGTERM</code> signal.</p>
</dd>
</dl>
<h1 id="mod_perl-Startup">mod_perl Startup</h1>
<p>The following sections discuss the specifics of the mod_perl startup.</p>
<h2 id="Start-Immediately-Restarts">Start Immediately Restarts</h2>
<p>As explained in the <a>Server Life Cycle section</a>, on start Apache normally runs the server configuration phase, followed by <code><a>PerlOpenLogsHandler</a></code> and <code><a>PerlPostConfigHandler</a></code> phases, then immediately restarts itself. Therefore everything running at the server startup is executed twice. During the restart, Perl is completely destroyed and started again.</p>
<h2 id="When-Does-perl-Start-To-Run">When Does perl Start To Run</h2>
<p>If Apache is started as <code>'httpd -t'</code> (equivalent to <code>'apachectl configtest'</code>) or as <code>'httpd -S'</code>, it will run only the configuration phase and exit. Depending on your configuration file, it may or may not start perl. See the details below.</p>
<p>During the normal startup, mod_perl 2.0 postpones the startup of perl until after the configuration phase is over, to allow the usage of the <code><a>PerlSwitches</a></code> directive, which can't be used after Perl is started.</p>
<p>After the configuration phase is over, as the very first thing during the <code><a>post_config phase</a></code>, mod_perl starts perl and runs any registered <code><a>PerlRequire</a></code> and <code><a>PerlModule</a></code> entries.</p>
<p>At the very end of the <code><a>post_config phase</a></code> any registrered <code><a>PerlPostConfigRequire</a></code> entries are run.</p>
<p>When any of the following configuration directives is encountered (during the configuration phase) mod_perl 2.0 is forced to start as soon as they are encountered (as these options require a running perl):</p>
<ul>
<li><p><code><a>PerlLoadModule</a></code></p>
</li>
<li><p><code><a><Perl> section</a></code></p>
</li>
<li><p><code><a>PerlConfigRequire</a></code></p>
</li>
</ul>
<p>Therefore if you want to trigger an early Perl startup, you could add an empty <code><a><Perl> section</a></code> in <i>httpd.conf</i>:</p>
<pre><code> <Perl>
# trigger an early Perl startup
</Perl></code></pre>
<p>right after loading the mod_perl module, if you are using DSO, or just before your mod_perl configuration section, if you're using a static mod_perl build. But most likely you want to use the <code><a>PerlConfigRequire</a></code> instead.</p>
<h2 id="Startup-File">Startup File</h2>
<p>A startup file with Perl code to be executed at the server startup can be loaded using <code><a>PerlPostConfigRequire</a></code>. For example:</p>
<pre><code> PerlPostConfigRequire /home/httpd/perl/lib/startup.pl</code></pre>
<p>It's used to adjust Perl modules search paths in <code>@INC</code>, pre-load commonly used modules, pre-compile constants, etc. Here is a typical <i>startup.pl</i> for mod_perl 2.0:</p>
<pre><code> #file:startup.pl
#---------------
use lib qw(/home/httpd/perl);
# enable if the mod_perl 1.0 compatibility is needed
# use Apache2::compat ();
# preload all mp2 modules
# use ModPerl::MethodLookup;
# ModPerl::MethodLookup::preload_all_modules();
use ModPerl::Util (); #for CORE::GLOBAL::exit
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::ServerRec ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use APR::Table ();
use ModPerl::Registry ();
use Apache2::Const -compile => ':common';
use APR::Const -compile => ':common';
1;</code></pre>
<p>In this file <code>@INC</code> in adjusted to include non-standard directories with Perl modules:</p>
<pre><code> use lib qw(/home/httpd/perl);</code></pre>
<p>If you need to use the backwards compatibility layer load:</p>
<pre><code> use Apache2::compat ();</code></pre>
<p>Next we preload the commonly used mod_perl 2.0 modules and precompile common constants.</p>
<p>Finally as usual the <i>startup.pl</i> file must be terminated with <code>1;</code>.</p>
<h2 id="Dealing-with-Restarts">Dealing with Restarts</h2>
<p>Ideally the code running at the server startup shouldn't be affected by <a href="#Start_Immediately_Restarts">the apache restart</a>. If however this is not the case, you can use <code><a>Apache2::ServerUtil::restart_count</a></code>.</p>
<h1 id="Maintainers">Maintainers</h1>
<p>Maintainer is the person(s) you should contact with updates, corrections and patches.</p>
<ul>
<li><p>Stas Bekman [http://stason.org/]</p>
</li>
</ul>
<h1 id="Authors">Authors</h1>
<ul>
<li><p></p>
</li>
</ul>
<p>Only the major authors are listed above. For contributors see the Changes file.</p>
</body>
</html>
|