>>> On 11/25/2008 at 1:08 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Mon, Nov 24, 2008 at 04:55:42PM -0700, Brad Nicholes wrote: >> >>> On 11/24/2008 at 3:47 PM, in message > <[EMAIL PROTECTED]>, >> Ofer Inbar <[EMAIL PROTECTED]> wrote: >> >> > I tried feeding one of my custom metrics by hand: >> >> > [root ~]$ gmetric --name net_smtp_fin_wait2_out --value 0 --type uint8 >> >> > --units >> >> > 'connections' >> >> > /etc/ganglia/gmond.conf:94: failed to determine the temp dir >> >> > Parse error for '/etc/ganglia/gmond.conf' >> >> It needs a temp directory to get around some issues with libconfuse. > > gmond does; gmetric doesn't need anything more than to know which > channel to use (hence nothing in the includes) and it is getting > blocked by this restriction because of its use of libganglia to > read gmond's configuration through libgmond. >
Anything can be included from the main gmond.conf file. There is nothing that says that a user can't put socket and channel information in a separate file and then include it from gmond.conf. So making the assumption that gmetric doesn't need includes is false. If this is a real problem for users, then gmetric should be using a different .conf file that only contains the socket information rather than using the same gmond.conf file that contains all of the metric information and includes. Also, both gmond and gmetric both use the same code path for resolving the configuration, so if the code is changed to ignore configuration failures for gmetric, it is also changed to ignore configuration failures for gmond. This isn't a good thing. This problem doesn't require a code change to be resolved. Simple documentation for gmetric would solve the problem. >> To solve the problem that you are describing, we would have to actually >> add wildcard capability to libconfuse. > > libconfuse is instructed to use our implementation for includes and that > uses a temporary file, so this is fixable in our code. > > a fix to the problem reported by Ofer only needs our handler modified > so that failures to create temporary files to handle includes are not > treated as fatal as Committed revision 1922 > No, libconfuse doesn't work that way. The include handler only allows gmond to manipulate the input into a form that libconfuse can handle. In this case the input is a single wildcard file path that needs to be translated into a single absolute file path. libconfuse can not handle wild card paths. Also libconfuse only knows how to get its input from a file. The gmond include handler is only manipulating the wildcard path into an absolute path to a file that contains all of the resolved paths. At that point libconfuse is able to read and process all of the included files through absolute paths. The include handler has nothing to do with just translating a single wildcard path into multiple absolute paths and then handing them back to libconfuse in memory. These include paths have to be written to a file first and then libconfuse has to be told where the new file is. This problem can't be fixed by just changing the include handler, otherwise I would have done it that way. Revision 1922 currently breaks the configuration file handling and needs to be reverted. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general
