"./bin/instance logtail" now needs a logfile argument

[jensens]

Usually, with ZServer, it was enough to do a ./bin/instance logtail. Now with WSGI this is not sufficient.

So, ./bin/instance logtail var/log/instance.log works.

Is this by intend? Or is it a regression?

[MrTango]

@petschki any idea?

[MrTango]

ah no @tschorr was working on that ;)

[tschorr]

I wasn't. I guess nobody was, that's why it's broken 8-)

[dataflake]

I have looked at it a little bit and I'm not sure if it's possible to bring this back in a sane way.

With WSGI, Zope does not use its own logging configuration anymore, and we cannot just read log file paths out of zope.conf. Logging is configured in the WSGI .ini configuration.

Yes, I can find that file while startup is processing, but I can't rely on finding specific names or contents because plone.recipe.zope2instance allows users to create and use their own WSGI configuration. As far as logging configuration goes, it's free form.

The logging module doesn't have any functions to e.g. say "read this configuration and give me information about it", like what handlers and their file paths are defined. It just allows you to load it and reconfigure the logging system with it. Even if you just load it and the configuration is changed there's no good way to ask the logging module about all its loggers and their handlers. Since logger naming is essentially unknown at that point (with user-created WSGI configurations there may not be a plone logger) the only logger you will always get reliably is the un-named root logger.

The best I can think of is to do the following in plone.recipe.zope2instance.ctl.main:

• load the configuration with logging.config.fileConfig(options.wsgi)
• get the root logger with logging.getLogger()
• iterate over the root logger handlers attribute and trying to find a logging.FileHandler, which in turn has the log file path in its baseFilename attribute
• set options.logfile to the value of baseFilename

Feels a bit scary and convoluted.