----- 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. Cheers Martin ------------------------------------------------------------------------- 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
