[collectd] Strange behavior of UnixSock plugin

[Florian Forster]

Hi Jarle,

On Sat, Dec 13, 2008 at 12:05:32PM +0100, Jarle Bjørgeengen wrote:
> This was caused by the (custom) type missing from types.db. The reason
> it was missing was of course because the yum/rpm upgrade process
> overwrote types.db. Is there a types.db.local mechanism, to avoid this
> in the future. I guess just changing the path to somewhere else  in
> collectd.conf also would do the trick, but then new upstream types
> would have to be added manually .. 

yes, you can load multiple types.db files, precisely for this reason.

I've updated the types.db(5) manual page to be more specific:
-- 8< --
diff --git a/src/types.db.pod b/src/types.db.pod
index f0a49f6..ef1550c 100644
--- a/src/types.db.pod
+++ b/src/types.db.pod
@@ -29,9 +29,19 @@ happen. See L<rrdcreate(1)> for more details.
 =head1 FILES
 
 The location of the types.db file is defined by the B<TypesDB> configuration
-option (see L<collectd.conf(5)>). If you want to specify custom data-sets, you
-should do so by using a custom file specified as an additional argument to the
-B<TypesDB> option.
+option (see L<collectd.conf(5)>).
+
+=head1 CUSTOM TYPES
+
+If you want to specify custom types, you should do so by specifying a custom
+file in addition to the default one (see L<FILES>) above. You can do that by
+having multiple B<TypesDB> statements in your configuration file of by
+specifying more than one file in one line.
+
+For example:
+
+ TypesDB "/opt/collectd/share/collectd/types.db"
+ TypesDB "/opt/collectd/etc/types.db.custom"
 
 =head1 SEE ALSO
 
-- >8 --

If you have further suggestions on how this could be explained better,
please let me know :)

> > ---------------------------------
> >  $sock->putval (%identifier, time=> $time , \
> > values => [@vdisk_rates, at vdisk_lats])
> > ---------------------------------
> > 
> > and does not return, or output anything to the logfile. 
> > 
> 
> Is this intended behavior , or would it be sensible to return an error
> if trying to PUT data with a non existant type ? It would at least
> help detecting the problem faster :-) 

You're right, an error message would be appropriate here.. I'll take a
look.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20081220/304f6b17/attachment.pgp