>>> On 11/26/2008 at 3:45 AM, in message <[EMAIL PROTECTED]>, Martin Knoblauch <[EMAIL PROTECTED]> wrote: > ----- Original Message ---- > >> From: Brad Nicholes <[EMAIL PROTECTED]> >> To: Ofer Inbar <[EMAIL PROTECTED]> >> Cc: ganglia-general@lists.sourceforge.net >> Sent: Tuesday, November 25, 2008 8:43:08 PM >> Subject: Re: [Ganglia-general] gmetric fails when disk is unwriteable? >> >> >>> 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 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. This may be a design flaw in libconfuse but it is the way it works now and we have to live with it. Brad ------------------------------------------------------------------------- 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 Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
