[Rspamd-Users] cannot execute /etc/rspamd/custom-ratelimit.lua: attempt to call a nil value

George Asenov george.asenov at wpx.net
Wed Aug 31 11:25:38 UTC 2022

Hi Ged,

Thanks for your answer.
But my file is 69 lines of code. Most of it is modified example from the 
rspamd documentation.

The line ratelimit.lua:852 is part of the rspamd source code probably 
responsible for loading the custom script.

I have tried to comment out many parts of my code and also set some 
static values to some of the variables but the error didn't change.

Hope someone more familiar with lua (I'm newbie with it) to spot maybe 
obvious error in my code.

On 31-Aug-22 12:40 PM, G.W. Haywood via Users wrote:
> Hi there,
> On Wed, 31 Aug 2022, George Asenov wrote:
>> I'm trying to write custom ratelimit script but it keeps failing at 
>> start with:
>> ###########
>> lua; ratelimit.lua:852: cannot execute 
>> /etc/rspamd/custom-ratelimit.lua: attempt to call a nil value
>> ...
> I've never in my life written lua code, but seeing an error message
> like that would make me ask
> "What's at line 852?"
> My guess is that it's something with an undefined (nil) value. :)
> If there are many things on line 852 capable of taking values you can
> try somehow to separate them onto multiple lines.  The error messages
> you get might then tell you which of the values caused the problem.
> Of course the code you've posted doesn't have anything like 852 lines.
> If you think that it really is what's causing the error, first you'll
> probably need to find out what other code is wrapped around yours, so
> you can count the lines in the same way that the lua interpreter does.
> Alternatively you can put some 'do nothing' lines in your code before
> (hopefully) the part causing the error, just to see if the line number
> in the error message changes.
> Generally speaking if you're starting new development from scratch I'd
> recommend starting with something very, *very* simple, so that you can
> build on something which 'works' - which is usually a lot easier than
> trying to fix something which doesn't.  If you started with something
> like the code in your post, you could for example comment out lots of
> it until you get something which at least runs, even if it doesn't do
> what you want when it does.  Then you can incrementally uncomment the
> commented parts, so you gradually approach the objective, and errors
> are revealed as you uncomment more or less one line of code at a time.
> Sorry not to be more help than that.

Warm regards
George A.

More information about the Users mailing list