|1. Windows port|
|2. CLF option|
|3. Info option|
|4. Additional external hooks|
|5. Time-related features|
|6. Use a better mechanism for signals|
|7. Integrate as an Apache module|
If you can help on these subjects or if you have other ideas and suggestions, you're welcome.
Some managelogs features are still Posix-specific (like setuid/setgid), generally because the corresponding feature is not available in the APR library.
The code should be more portable, especially on Windows. Either the Unix-specific features have a Windows alternative, or they must be disabled on Windows.
Then, provide a binary distribution for Windows.
An option which causes timestamps to be read from the input log lines (supposed to be in Common Log Format). Allows to run some old logfiles through managelogs using time-related features.
the logmanager library is already prepared for such a feature as functions receive the time from the calling program. Today, managelogs always sends a null value, meaning that the library gets the time from the system clock. So, we just need the code to extract the time from each log line.
An option to display in readable form some information about a log manager current state (mostly extracted from the status file).
Several output formats should be available, as detailed, XML, or compact (to be read by an external script).
Problem : both processes cannot be synchronized (could run on different hosts).
- An optional command to be launched when the program aborts on a fatal error. This command would receive the information on the error, and could connect with a monitoring system, send a trap... (TBD: Pros and cons of running this command in foreground or background).
- Another external command to be executed when managelogs gets a 'file system full' error (as it now survives it). This command should be sent only once per distinctive event.
Actually, both can be gathered into an external 'alert' command, triggered only when an unexpected event occurs. This command would receive a reason, a (numeric and string) level, an action code (abort or ignore), a message... and could make the link with an external alert system.
Note: If the program exits just after having launched its alert command, the child process must not be killed. So, it may be interesting to run the child process in foreground (waitpid) when the action code is 'abort'.
Unlike rotatelogs and cronolog, managelogs does not support strftime patterns in filename specs.
I'd like to integrate cronolog's time-related features, but combining this with the existing features is not trivial (creating directories is one thing, but deciding when to remove them is another !).
I also have several issues to investigate on the way to manipulate the current time and how to compute accurate delays from the current local time, especially with DST.
managelogs currently uses a basic memory-based mechanism to manage signals and avoid reentrance in log managers.
This mechanism should be improved to use system mutexes. And the logmanager library should become fully reentrant and thread-safe. If it can be done in a portable (M$-compatible) way, it is still better.
I don't know yet how to do it, but it can be interesting for heavily loaded or ISP-like environments (with a lot of virtual hosts).
To be implemented as another front-end to the logmanager library.