Changes
FAQ
,no edit summary
Please also note that the logLevel will only influence the amount of output written to the log file. It does not affect the amount of output written to the console. If you're running WPKG from the command-line logLevel will not have any effect on the output there. To receive debug output on the console you need to use the /debug command-line switch. This allows WPKG client to run WPKG in the background as a service without using the /debug flag but using the /silent switch so no output is written to an invisible console - instead administrators can control the amount of output written to the logs by specifying logLevel either on the called command line or (more convenient from my point of view) within [[config.xml]].
== Logging: How can I customize the granularity of log-files? ==
You can enable/disable logging of the following log severities:
- errors
- warnings
- information
- audit success
- audit failure
There has been some proposals on Bugzilla to introduce several levels of debug logging in order to allow fine-grained control on the amount of logs written to the log files in debug mode. Even some patches have been posted to Bugzilla already.
However I am personally completely against such an "enhancement". From my point of view the log levels above are completely sufficient. In productive environment you will log errors, warnings and probably informational messages. On your test machines and for WPKG developers you will most probably enable debug logging to trace exactly what's happening inside WPKG. It looks like some people tried to use debug output in productive environment and of course there is too much output on debug level. So some people asked for a fine-grained debug-level setting.
Unfortunately such multiple debug levels create a maintenance nightmare. Even within a short discussion thread it showed that everyone has hes/hers own point of view how much output should be logged. I personally think that it would be impossible to satisfy the needs of everybody. Especially if there are no clear rules what exactly needs to be logged to which debug level which is an impossible thing to define for all future enhancements. Just imagine a new feature to be added to WPKG; the programmer adds some debug output - to which debug level should it be attached? I am absolutely sure if you're going to ask 10 people you will get as many different answers as log levels are available. Just a simple example is the logging of a list of packages read from the XML files. Somebody might argue that this should be printed within the lowest debug level since it's absolutely crucial for WPKG operation that the packages are correctly read. Somebody else might think this just blows up the log file with useless information since you know your XML files are correct and there will be no problem here.
As a result WPKG developers and administrators who need to debug will anyway use the highest available log level to debug in order to make sure not to miss the important parts. Such (technical) people are usually also able to handle such a huge amount of output using search, grep and other tools.
Another big drawback of a high amount of log levels is that log-files can show a huge amount of different detail level. Support requests posted to the WPKG support team might contain enough information for the administrator but not for the WPKG developers. So it will be anyway crucial to get a log file with the highest possible log level.
The log file size on a typical system (tested on my installations) is about 20-50kB) This size is still easily parseable and searchable.
Disadvantages of multiple debug log-levels:
- If you really have to find a bug you will anyway set the log level to the highest available level in order to make sure you don't miss the important parts.
- Everybody will anyway have a different view how much detail should be logged within a specific debug level.
- The result is that administrators and developers will anyway use the hightest available log level to make sure all information is available.
- Log files posted to the WPKG support (mailing list/Bugzilla) would potentially contain too less information.
- Full debugging log is not that huge so it is still possible to handle it - so no need to reduce the amount of output.
== Logging: Can I keep more than just the last execution log? ==
Yes you can. By default WPKG writes a log file using the name pattern "wpkg-[HOSTNAME].log". This will overwrite the same log on each execution. This was desired in order to prevent filling up the HDD with lots of log files. However if you use a pattern like "wpkg-[HOSTNAME]-[YYYY]-[MM]-[DD]_[hh]-[mm]-[ss].log" will write a new log file if WPKG is executed one second later again (and it's very unlikely to execute it twice within the same second).
It's clear that using such a pattern you will get lots of log files within the log file folder. Therefore it's recommended to have some cleanup tasks running on that folder (log rotation, log aging) - see the question about log rotation.
Some people also asked for log file appending instead of overwriting. I have chosen the overwriting approach in order to prevent the log file growing to infinite. Additionally appending changes the modify date of a log file which creates some problems with some log rotating scripts. So it's much better to write a new log file on each execution.
== Logging: What about log rotation? ==
WPKG itself does not contain built-in log rotation. I personally think this is a bad idea. Log rotating is not a core functionality of WPKG. Additionally there are numerous tools available which are specialized on rotating log files created by any application. Almost any Linux box already comes with a rotating tool like 'shrotate'.
Additionally there is a huge amount of ways to rotate log files. Some examples:
- based on size
- based on date
- based on name
- based on attributes
- any combination of the ones above
Well rotating is a very complex thing and needs to be very flexible to fit the needs of each environment and the flavor of the administrator. There is a big amount of tools out there which can do the rotation independently of WPKG. These tools are dedicated to log rotation. It's an illusion that WPKG will ever be as flexible as such a tool. Additionally I am against re-inventing the wheel and incorporating code into WPKG which is unnecessary and is prone to errors and bugs.
So the suggestion is clearly to use an external log rotation script if you would like to retain several log files. Personally I am perfectly fine with the default settings to just keep a log of the last execution per machine so I can see all the messages and errors produced by that machine at the moment. I am not really interested to know what happened during an installation months ago - I am just interested in the current system state - which is actually represented by the local [[wpkg.xml]] and the last execution log.
[[category:Documentation]]
[[category:Installation]]