On Wed, Nov 26, 2008 at 08:40:55AM -0700, Brad Nicholes wrote: > >>> On 11/26/2008 at 3:45 AM, in message > <[EMAIL PROTECTED]>, Martin Knoblauch > <[EMAIL PROTECTED]> wrote: > > > >> From: Brad Nicholes <[EMAIL PROTECTED]> > >> > >> >>> On 11/25/2008 at 10:14 AM, in message > >> <[EMAIL PROTECTED]>, > >> Ofer Inbar wrote: > >> > Brad Nicholes wrote: > >> >> It needs a temp directory to get around some issues with libconfuse. > >> >> Libconfuse doesn't actually support wildcard paths or files. A > >> >> libconfuse include statement must have a full path to the file that > >> >> it is going include. So gmond makes up for this problem by creating > >> >> a temp file, resolving all of the file paths and names and then > >> >> writing them as separate includes in a temp file. Then it tells > >> >> libconfuse to include the temp file directly. Without the ability > >> >> to resolve the wildcard paths and write them to a temp file, the > >> >> wildcarding feature of gmond wouldn't work. To solve the problem > >> >> that you are describing, we would have to actually add wildcard > >> >> capability to libconfuse. > >> > > >> > Might this be cleaner workaround that would work for gmond as well? > >> > > >> > - override libconfuse's include function as you're already doing > >> > - resolve file paths and names as you're already doing > >> > - instead of writing that to a temp file and telling libconfuse to > >> > include that file, just tell libconfuse to include each individual > >> > file (the same filenames you're now writing to the temp file) > >> > > >> > >> No, libconfuse doesn't work that way. The include handler can only > > manipulate > >> the file path that it is handed. So the result of the handler has to be a > >> single absolute file path. There isn't any way to take a single file path > > as > >> input into the handler and return multiple file paths back to libconfuse. > > The > >> only way to do it was to write all of the individual file paths to a file > > and > >> then hand libconfuse back a single file path to the new include file. > >> > > > > the question is: can't the handler be rewritten to the conversions "in > > memory", without needing to write a temp file? This would make the process > > more robust. You never know when a disk is full, or goes RO. > > No, I tried doing that already but was unsuccessful. Libconfuse > is limited in what you can do in this area.
the API libconfuse exports is limited to handling single file includes (as documented) so it shouldn't be a surprise that it wouldn't handle a wildcard include with it. > The problem is that when libconfuse wants to read in the include file, > it is in the middle of the lexer and needs to continue. A handler can't > just read the file and hand it back to libconfuse through some other > cfg_* call. an alternative will be to preprocess the configuration file and feed it into a buffer in memory, resolving all includes, and then call libconfuse to parse and process the buffer instead. this would have also the nice side effect of preventing gmond/gmetric to segfault if there is no gmond.conf (hence using the embedded configuration) and there are files in the include path (as documented in the release notes since 3.1 for requiring gmond.conf if using modpython). > This may be a design flaw in libconfuse but it is the way it works now > and we have to live with it. since AFAIK no libconfuse developer was ever notified of their flaw it might be as well that our implementation is abusing their API. will check with them and update back with any suggestions. Carlo ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general
