Collectd 4.10 #1

ghost · 2012-01-26T11:31:21Z

Even better than memory leaks: Memory corruption.

Change-Id: I9899b98517fe0c239bffcf7a75681560029aa2ba

Cl/perl openvz

Infiniband

ceph: a couple of small details

write_riemann: avoid deadlocks, rate limit log messages.

Update from original

Fixes the following warning on Solaris: |c_avl_tree_t *c_avl_create (int (*compare) (const void *, const void *)); | ^ line 54, utils_avltree.h | included in line 34, utils_vl_lookup.c | | obj->by_type_tree = c_avl_create ((void *) strcmp); | ^ line 567, utils_vl_lookup.c E_ARG_INCOMPATIBLE_WITH_ARG_L, argument #1 is incompatible with prototype: prototype: pointer to function(pointer to const void, pointer to const void) returning int : "src/daemon/utils_avltree.h", line 54 argument : pointer to void I'll look into writing a generic function to compare avl keys so we don't need to do all the casting.

When using a configuration like this: ``` LoadPlugin curl_json <Plugin curl_json > <URL "http://api.facebook.com/method/fql.query?format=json&query=select+fan_count+from+page+where+page_id=280922605253831" > Instance "facebook" <Key "*/fan_count"> Type "gauge" </Key> </URL> </Plugin> ``` collectd segfaults in `src/curl_json.c` in `cj_cb_number`. >>> bt #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 collectd#1 0x0000000000414da2 in search (t=0x2304a80, t=0x2304a80, key=0x1) at ../../../src/daemon/utils_avltree.c:119 collectd#2 c_avl_get (t=0x2304a80, key=key@entry=0x1, value=value@entry=0x7f01184f2ab8) at ../../../src/daemon/utils_avltree.c:599 collectd#3 0x000000000040cbd1 in plugin_get_ds (name=0x1 <error: Cannot access memory at address 0x1>) at ../../../src/daemon/plugin.c:2559 collectd#4 0x00007f011f93b7ef in cj_get_type (key=0x23324f0) at ../../src/curl_json.c:147 collectd#5 cj_cb_number (ctx=0x231f2f0, number=<optimized out>, number_len=2) at ../../src/curl_json.c:244 collectd#6 0x00007f011f4b7874 in yajl_do_parse (hand=0x7f01100008e0, jsonText=jsonText@entry=0x234f990 "{\"error_code\":12,\"error_msg\":\"REST API is deprecated for versions v2.1 and higher (12)\",\"request_args\":[{\"key\":\"method\",\"value\":\"fql.query\"},{\"key\":\"format\",\"value\":\"json\"},{\"key\":\"query\",\"value\":\"sel"..., jsonTextLen=jsonTextLen@entry=257) at /tmp/buildd/yajl-2.1.0/src/yajl_parser.c:307 In fact, `db->state[db->depth].key` is not a key (it's a tree). This is correctly detected at the beginning, but despite that, there is a call to `cj_cb_inc_array_index()` (without effect, not in an array) and `key` is set again to `db->state[db->depth].key` which is still not a key. In a previous call to `cj_cb_map_key()` where the corresponding value is set, `(c_avl_get (tree, CJ_ANY, (void *) &value) == 0)` is true but `(CJ_IS_KEY((cj_key_t*)value))` is false. Therefore, this confirms this a tree which is stored in this node, not a key. This is a tentative fix to ignore the value if we are expecting a map, but didn't get one and aren't in an inhomogeneous array.

…ugin_support Enable support for the notify_plugin package which depneds on libesmtp-dev. Testing without an explicit binary dependency. This may require additional modification.

…otify_plugin_support" This reverts commit ea740cb, reversing changes made to 1979330.

fix typo in collectd.conf.pod

connectivity plugin initial commit

Pull in upstream master

Sync with upstream

ChangeLog: collectd: Use one write thread per write plugin The previous write thread design u 8000 sed a single queue with a single read thread from which one of the write threads would de-queue an element and would then sequentially call each registered write callback. This meant that all write plugins would have to cooperate in order to not drop values. If for example all write threads are stalled by the same write plugin's callback function not returning, the queue will start to fill up until elements start to be dropped, even though there are other plugins that could still make progress. In addition to that, all write callbacks have to be designed to be reentrant right now, which increases complexity. This new design uses a single linked-list write queue with one read head per output plugin. Each output plugin is serviced in a dedicated write thread. Elements are freed based on a reference count, which is shown in the ASCII-Art below: +- Thread collectd#1 Head +- Thread collectd#2 Head +- Tail v v v +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | 0|->| 1|->| 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ ^ +- to be free()d The changes introduced by this commit have some side-effects: - The WriteThreads config option no longer exists, as a strict 1:1 ratio of write plugins and write threads is used. - The data flow has changed. The previous data flow was: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() enqueue_metric_family() write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() | ^- plugin_write_dequeue() <-+ plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(fc_process_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) plugin callback() The data flow now is: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(post_cache_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() <-+ plugin callback() One result of this change is, that the behaviour of plugin_write has changed from running the plugin callback immediately and in the same thread, to always enqueueing the value and de-queing in the dedicated thread. - The behaviour of the WriteQueueLimitHigh and WriteQueueLimitLow options has changed. The Queue will be be capped to a length of LimitHigh by dropping random queue elements between the queue end and LimitLow. Setting LimitLow to a reasonably large value ensures that fast write plugins do not loose values, even in the vicinity of a slow plugin. The diagram below shows the random element selected for removal (###) in Step 1 and the queue with the element removed in Step 2. Step 1: +- Thread collectd#1 Head | +- Thread collectd#2 Head +- Tail v | | v v +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | 1|->| 1|-># 1#->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Step 2: | +- Thread collectd#1 Head +- Thread collectd#2 Head +- Tail | v | v v | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>

ChangeLog: collectd: Use one write thread per write plugin The previous write thread design used a single queue with a single read head from which one of the write threads would de-queue an element and would then sequentially call each registered write callback. This meant that all write plugins would have to cooperate in order to not drop values. If for example all write threads are stalled by the same write plugin's callback function not returning, the queue will start to fill up until elements start to be dropped, even though there are other plugins that could still make progress. In addition to that, all write callbacks have to be designed to be reentrant right now, which increases complexity. This new design uses a single linked-list write queue with one read head per output plugin. Each output plugin is serviced in a dedicated write thread. Elements are freed based on a reference count, which is shown in the ASCII-Art below: +- Thread collectd#1 Head +- Thread collectd#2 Head +- Tail v v v +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | 0|->| 1|->| 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ ^ +- to be free()d The changes introduced by this commit have some side-effects: - The WriteThreads config option no longer exists, as a strict 1:1 ratio of write plugins and write threads is used. - The data flow has changed. The previous data flow was: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() enqueue_metric_family() write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() | ^- plugin_write_dequeue() <-+ plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(fc_process_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) plugin callback() The data flow now is: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(post_cache_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() <-+ plugin callback() One result of this change is, that the behaviour of plugin_write has changed from running the plugin callback immediately and in the same thread, to always enqueueing the value and de-queing in the dedicated thread. - The behaviour of the WriteQueueLimitHigh and WriteQueueLimitLow options has changed. The Queue will be be capped to a length of LimitHigh by dropping random queue elements between the queue end and LimitLow. Setting LimitLow to a reasonably large value ensures that fast write plugins do not loose values, even in the vicinity of a slow plugin. The diagram below shows the random element selected for removal (###) in Step 1 and the queue with the element removed in Step 2. Step 1: +- Thread collectd#1 Head | +- Thread collectd#2 Head +- Tail v | | v v +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | 1|->| 1|-># 1#->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Step 2: | +- Thread collectd#1 Head +- Thread collectd#2 Head +- Tail | v | v v | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>

ChangeLog: collectd: Use one write thread per write plugin The previous write thread design used a single queue with a single read head from which one of the write threads would de-queue an element and would then sequentially call each registered write callback. This meant that all write plugins would have to cooperate in order to not drop values. If for example all write threads are stalled by the same write plugin's callback function not returning, the queue will start to fill up until elements start to be dropped, even though there are other plugins that could still make progress. In addition to that, all write callbacks have to be designed to be reentra 8000 nt right now, which increases complexity. This new design uses a single linked-list write queue with one read head per output plugin. Each output plugin is serviced in a dedicated write thread. Elements are freed based on a reference count, which is shown in the ASCII-Art below: +- Thread collectd#1 Head +- Thread collectd#2 Head +- Tail v v v +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | 0|->| 1|->| 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ ^ +- to be free()d The changes introduced by this commit have some side-effects: - The WriteThreads config option no longer exists, as a strict 1:1 ratio of write plugins and write threads is used. - The data flow has changed. The previous data flow was: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() enqueue_metric_family() write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() | ^- plugin_write_dequeue() <-+ plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(fc_process_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) plugin callback() The data flow now is: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(post_cache_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() <-+ plugin callback() One result of this change is, that the behaviour of plugin_write has changed from running the plugin callback immediately and in the same thread, to always enqueueing the value and de-queing in the dedicated thread. - The behaviour of the WriteQueueLimitHigh and WriteQueueLimitLow options has changed. The Queue will be be capped to a length of LimitHigh by dropping random queue elements between the queue end and LimitLow. Setting LimitLow to a reasonably large value ensures that fast write plugins do not loose values, even in the vicinity of a slow plugin. The diagram below shows the random element selected for removal (###) in Step 1 and the queue with the element removed in Step 2. Step 1: +- Thread collectd#1 Head | +- Thread collectd#2 Head +- Tail v | | v v +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | 1|->| 1|-># 1#->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Step 2: | +- Thread collectd#1 Head +- Thread collectd#2 Head +- Tail | v | v v | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>

ChangeLog: collectd: Use one write thread per write plugin The previous write thread design used a single queue with a single read head from which one of the write threads would de-queue an element and would then sequentially call each registered write callback. This meant that all write plugins would have to cooperate in order to not drop values. If for example all write threads are stalled by the same write plugin's callback function not returning, the queue will start to fill up until elements start to be dropped, even though there are other plugins that could still make progress. In addition to that, all write callbacks have to be designed to be reentrant right now, which increases complexity. This new design uses a single linked-list write queue with one read head per output plugin. Each output plugin is serviced in a dedicated write thread. Elements are freed based on a reference count, which is shown in the ASCII-Art below: +- Thread #1 Head +- Thread #2 Head +- Tail v v v +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | 0|->| 1|->| 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ ^ +- to be free()d The changes introduced by this commit have some side-effects: - The WriteThreads config option no longer exists, as a strict 1:1 ratio of write plugins and write threads is used. - The data flow has changed. The previous data flow was: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() enqueue_metric_family() write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() | ^- plugin_write_dequeue() <-+ plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(fc_process_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) plugin callback() The data flow now is: (From one of the ReadThreads) plugin_dispatch_{values,multivalue}() plugin_dispatch_metric_family() plugin_dispatch_metric_internal() ^- fc_process_chain(pre_cache_chain) fc_process_chain(post_cache_chain) fc_bit_write_invoke() plugin_write(NULL) / plugin_write(plugin_name) write_queue_enqueue() -----{Queue}----+ | (In one of the WriteThreads threads) | plugin_write_thread() <-+ plugin callback() One result of this change is, that the behaviour of plugin_write has changed from running the plugin callback immediately and in the same thread, to always enqueueing the value and de-queing in the dedicated thread. - The behaviour of the WriteQueueLimitHigh and WriteQueueLimitLow options has changed. The Queue will be be capped to a length of LimitHigh by dropping random queue elements between the queue end and LimitLow. Setting LimitLow to a reasonably large value ensures that fast write plugins do not loose values, even in the vicinity of a slow plugin. The diagram below shows the random element selected for removal (###) in Step 1 and the queue with the element removed in Step 2. Step 1: +- Thread #1 Head | +- Thread #2 Head +- Tail v | | v v +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | 1|->| 1|-># 1#->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X +--+| +--+ #### +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Step 2: | +- Thread #1 Head +- Thread #2 Head +- Tail | v | v v | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | 1|->| 1|->| 1|->| 2|->| 2|->| 2|->| 2|->| 2|->X | +--+ +--+ +--+| +--+ +--+ +--+ +--+ +--+ | | | LimitHigh | LimitLow Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>

oracle plugin: Fix use of the OCIErrorGet() function.

a68d919

Change-Id: I9899b98517fe0c239bffcf7a75681560029aa2ba

ghost closed this Jan 26, 2012

cstorey mentioned this pull request Aug 14, 2013

exec plugin sporadically hanging in getpwnam_r #229

Closed

robb-reporo mentioned this pull request Mar 6, 2014

ipmi in combination with java plugins crashes #114

Closed

pyr pushed a commit that referenced this pull request Jul 29, 2014

Merge pull request #1 from jyotty/cl/perl-openvz

41297fe

Cl/perl openvz

brandentimm mentioned this pull request Aug 25, 2014

collectd.conf man page is contradictory #715

Closed

gilesw mentioned this pull request Aug 29, 2014

apache plugin crashes on Ubuntu Lucid when 2 https instances are used #720

Closed

toni-moreno mentioned this pull request Dec 11, 2014

apache plugin HTTPS - multithread crash on RHES 5.7 #858

Open

karcaw pushed a commit to karcaw/collectd that referenced this pull request Dec 15, 2014

Merge pull request collectd#1 from Maigard/infiniband

af8b511

Infiniband

mfournier pushed a commit that referenced this pull request Mar 3, 2015

Merge pull request #1 from mfournier/ceph

e34ed7a

ceph: a couple of small details

srini5884 mentioned this pull request May 11, 2015

Collected restart issues & Invalid line error in listeners log #1026

Closed

marekbecka mentioned this pull request Jun 10, 2015

fix memory initialization in tail plugin #1073

Closed

davidc-donorschoose mentioned this pull request Oct 1, 2015

Segfault with python plugin - collectd: terminated by signal 11 #1285

Closed

mdubbyap mentioned this pull request Jan 12, 2016

collectd terminated with SIGABRT #1505

Closed

mdubbyap mentioned this pull request Apr 1, 2016

SIGSEGV in python module on 5.5.1 #1645

Closed

wcarrell mentioned this pull request Apr 4, 2016

Unable to build my own plugin #1651

Closed

BG1321 mentioned this pull request Apr 5, 2016

How to retrieve a String data as a return value? #1652

Closed

pyr pushed a commit that referenced this pull request Apr 18, 2016

Merge pull request #1 from pyr/f/riemann/rcc

11df5f5

write_riemann: avoid deadlocks, rate limit log messages.

Pratik-Shah mentioned this pull request May 9, 2016

Collectd statsd plugin deadlock #1703

Closed

rubenk pushed a commit that referenced this pull request Jun 4, 2016

Merge pull request #1 from collectd/master

5d01cda

Update from original

ghost mentioned this pull request Nov 8, 2016

Deadlock at startup with Exec #2032

Closed

pmauduit pushed a commit to pmauduit/collectd that referenced this pull request Jan 30, 2017

Revert "Merge pull request collectd#1 from krux/akulick_OPS-861-add_n…

2795457

…otify_plugin_support" This reverts commit ea740cb, reversing changes made to 1979330.

rubenk pushed a commit that referenced this pull request May 30, 2017

Merge pull request #1 from archii/archii-fix-docs-typo-1

a05589a

fix typo in collectd.conf.pod

StLuke mentioned this pull request Jul 19, 2017

Stopping collectd does not stop collectd write_http plugin logging in syslog #2371

Open

thewiwi mentioned this pull request Aug 27, 2017

possible issue with libvirt/kvm on RHEL 7.4 #2410

Closed

jiriproX mentioned this pull request Oct 25, 2017

collectd built from commit 66fd3303 crash with SIGSEGV #2506

Closed

yellowpattern mentioned this pull request Dec 21, 2017

OpenIPMI threads deadlock #2632

Closed

roderick-unicom mentioned this pull request Aug 23, 2018

curl_json not working with Couchdb 2.2.0 #2906

Open

f1-outsourcing mentioned this pull request Jan 7, 2019

ceph plugin complaining a lot when other osd's are down #3035

Open

waldner mentioned this pull request Jun 11, 2019

write_graphite plugin calculates wrong rates for context switches #3171

Closed

tainguyennc mentioned this pull request Jun 20, 2019

collectd crashes with assertion "ce->values_num == ds->ds_num" #3186

Closed

smaxx1337 mentioned this pull request Aug 16, 2019

collectd[24921]: csv plugin: DS type does not match value list type [sw-collectd] #3256

Closed

mrunge pushed a commit that referenced this pull request Sep 18, 2019

Merge pull request #1 from atyronesmith/connectivity

20e8c46

connectivity plugin initial commit

KingRabbid mentioned this pull request Oct 12, 2019

Aggregation works with old/previous snapshot values? #3301

Open

WalterFaber mentioned this pull request Oct 28, 2019

Ping Plugin with DNS - Crash "ping_iterator_get_info (liboping.so.0)" #3324

Closed

jagauthier mentioned this pull request Jan 11, 2020

virt plugin: Array index out of bounds: tag_index #3364

Closed

KingRabbid mentioned this pull request Jun 5, 2020

FAILURE...has not been updated for xxxxx seconds #3475

Open

mrunge pushed a commit that referenced this pull request Jun 6, 2020

Merge pull request #1 from collectd/master

765cc77

Pull in upstream master

srijnair-cisco mentioned this pull request Jun 25, 2020

Reader core dump with *** Error in `/usr/sbin/collectd': corrupted size vs. prev_size: 0x00007f19b0038780 *** #3488

Open

mrunge pushed a commit that referenced this pull request Jul 9, 2020

Merge pull request #1 from collectd/master

f515c93

Sync with upstream

KamranAsifSiddiqui mentioned this pull request Aug 27, 2020

Failed to start Collectd statistics daemon. #3546

Open

MiXFiX mentioned this pull request Sep 13, 2021

plugin_load: Could not find plugin "nut" in /usr/lib/collectd #3915

Closed

semirke mentioned this pull request Oct 8, 2021

postgresql: c_psql_write: Failed to determine rate #3929

Open

vdefendme mentioned this pull request Mar 28, 2022

SNMP Plugin making wrong data ( data in Millions ) #3989

Open

MarkCRay mentioned this pull request May 10, 2022

collectd coredumps with SIGSEGV when using NVMe devices on kernel that support Native NVMe multipathing. #4004

Open

lomoonmoonbird mentioned this pull request Jul 25, 2022

Failed to get vcpu stats #4029

Closed

jchari mentioned this pull request Aug 21, 2024

Open IPMI library crashing with Unable to start SEL time set due to error #4325

Open

This pull request was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Collectd 4.10 #1

Collectd 4.10 #1

Uh oh!

Uh oh!

Uh oh!

Collectd 4.10 #1

Collectd 4.10 #1

Uh oh!

Conversation

Uh oh!

Uh oh!