Debugging Apache segfaults can be tricky, in an attempt to find out which module may be causing it. You might see something like this in the /var/log/httpd/error_log:

[Mon Aug 07 23:56:18.309463 2017] [core:notice] [pid 17630] AH00052: child pid 18187 exit signal Aborted (6)

1. You can do  using debug it the gdb option, like this:

   service httpd stop
   gdb /usr/sbin/httpd

   and quickly (before the dataskq starts it up again), run:

   run -X -d /etc/httpd

   And which should let you trigger one request in the foreground, so do it quickly, before any other connections arrive to your server.

1. Hopefully this was triggering your segfault, in which case it might show:

   Thread 1 “httpd” receives signal SIGABRT, Aborting.

   along with other info about exactly where it crashes.

2. To see more details about it in the function tree uses to get to that point, call a backtrace like this:

   bt full

   which should give you the list of functions calling, where it starting lower down, and ending at the top of the output. Somewhere in there might show you which module triggering it.

3. To quit gdb, just run:

   quit

CUSTOM HTTPD TEMPLATES: Starting point

DirectAdmin offers a huge variety of ways to customize your User’s VirtualHost entries. This guide will help you pick which method is up to use depending on what you need it to do.
To aid in speeding up paths, should you know what you want it to use, enter the info here:

There are 3 major sections to consider when deciding which method to use:

1. Raw Templates

   These are located in

   /usr/local/directadmin/data/templates/

   and we typically discourage relying on custom versions of these in case that we make important changes to them, in which case you would not get them.  In some cases, there you will need to do use a custom copy, but only if none of the options below work for you.  The typically 4 template in question would be:

   

   #OpenLiteSpeed
   openlitespeed_vhost.conf #combined for all 4

   but varies if you’re using other server types.

2. Per-Domain with the CUSTOM tokens via “Custom Httpd Config”

   This Admin Level area will  lets you insert code into any CUSTOM or CUSTOM# token point for all VirtualHosts in that domain, including the http+https for both domains and subdomains.
   This method is using only when you want to change a setting just for this domain.
   This GUI tool saves files to disk (depening on the token name), eg:

   /usr/local/directadmin/data/users/fred/domains/fred.com.cust_httpd     #CUSTOM
   /usr/local/directadmin/data/users/fred/domains/fred.com.cust_httpd.1   #CUSTOM1
   … #CUSTOM2, etc.

3. Tokens for Global, Per-User, Per-Domain

   This tool is using to inset token variables where applicable.  You are not saving a file for each CUSTOM token name, but can create the mentioned file below to pre-load some tokens. This will then allow you to set tokens before anything other CUSTOM tokens that are set (it’s not for code itself, just setting variables).  See this guide on how to set a token with the |?TOKENNAME=value| syntax.  Token variables can be using within a value eg:

   |?TOKENNAME=value of `OTHERTOKEN`|

   The files will be available to load in your custom tokens of various levels:

   

   where “httpd_tokens” is the name using, regardless of server type (httpd/nginx/litespeed/openlitespeed).
   This is independent of the template of the name, so these tokens will be loading into all of the 4 virtual_host2*.conf templates mentioned above.

4. Global VirtualHost Pre/Post

   These template depends on the “Template Name” above, so preset that if you’re trying to sort out which to use.
   Using these files will be writting the given code into the User’s httpd.conf either before or after, outside of the VirtualHost tag, for any use of the given template file.
   Paths can be either as follows:

   

   This took will be might be handy if you want to insert a https://webmail.domain.com VH (eg: you would use the /usr/local/directadmin/data/templates/custom/virtual_host2_secure.conf.post, so it only gets added once per domain, only for https)

5. Global Token name per file, pre/post

   The Similar to the global CUSTOM tokens, this will let you control only which template it goes with.  Your code will be inserting either before or after any use of the given CUSTOM* tokens.   For example, if you use the pre variant, this code is inserting before say, per-domain CUSTOM inserted code.  Possible files might be as follows:

1. Global CUSTOM token, regardless of filename

   This one is relating to the global tokens, except you can use this for actual code, as it is injecting in a specific order. Applies to all template files.  Possible files include as follow:

   

   taking note how the number of tokens have a dot between CUSTOM and the number.

Note: for almost all areas, you can use if-then-else syntax and place variables which carry forward within that template