any use case of logging.config.listen()?

[Zhang Weiwu]

Why would anyone use it? I can't think of use cases when one need to change
logging configuration dynamically through socket, but not needing the same
flexibility on overall configuration for his application (configparser). It
feels strange to design a socket interface only to expose logging
configuration. If you use logging.config.listen, I very much wish to know
what problem are you attacking.

I imagined this use case, and invite you to debate if it be valid. Thanks.

To design a GUI monitor of a daemon, like amule-gui (log-reading
monitor for amule) or pureadmin (log-reading monitor for pureftp).
Here is how:

1. The user starts the monitor on his PC. It socket-coneect the
daemon written in python - perhaps wrapped by SSH protection - and
send a new config file that adds SocketHandler with his own IP
address and port.

2. The daemon starts to emit log to TCP socket, the user watches his
monitor.

3. When the user finishes, the GUI monitor sends a new config file
to remove the handler (is it possible with current API?) Or, the
user drops out, the server finds socket dead and removes the
SocketHandler on its own.

It works like FTP's PORT command, asking server to establish
connection back to the client. Unfortunately this technology doesn't
work nowadays when most PCs are behind NAT firewall.

It begets the question, that if it is easier to write a socket-listening
loging handler and forget all about logging.config.listen() stuff. I never
did it before, hence the question.

 

[Zhang Weiwu]

Thank you a lot for your case description.

But why develop all of that code when logging.config.listen() already
exists? Adding a new SocketHandler seems more heavyweight (and more
risky) than adjusting the logging level on an existing SocketHandler.

There are 2 reasons that i cannot just use existing API for the project I am
working on.

1. My monitoring GUI client is often behind various NAT. In fact it is a
hand-held client, I could be using it in a café's WIFI. It is impossible to
tell the python-daemon to just send the log to given address and port.

2. I forgot to explain that in my project adjusting log level is only half
of what needs to be done. The monitoring GUI client also needs to be able to
send a few operational parameters' change. e.g. I need to see the log, and
decide to change 'Threshold' from 0.5 to 0.53 and see the difference.

For the first problem, a new logging.ListeningSocketHandler would work -
don't know if it is easy to write one - which can be written in a way that
simply drops logs if no one is listening, thus forgoing logging.config.listen().

For the second problem, a way to dynamically accept new operational
paramters from socket is needed, solo logging.config.listen() wouldn't
suffice.

Either case I don't find use of logging.config.listen(), even though I am
looking hard for every way to reuse existing code.

 

[Chris Angelico]

Either case I don't find use of logging.config.listen(), even though I am
looking hard for every way to reuse existing code.

That's not a problem. It's a feature that doesn't quite fit your task,
so you don't use it. It's like trying to install an operating system
on a new computer and deciding that emacs isn't the one for you.
*dives for cover*

ChrisA