Hi Jack! 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. 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.
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. 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. Best, Albrecht. [1] <https://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html>
Attachment:
pgp40H6fo4gVN.pgp
Description: PGP signature