plugin-directory verified
Where plugins are loaded from
plugin-directory: …Directory of shared objects the engine loads at start-up, giving custom C code a place inside the delivery path.
Values
- Values
directory containing .so files- applying
restart required- where it can be set
in the config file · with a startup flag · as an environment variable
In detail
The vendor documents the plugin interface in detail — an API version, three exported entry points (mq_version, mq_initialize, mq_cleanup), and a header shipped in the package at /usr/include/mailerq.h — while the directive that loads plugins appears in no help output. We found it by probing the binary, and the binary contains both the directive name and the error text for a plugin that fails to export mq_version. Plugins are loaded in alphabetical order, which is why the vendor's examples are numbered. They run inside the engine's event loop and may modify messages, so a blocking call in a plugin stops delivery for everything, not just the message in hand. For us this is a capability to know about rather than use: it is the escape hatch for a customer who needs behaviour MailerQ does not have, and the reason to be careful about what a customer is allowed to install on a node we operate.