Re: [Proposal/Patch] SMTP logging

On 2019.08.01 06:45, Albrecht Dreß wrote:
Am 31.07.19 22:24 schrieb(en) Jack via balsa-list:
Mostly, but a few more details. First, would it be correct to say "... sylogd (or equivalent)..."?
Yes – syslog, syslog-ng, samhain/yule, etc. all serve this purpose… Citing form IEEE 1003.1 [1]: The syslog() function shall send a message to an implementation-defined logging facility, which may log it in an implementation-defined system log, write it to the system console, forward it to a list of users, or forward it to the logging facility on another host over the network.

Second, am I correct, then, the all/most of the current Balsa logging is for the benefit of the user, but this new stuff really targets the sysop, so some useful info is more likely to be found when a user complains?
Exactly. Depending upon the settings, balsa's status messages are displayed either in balsa itself (dialogue, status bar, etc., i.e. they are just lost shortly) or using the session's notification mechanism, or go to stdout/stderr (also depending upon the value of the G_MESSAGES_DEBUG environment variable), where they end up either in ~/.xsession-errors if balsa is launched by the window manager, or are again lost if it is run manually from a terminal unless the output is redirected to a file.
Might it make sense (as a wishlist item) for Balsa (optionally?) to create a log file (perhaps in the .balsa directory) with configuration to allow how many versions to keep? A possible configuration item could be loglevel (or simply whether to log what normally goes to stdout or only what goes to stderr).

The syslog mechanism guarantees that these messages will *always* be stored in a standard place where they can be used for the (rather unlikely) debugging purpose I outlined in my previous message.
As I said, I have no objection to this - I'm just trying to play with how this might end up more integrated with the overall Balsa logging mechanism.

I have no idea of the balance of machines on which Balsa runs - between single user/home machines and machines where there really is likely to be a separate sysop. Or - is this to provide info to the (local) user who then provides it to the (remote) sysop (of the mail server) when there is a problem?
I think both scenarios are possible, depending upon the user's skill level.

If this is the case, then what/how/why does syslog provide compared to logging the same string with Balsa's currently used logging mechanism?
Well, as I outlined above, /most/ of balsa's status output is just lost when balsa is closed. The best case would actually be logging to stdout or stderr, which is then added to ~/.xsession-errors. However, this file is usually rotated only once, i.e. you will find ~/.xsession-errors for the current session, and ~/.xsession-errors.old for the previous one. If you want to trace a message you sent during the, say, next-to-last session, the corresponding .xsession-errors has already been erased.
So this might be addressed with the above suggestion of Balsa just saving it's log to a file (either by default or configuration or command line switch). Yes, such a log would be under the user's home dir (which makes sense to keep separate user's logs separate) but in case of the problems which started this thread, the user is going to have to forward that information to someone else anyway, so the only real importance is for the user to easily know where that information is.

In contrast, the syslog facilities are typically configured to keep a longer period and/or amount of messages (on Debian, look at /var/log/mail.log*) which makes it a lot more likely to find the requested information even after a longer period of time.

I would like to stress that this debugging purpose is a rather exceptional case for Balsa's logging – I think *all* other messages actually should be displayed to the user, who has to act on them accordingly.


[1] <>

I'm trying to think of the range of approaches by other apps I use. Some drop logs under the user's home, some use syslog, some have separate logs or log dirs under /var/log, some have areas under /etc or /var, I assume there are others. However, I can't think of any reason any one of them should set a precedent for Balsa. I suppose your syslog patch is easy enough to put in place now, and separately continue the discussion of what to do with the rest of Balsa's logging, and coalesce later.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]