Feature Proposals » TWiki::Func::getDebugFilePath()

Motivation

Programs launched from TWiki may write to log files.

Description and Documentation

PloticusPlugin launches the "pl" command, which dumps core under certain situations, which I need to investigate. Currently, only the process IDs and the time stamps of those core files are known, which is not enough for a TWiki installation having 1M+ topics.

So I'd like to record "pl" command launches with their process IDs and topic names. The record should be on TWiki's debug file. However, the "pl" command is not launched directly from TWiki. Rather, TWiki launches a wrapper of "pl", namely ploticus.pl and the wrapper launches "pl". So to record the process ID of a "pl" execution, the wrapper needs to write to the debug file. For this, there needs to be a way to get the path of debug file and the plugin hands the path name to the wrapper. The wrapper will do:

open(TWIKIDEBUG, ">>$twikiDebug");
print TWIKIDEBUG "$execCmd [$pid] launched for $webTopic\n";
close(TWIKIDEBUG);

Examples

Impact

Implementation

TWiki::Func::debugFilePathName() will be introduced. Those functions return the path of the debug file. If the current value of the debug file path is relative, TWiki will try to make it absolute.

-- Contributors: Hideyo Imazu - 2015-12-11

Discussion

Maybe I miss something, why not just use writeWarning(), writeDebug(), writeLog()? I am concerned if we give direct access to the files we don't have control over it, such as file locking on write (something we should do.)

-- Peter Thoeny - 2015-12-11

tools/ploticus.pl, which is launched from PloticusPlugin and launches the "pl" command, knows the process ID of "pl". I'd like to have ploticus.pl write to TWiki's debug file. Being a thin rapper, ploticus.pl is not supposed to instantiate the TWiki class. It's possilbe for ploticus.pl to output the process ID of "pl" to STDOUT, which is read by PloticusPlugin anyway, and enhance PloticusPlugin to record the process ID. But this is unnecessarily complex. Handing the debug file path and the topic name to ploticus.pl and have ploticus.pl record those is simpler. Alternatively, ploticus.pl can use its own debug file. But I prefer consolidating debug information on TWiki's debug file.

-- Hideyo Imazu - 2015-12-12

This is a special case as you pointed out. I recommend to enhance the wrapper script to capture STDIN and possibly STDOUT. Very easy of you just want to capture STDIN. Also relatively easily possible with an extra module to capture both. See BackupRestorePlugin for details.

Alternatively, the plugin could read the $TWiki::cfg{DebugFileName} to get the debug filename. This would be a slight undocumented way, but is not likely to break in the future. It would just circumvent file locking once we implement that.

Let's discuss this in the release meeting.

-- Peter Thoeny - 2015-12-17

If you worry about control, I'm fine only with TWiki::Func::debugFilePath().

Here's why I'd like this approach.

1. The amount of code to be written is the smallest if I hand the debug file path and the topic name to the ploticus.pl wrapper.
2. It works most reliably.

It's possible to achieve my goal by having ploticus.pl return the process ID of pl to STDOUT. But then, I need to define and implement a protocol between the PloticusPlugin body and ploticus.pl. At this point, I'm interested only in the process ID of pl. But I may want to record more. In that case, the protocol needs to be enhanced.

-- Hideyo Imazu - 2016-01-07

Accepted by KampalaReleaseMeeting2016x01x07

-- Peter Thoeny - 2016-01-08

Now I believe the function must be named TWiki::Func::getDebugFilePath() rather than TWiki::Func::getDebugFilePathName() because the return value is a path to which debug message is written. It checks if the path is absolute before returning. If it's not, it's made absolute.

-- Hideyo Imazu - 2016-02-02

Sounds good.

-- Peter Thoeny - 2016-02-02