DeutschEnglish

Submenu

- - - By CrazyStat - - -

8. November 2019

rspamd and redis: Random Connection refused errors

Filed under: Server Administration — Tags: , , , , , — Christopher Kramer @ 19:35

For some time, I am using rspamd as Spamfilter. By the way, I can really recommend it over Spamassasin / Amavisd-new solutions. I configured rspamd to use a redis database for the bayes filter, neural network etc.

Everything worked well until after some time, probably due to an update, it started spitting out Connection refused errors like these:

2019-11-07 06:25:10 #32043(normal) rspamd_redis_stat_keys: cannot get keys to gather stat: Connection refused
2019-11-07 06:25:15 #32042(normal) <4n3xhp>; lua; neural.lua:855: cannot get ANN data from key: rn_default_default_t66yaxz4_0; Connection refused
2019-11-07 06:25:15 #32044(normal) <4n3xhp>; lua; neural.lua:1101: cannot get ANNs list from redis: Connection refused
2019-11-07 06:25:15 #32040(controller) <4n3xhp>; lua; neural.lua:1135: cannot exec invalidate script in redis: Connection refused

Not every connection to redis failed, but quite a lot. This is a Debian Stretch system with a local redis 3.2.6 database and rspamd 2.1 running on the same host. So network problems couldn’t be it. The redis logs did not even mention the failed connections, the MONITOR command of redis also did not show anything for the refused connections. Restarting redis didn’t change anything, but restarting rspamd solved the problem for about an hour, when the problem started again. I tried adjusting the linux open files limit, the number of maximum redis connections and timeout settings without any luck.

Finally, I found the setting that solved the problem. My redis configuration in /etc/rspamd/local.d/redis.conf had looked like this:

password = "somePassword";
write_servers = "localhost";
read_servers = "localhost";

Changing it to this solved the problem:

password = "somePassword";
write_servers = "127.0.0.1:6379";
read_servers = "127.0.0.1:6379";

The problem seems to be that localhost both resolves to an IPv4 address and an IPv6 address. Redis, however, is configured to only listen on the IPv4 address in /etc/redis/redis.conf:

bind 127.0.0.1

Rspamd seems to sometimes use the IPv4 address, which works, and sometimes the IPv6 address, which doesn’t. This is why the problem seems to occur randomly.

Hope this helps somebody to find the issue faster. If this saved your day, please drop a comment.

Recommendation

Try my Open Source PHP visitor analytics script CrazyStat.

5. July 2018

PHP: trying to catch an Exception, but it never gets caught?

Filed under: PHP — Tags: , , , , , — Christopher Kramer @ 20:24

You are trying to catch an Exception like this and it never gets caught?

<?php
try {
// whatever you do here
// probably, you use some library
} catch(Exception $e) {
// this never works
}
?>

Most likely, your app is in some namespace. This means with the above code you only catch exceptions of the namespace of your app, not any exception. The solution is easy, just add a backslash:

try {
// whatever
} catch(\Exception $e) {
// this should work
// note the backslash!
}

Hope this helps somebody.

4. May 2015

Typo3 6.2 and Crawler Failed opening required ‘PATH_t3libclass.t3lib_page.php’

Filed under: Typo3 — Tags: , , , , , , — Christopher Kramer @ 11:28

Typo3 6.2 with the current version of the crawler from TER (3.5) gives this error when executed by the planner from cron:

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_page.php' (include_path='[...]') in [...]typo3conf/ext/crawler/class.tx_crawler_lib.php on line 30

Or if you open the crawler module in the Info-Module, you get only a blank screen and these errors in the log:

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_pagetree.php' (include_path='[...]') in [...]typo3conf/ext/crawler/modfunc1/class.tx_crawler_modfunc1.php on line 30, referer: http://[...]/typo3/mod.php?M=web_info&moduleToken=[...]

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_pagetree.php' (include_path='[...]') in [...]/typo3conf/ext/crawler/modfunc1/class.tx_crawler_modfunc1.php on line 30, referer: http://[...]/typo3/backend.php

I found a bug report for this exists in the crawler bugtracker for over a year now. And the current crawler version 3.6.2 also fixes the problem, but for some reason is not in the TER yet. So to solve the problem:

Download crawler version 3.6.2 and replace “/typo3conf/ext/crawler/” with the contents of this archive.

Hope this helps somebody solving the issue faster.

4. October 2012

PDO / sqlite: database table is locked

Filed under: DBMS,PHP,phpLiteAdmin — Tags: , , , , , , , — Christopher Kramer @ 22:06

At the moment I am working again on phpliteadmin, a  php-based web GUI for database administration of sqlite databases. While debugging, I stumbled across a problem that only occurred with the PDO extension (not with SQLiteDatabase or SQLite3). I got the following error message while trying to drop a table:

HY000 / 6 / database table is locked

By the way, you can use PDO::errorInfo() to get these error messages. So as the error correctly explains, the table I tried to drop seemed to be in use. PDO documentation for PDO::query() also explains the problem (even though DROP TABLE statements are fired using PDO::exec()):

If you do not fetch all of the data in a result set before issuing your next call to PDO::query(), your call may fail. Call PDOStatement::closeCursor() to release the database resources associated with the PDOStatement object before issuing your next call to PDO::query().

So I hunted for the open cursor on a resultset of the table in question and could not find any. Finally, I found the SQL statement which still had an open cursor:

SELECT * FROM sqlite_master

Thinking about this, it is obvious: When querying sqlite_master, you request information about database tables. If one of the table gets altered or dropped, this might change the data listed in the resultset on which I still have a cursor.

Maybe this is a special case as usually you do not query sqlite_master a lot. But in case you do, this might be useful information.

To solve the problem, as the manual says, simply release the cursor using PDOStatement::closeCursor() before dropping/altering tables.