Closed dmik closed 3 years ago
Note that I now think that it's better to put all logs into a single directory rather than in a per-library one. For this, we will have to prefix each log file with the library name but that's totally fine as it wont' change the overall file name length. The main benefit here is to avoid maintaining per-library directories and also allows to have logs from different libraries but for the same process side by side. This is something to think on, though.
Currently, I propose the following log file name format:
TTTTTTTT-XXXX-EXE-LIB.log
Where TTTTTTTT is the number of seconds since 01.01.1970 (QSV_TIME_LOW), XXXX is a process ID in hex, EXE is an executable file name and LIB is a library name the log belongs to (i.e. libc or libcx).
This way, logs will be sorted by timestamp (i.e. in order they are created) which is usually also the best, especially when there are many related processes. Then by PID, which also makes sense. And the rest is basically to disambiguate.
Note that if we go with a single log dir, LIBCx will need a (minor) patch as well. Including its RPM .spec — to remove the /var/log/libcx/
directory association from there.
Note also that EXCEPTQ logs should go into that single directory as well then, see #99.
All done, logs (with names like above) now go to %LOGFILES%\app
, or to %UNIXROOT%\var\log\app
or to the root dir of the boot drive if the previous two locations are not set or don't exist. Note that I introduced the app
subdirectory so that these logs won't mix with other system logs like install logs, single-file app logs like cups.log
etc. This app
subdir is shared rather than being owned by LIBC -- any application is encouraged to write its runtime logs there provided it follows the naming scheme (for sorting and to avoid naming conflicts).
Note that .TRP also go to that directory now, see #99.
I need to adapt LIBCx to these changes and we are done here.
All seems to work.
Currently, they are put in to the current directory with file names
libc_XXXX.log
where XXXX is the process ID in hex.This behavior has a big disadvantage — imagine a complex app running helper child processes that change the current directory. Logs from those child processes may end up anywhere on the drive and it's very inconvenient to gather them all when debugging and/or analyzing logs. Also, if the current directory is read-only, you will not get logs at all.
For LIBCx we already have it solved by putting all its logs into
/@unixroot/var/log/libcx/
(see https://github.com/bitwiseworks/libcx/commit/08942948944de346063d3c5139ef68ba9716a46a) and it has proven to be very convenient — including cases when a user has to run log-enabled DLL and then collect all of the logs. This is also very useful in terms of housekeeping, obviously.