No logging in 6x

So it is blocking but not logging or did you only see if it was logging?

That feature wouldn't have been removed on purpose.

From what I've seen.. Inside the hook_boot() implementation:

  if (variable_get('troll_enable_ip_ban', 1)) {
    $domain = db_result(db_query_range("SELECT domain_name FROM {troll_ip_ban} WHERE (expires > %d OR expires = 0) AND ip_address = '%s'", time(), $ip, 0, 1));
    if ($domain !== FALSE) {
      global $base_url;
      watchdog('troll', 'IP Ban: @addr Domain: @domain', array('@addr' => $ip, '@domain' => $domain), WATCHDOG_INFO);
      $troll_ip_ban_redirect = variable_get('troll_ip_ban_redirect', '');
      if (empty($troll_ip_ban_redirect)) {
        include_once('includes/common.inc');
        $page = drupal_get_path('module', 'troll') .'/blocked.html';
      }
      else {
        $page = $troll_ip_ban_redirect;
      }

According to the troll.module code, the watchdog message should only appear if the domain is not FALSE.
According to troll.install code, domain_name in {troll_ip_ban} is 'not null' => TRUE, 'default' => '' <- empty string.
When submitting the Ban IP form, the value for domain_name is, even if empty, '' <- empty string.

So the only reasons to not watchdog the message are:
- IP address in not banned, it is possible because this code is out of the if (troll_is_backlisted()) conditional logic.
- The Ban has expired, and therefore the query founds no entry.

So just watching the code, if you get the blocked.html page, than for sure the watchdog() call has been executed, because if $domain is false, the IP address is not banned.

But, just to confirm, the only reason why watchdogs are not logging is because it is the hook_boot() implementation, if this message is not being logged, then ANY of the messages are being logged. May that be true?

The place to call the hook hook_boot() during bootstrap is at _drupal_bootstrap() in bootstrap.inc

        ...
        // Load module handling.
        require_once './includes/module.inc';
        bootstrap_invoke_all('boot');
        ...

/**
 * Call all init or exit hooks without including all modules.
 *
 * @param $hook
 *   The name of the bootstrap hook we wish to invoke.
 */
function bootstrap_invoke_all($hook) {
  foreach (module_list(TRUE, TRUE) as $module) {
    drupal_load('module', $module);
    module_invoke($module, $hook);
  }
}

The modules are loaded and then the hook_boot is called. The order of loading is based in the arguments used to call module_list(), the first TRUE is to refresh a previously saved list, and the second argument (bootstrap) is to load only those modules marked to be loaded during bootstrap (caching and alike modules):

$result = db_query("SELECT name, filename, throttle FROM {system} WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight ASC, filename ASC");

Troll is in that list, but dblog (aka, database logging) is not included in this list. I guess we can say, any logging is being done currently during the hook_boot() implementation. Even including the module in the bootstrap list, it would require an equal or lower weight than troll module to be working.

I've spotted several solutions here, but I don't feel comfortable with any of them. it is possible to load dblog module in troll_boot() (drupal_load('module', 'dblog') and that would do, but there is to check the module is already enabled, and this doesn't cover syslog, and other logging modules. It can also be fixed setting the messages during hook_boot, and logging them later during hook_init().

I want to confirm: it is not logging anything during hook_boot, and this includes the following messages:

watchdog('troll', 'Alternate blank page displayed to @ip', array('@ip' => $ip), WATCHDOG_INFO);
watchdog('troll', 'Alternate 404 page displayed to @ip', array('@ip' => $ip), WATCHDOG_INFO);
watchdog('troll', '@ip redirected to @url', array('@ip' => $ip, '@url' => $url), WATCHDOG_INFO);
watchdog('troll', 'Data submission ignored with notification to user from @ip', array('@ip' => $ip), WATCHDOG_DEBUG);
watchdog('troll', 'Data submission ignored silently from @ip', array('@ip' => $ip), WATCHDOG_DEBUG);
watchdog('troll', 'Page load stuttered from @ip', array('@ip' => $ip), WATCHDOG_DEBUG);
watchdog('troll', 'IP Ban: @addr Domain: @domain', array('@addr' => $ip, '@domain' => $domain), WATCHDOG_INFO);

I've included the testcase for this issue, it tests very basically the blocking functionality, and does also changing bootstrap flag for dblog module.

Confirming that blocked IPs are not logged into watchdog at admin/reports/dblog This is with Troll 6.x-1.x-dev (2009-Aug-03). I haven't tried patch in comment #5. I didn't notice that Troll 5.x was logging the blocked IPs into watchdog.

Steps to reproduce this issue with 6.x-1.x-dev (2009-Aug-03).
1. Ban an IP address.
2. Using above banned IP address try to access the site.
3. The IP ban works. Banned IP can't access the site.
4. The IP address isn't log into watchdog at admin/reports/dblog though. Expected result is that the access attempts done by the banned IP address should be log into watchdog at admin/reports/dblog.

If someone else want to contribute testing here is an easy way to test a banned IP.
1. Go to admin/user/troll/ip_ban and ban the IP Address 85.214.74.70 Domain Name http://ipinfo.info
2. Go to http://ipinfo.info/netrenderer/index.php and type in your site URL into the field at the top of this page. Click on RENDER button.
3. If successful the Troll banned page (blocked.html) will be display down this page.
4. Go to watchdog at admin/reports/dblog to check if the above access attempt has been log.

I created this issue specific to the watchdog message on blocking a user (not when a blocked ip or user attempts access): #749924: Add watchdog record when a user is blocked

Marked #541936: Blocked events are not registered in dblog as a duplicate.

If this is still an issue, please re-open and upgrade version to D7. Drupal 6 is no longer being maintained.