KP-8688 Add a syslog handler

[Traubert]

(Keep old file-logging as well for now for testing purposes)

[mmatthiesencsc]

The change looks sensible,

[mmatthiesencsc]

So is this preparing the general logger for syslog and not using it as default?

[Traubert]

@janiemi, I sent a review request, mostly just to let you know that we're trying to make logging from multiple threads more failsafe by using rsyslog on our servers to do the logging. This will also make it easier (hopefully) to direct logs to an external logging service one day. This, and the authserver PR, are for that.

[janiemi]

I think it’s great if it helps logging from parallel processes avoid messing up the log.

However, does writing to syslog mean writing to the same file as other types of processes using the syslog facility, or would Korp still have a log file of its own? If the former, I’m wondering if the current logging format is too verbose for that.

By the way, to simplify things and to avoid duplication, I have removed support for the plugin-specific config.py configurations from the development version of the plugins and the plugins library that intends to be compatible with the current version of Språkbanken’s Korp backend. pluginconf in __init.py__ will thus be the place for configuration variables and their default values.

(I’m sorry I still haven’t cleaned up the Git branches.)

[Traubert]

However, does writing to syslog mean writing to the same file as other types of processes using the syslog facility, or would Korp still have a log file of its own? If the former, I’m wondering if the current logging format is too verbose for that.

There's also configuration for syslog to handle the messages in an appropriate way, so they should end up in eg. /var/log/korp/, or even where they always were, if we want. They do currently also go to /var/log/messages, but I think I can get them prevent that with more configuration.

By the way, to simplify things and to avoid duplication, I have removed support for the plugin-specific config.py configurations from the development version of the plugins and the plugins library that intends to be compatible with the current version of Språkbanken’s Korp backend. pluginconf in __init.py__ will thus be the place for configuration variables and their default values.

Ah, ok, good to know. So the way to have our own site-specific configuration will be to have a branch just for that with edits to __init.py__, or make some alterations to it on deployment, or something?

[janiemi]

Good that you can configure where the log info is written to. I’m then ready to approve these changes. (I admit that I’m not familiar with the syslog facility.)

Ah, ok, good to know. So the way to have our own site-specific configuration will be to have a branch just for that with edits to __init.py__, or make some alterations to it on deployment, or something?

Definitely not: the plugin configurations are also defined in Korp’s config.py (or typically, instance/config.py). Please see the documentation for some more details.

Even though it might be more modular to have separate config.py files for each plugin, I began to think that it would be also be more complicated and that it might not always be obvious where a configuration value comes from, so I decided to remove support for plugin-specific configuration files.