Better logging required

[ThomasAdam]

At the moment, FVWM3's logging is OK if you know where to look, but ultimately overly verbose.

We should standardise on using something like log_debug() to do our logging for us, and allowing the user to set a path/filename to the log file.

This should be toggleable via USR2, for example.

Auditing of existing fvwm_msg() callers should be done to determine what's still relevant.

A start on this should be made for milestone 1.0 if possible. See: ta/logging

[ThomasAdam]

A start on this has been made, and is now merged to master ready for 1.0

This now means:

• Callers using fprintf(stderr, ...); have been converted to use fvwm_debug();
• Logging now happens to a file: fvwm3-<PID>.log, typically in $HOME -- this is to reduce the confusion around where some display managers log STDERR to.
• Logging can be toggled at run-time by sending SIGUSR2 to fvwm3, a la: pkill -USR2 fvwm3

Post 1.0:

• Rationalise logging (less verbose/more accurate);
• Add additional log lines in the code;
• Check module support for libs/log.c and check they can use it -- some modules (FvwmIconMan? replicates fvwm_msg() itself because it's not in libfvwm.

[afhp-2020]

Is there any way to enable logging at startup, instead of explicity with SIGUSR2 ?

When something goes wrong as Fvwm is setting itself up, the old log in xsession-errors caught everything. Now if one has to wait until it's up (when it does come up) manually activating logging is much too late in the process.

[ThomasAdam]

@afhp-2020,

You can pass -v to fvwm3, hence: fvwm3 -v

Pull from master first...

[afhp-2020]

Pulling from master is what got me in today's rabbit hole (other report incoming).

Some issues I've noticed:

• fvwm -v on a "fresh" setup works fine: the log is created and filled.
• fvwm -v if there already is a ~/fvwm-<some pid>.log will not open a new log and will not update the existing log (the latter makes sense, since the pid has changed; but there is no fvwm-<new pid>.log either). This is observed when completely exiting fvwm and relaunching it.
• Restarting fvwm will stop updating the current log (the pid is unchanged), while the toggle is still on ; in other words, after a restart SIGUSR2 must be sent twice otherwise nothing new appears in the log.

[ThomasAdam]

Hi @afhp-2020,

Yeah. Removing the PID from the filename makes sense here. Since the log file is opened in append mode, this should keep writing to it. I'm about to merge to master a fix for this, such that the log file is: ~/fvwm3-output.log.

Restarting fvwm3 keeps appending to this file, and I don't need to keep toggling fvwm3 via SIGUSR2. If I do, and fvwm3 -v is already present, it toggles as expected.