LILiK
/
openwrt-packages-dist
5
0
Fork 0
Code Issues 0 Pull Requests 0 Projects 0 Releases 0 Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
8696 Commits
1 Branch
46 MiB
Tree: 60c5902bfd
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '60c5902bfd'
${ noResults }
openwrt-packages-dist/utils/collectd/patches/300-delay-first-read-cycle....

11 lines
345 B
Raw Normal View History

collectd: Delay first data read cycle by 1s Some collectd plugins launch third-party plugins that have variation in initialisation time (like libpcap). Recently (since kernel bump to 4.1) the DNS plugin has been causing collectd to crash semi-randomly at startup on MIPS based WNDR3700. Debugging led to realisation that the DNS plugin seems to require at least 0.1s time to start, before the first data reading attempt starts. By default, the first data read cycle starts immediately, while apaprently some of the plugins may still be asyncronously initialising. To make things safe, this patch adds 1 second delay before the first data read cycle. Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
9 years ago
​
collectd: update to 5.7.1 Update collectd to version 5.7.1 * replace 003-remove-werror.patch with configure option * remove 200-fix-git-describe-error.patch that is now unnecessary * reformat other patches due to whitespace changes * add new plugins to the list as disabled * correct download & homepage links * add myself as the second maintainer Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
8 years ago
​
​
collectd: Delay first data read cycle by 1s Some collectd plugins launch third-party plugins that have variation in initialisation time (like libpcap). Recently (since kernel bump to 4.1) the DNS plugin has been causing collectd to crash semi-randomly at startup on MIPS based WNDR3700. Debugging led to realisation that the DNS plugin seems to require at least 0.1s time to start, before the first data reading attempt starts. By default, the first data read cycle starts immediately, while apaprently some of the plugins may still be asyncronously initialising. To make things safe, this patch adds 1 second delay before the first data read cycle. Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
9 years ago
collectd: update to 5.7.1 Update collectd to version 5.7.1 * replace 003-remove-werror.patch with configure option * remove 200-fix-git-describe-error.patch that is now unnecessary * reformat other patches due to whitespace changes * add new plugins to the list as disabled * correct download & homepage links * add myself as the second maintainer Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
8 years ago
​
​
collectd: Delay first data read cycle by 1s Some collectd plugins launch third-party plugins that have variation in initialisation time (like libpcap). Recently (since kernel bump to 4.1) the DNS plugin has been causing collectd to crash semi-randomly at startup on MIPS based WNDR3700. Debugging led to realisation that the DNS plugin seems to require at least 0.1s time to start, before the first data reading attempt starts. By default, the first data read cycle starts immediately, while apaprently some of the plugins may still be asyncronously initialising. To make things safe, this patch adds 1 second delay before the first data read cycle. Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
9 years ago
collectd: update to 5.7.1 Update collectd to version 5.7.1 * replace 003-remove-werror.patch with configure option * remove 200-fix-git-describe-error.patch that is now unnecessary * reformat other patches due to whitespace changes * add new plugins to the list as disabled * correct download & homepage links * add myself as the second maintainer Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
8 years ago
 
  1. --- a/src/daemon/plugin.c

  2. +++ b/src/daemon/plugin.c

  3. @@ -1108,7 +1108,7 @@ static int plugin_insert_read(read_func_

  4.    int status;
  5.    llentry_t *le;
  6.  
  7. -  rf->rf_next_read = cdtime();

  8. +  rf->rf_next_read = cdtime() + (cdtime_t) 1073741824; //delay first read 1s

  9.    rf->rf_effective_interval = rf->rf_interval;
  10.  
  11.    pthread_mutex_lock(&read_lock);