# termination problem mustgather

IBM HTTP Server customers occasionally encounter problems stopping the
web server. The expected result of `apachectl stop` or sending the
`SIGTERM` signal to the IHS parent process is that all httpd processes
for that web server instance will exit within around thirty seconds.
When this does not occur, IBM HTTP Server support needs data to be
collected on the remaining httpd processes to help diagnose why the
processes have not terminated.

When this type of problem occurs, the remaining httpd processes normally
show "1" for their parent process id, as shown in this example:

    $ ps -ef | grep httpd 
      nobody 15876     1   0   Feb 08      -  0:00   /usr/HTTPServer/bin/httpd
      nobody 17112     1   0   Feb 08      -  0:00   /usr/HTTPServer/bin/httpd
      nobody 17524     1   0   Feb 08      -  0:00   /usr/HTTPServer/bin/httpd
      nobody 19252     1   0   Feb 17      -  0:00   /usr/HTTPServer/bin/httpd
      nobody 20048     1   0   Feb 08      -  0:00   /usr/HTTPServer/bin/httpd
      nobody 20944     1   0   Feb 08      -  0:00   /usr/HTTPServer/bin/httpd
      nobody 21734     1   0   Feb 17      -  0:00   /usr/HTTPServer/bin/httpd
      nobody 24166     1   0   Feb 17      -  0:00   /usr/HTTPServer/bin/httpd

Before killing the processes manually, gather the required
documentation, as directed below.

#### Special note for known problems

IBM HTTP Server 2.0.42.x

Before submitting documentation to IBM for analysis, ensure that you are
using cumulative e-fix PK01070 [or later](questions.html#20EFIX) to
correct a pervasive termination problem.

IBM HTTP Server
2.0.47.x

##### Failure to terminate IBM HTTP Server on Unix and Linux when used with IBM Tivoli Monitoring

The `apachectl stop` command sends the SIGTERM signal to the httpd
parent process in order to shut down the web server. When IBM HTTP
Server is started under IBM Tivoli Monitoring, the SIGTERM signal may be
masked by IBM Tivoli Monitoring. This will cause the `apachectl stop`
command to be ineffective.

A work-around for this problem is to start IBM HTTP Server using a
special Perl script which restores the SIGTERM signal before starting
IBM HTTP Server.

1.  Save this Perl script in a file called
    `/usr/local/bin/unblocksigterm.pl`:
    
    ``` 
    #!/usr/bin/perl -w                    
    use strict;                           
    use POSIX;                            
    my $how = SIG_UNBLOCK;                
    my $set = POSIX::SigSet->new(SIGTERM);
    if (!sigprocmask($how, $set)) {       
      die "sigprocmask failed: $!";       
    }                                     
    my $cmd = join(' ', @ARGV);           
    print "$0: running $cmd\n";           
    my $rc = system($cmd);                
    exit($rc != 0 ? 1 : 0);
      
    ```

2.  Mark the Perl script as executable with `chmod`:
    
    ``` 
    # chmod +x /usr/local/bin/unblocksigterm.pl
      
    ```

3.  Start IBM HTTP Server using `unblocksigterm.pl` by adjusting the
    command specified in the IBM Tivoli Monitoring configuration:
    
      - Old:   
        `/usr/HTTPServer/bin/apachectl start`
      - New:   
        `/usr/local/bin/unblocksigterm.pl /usr/HTTPServer/bin/apachectl
        start`

## Gathering documentation

The hang documentation tool is used to gather the required
documentation. When using the tool, specify **auto** as the value of the
parent process id parameter, and specify **-** as the non-SSL address
parameter, as in the following example:

    # java -jar ServerDoc.jar GatherHangDoc /usr/HTTPServer auto -

After trying to stop the web server, wait at least sixty seconds before
gathering documentation.

The [hang documentation instructions](gather_hang_doc.html) have further
information about the use of the tool.