Hi i considered how to do that on my own after sa-update but finally came to the conclusion that would make things more complicate or even i did not realize a good reason why not to do it at all as far as i can see the shipped cronjob don't make use of "sa-compile" while the description sounds promising performance wise _________________________________________ NAME sa-compile - compile SpamAssassin ruleset into native code SYNOPSIS sa-compile [options] Options: --list Output base string list to STDOUT --sudo Use 'sudo' for privilege escalation --keep-tmps Keep temporary files instead of deleting -C path, --configpath=path, --config-file=path Path to standard configuration dir -p prefs, --prefspath=file, --prefs-file=file Set user preferences file --siteconfigpath=path Path for site configs (default: /etc/mail/spamassassin) --updatedir=path Directory to place updates (default: /var/lib/spamassassin/compiled/<perlversion>/3.004000) --cf='config line' Additional line of configuration -D, --debug [area=n,...] Print debugging messages -V, --version Print version -h, --help Print usage message DESCRIPTION sa-compile uses "re2c" to compile the site-wide parts of the SpamAssassin ruleset. No part of user_prefs or any files included from user_prefs can be built into the compiled set. This compiled set is then used by the "Mail::SpamAssassin::Plugin::Rule2XSBody" plugin to speed up SpamAssassin's operation, where possible, and when that plugin is loaded. "re2c" can match strings much faster than perl code, by constructing a DFA to match many simple strings in parallel, and compiling that to native object code. Not all SpamAssassin rules are amenable to this conversion, however. This requires "re2c" (see "http://re2c.org/"), and the C compiler used to build Perl XS modules, be installed. Note that running this, and creating a compiled ruleset, will have no effect on SpamAssassin scanning speeds unless you also edit your "v320.pre" file and ensure this line is uncommented: loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody Additionally, "sa-compile" will not restart "spamd" or otherwise cause a scanner to reload the now-compiled ruleset automatically.
I think this is pretty much a no go. We don't want to require a c-compiler just to use spamassasin. Unless I am missing something, this is not something we want to enable by default.
OK, agreed as default but what about a "hook" somewhere to enable in /etc/sysconfig with a clear comment, the point i try to make is that the update-cron is pretty fine and restarts SA only if there where updates if one want to have the rules compiled it gets difficult because it needs to run after that, compile and restart SA again - with a configuration hook without dependencies one only needs to know "OK, i have to install that list of packages and enable that behavior" to get all at once without hacks and multiple restarts
Sure, I'd be open to patches that add a (disabled by default) hook for this.
what about a conditional "if file/script xyz exists call it" in /usr/share/spamassassin/sa-update.cron between the update itself and restart spamassassin?
Parse /etc/mail/spamassassin/*.pre and look for an uncommented load of the Rule2XSBody plugin. It's present but commented-out in v320.pre. If uncommented, it indicates that the admin wants to use compiled rules.
Created attachment 1492798 [details] Patch against 3.4.2 from Fedora 29 Invoke sa-compile before restarting spamd IFF Rule2XSBody plugin is enabled and re2c is present, indicating that the admin wants compiled regular expressions.