Filebeat panic at startup #6145
Comments
- Add virtualenv for running Ansible in a reproducible manner. - Change regex for matching Metricbeat output from the system-cpu metricset The order of the JSON keys in the `metricset` object is different in the output than before (I haven't determined why.) - Update the win_copy dest argument to include the file name and not just the destination directory. - Refactor the Makefile and update the README. - Temporarily disable Filebeat testing on Windows while elastic/beats#6145 is resolved.
- Add virtualenv for running Ansible in a reproducible manner. - Change regex for matching Metricbeat output from the system-cpu metricset The order of the JSON keys in the `metricset` object is different in the output than before (I haven't determined why.) - Update the win_copy dest argument to include the file name and not just the destination directory. - Refactor the Makefile and update the README. - Temporarily disable Filebeat testing on Windows while elastic/beats#6145 is resolved.
andrewkroh
changed the title
|
This is also happening on ubuntu-precise-32 with config: Log:
root@vagrant-ubuntu-precise-32:~# filebeat -e -d "*"
2018-01-23T05:00:58.498Z INFO instance/beat.go:468 Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2018-01-23T05:00:58.499Z DEBUG [beat] instance/beat.go:495 Beat metadata path: /var/lib/filebeat/meta.json
2018-01-23T05:00:58.501Z INFO instance/beat.go:475 Beat UUID: 1d097697-d99a-4352-b82a-2c3b3795782a
2018-01-23T05:00:58.502Z INFO instance/beat.go:213 Setup Beat: filebeat; Version: 6.2.0
2018-01-23T05:00:58.503Z DEBUG [beat] instance/beat.go:230 Initializing output plugins
2018-01-23T05:00:58.503Z DEBUG [processors] processors/processor.go:49 Processors:
2018-01-23T05:00:58.503Z INFO fileout/file.go:76 Initialized file output. path=/root/output/filebeat max_size_bytes=10485760 max_backups=7 permissions=-rw-------
2018-01-23T05:00:58.504Z INFO pipeline/module.go:76 Beat name: vagrant-ubuntu-precise-32
2018-01-23T05:00:58.504Z INFO instance/beat.go:301 filebeat start running.
2018-01-23T05:00:58.504Z DEBUG [registrar] registrar/registrar.go:88 Registry file set to: /var/lib/filebeat/registry
2018-01-23T05:00:58.505Z INFO registrar/registrar.go:108 Loading registrar data from /var/lib/filebeat/registry
2018-01-23T05:00:58.505Z INFO registrar/registrar.go:119 States Loaded from registrar: 0
2018-01-23T05:00:58.505Z WARN beater/filebeat.go:261 Filebeat is unable to load the Ingest Node pipelines for the configured modules because the Elasticsearch output is not configured/enabled. If you have already loaded the Ingest Node pipelines or are using Logstash pipelines, you can ignore this warning.
2018-01-23T05:00:58.505Z INFO crawler/crawler.go:48 Loading Prospectors: 1
2018-01-23T05:00:58.505Z DEBUG [processors] processors/processor.go:49 Processors:
2018-01-23T05:00:58.505Z DEBUG [prospector] log/config.go:178 recursive glob enabled
2018-01-23T05:00:58.504Z INFO [monitoring] log/log.go:95 Starting metrics logging every 30s
2018-01-23T05:00:58.506Z DEBUG [registrar] registrar/registrar.go:150 Starting Registrar
2018-01-23T05:00:58.506Z DEBUG [prospector] log/prospector.go:120 exclude_files: []. Number of stats: 0
2018-01-23T05:00:58.506Z DEBUG [prospector] log/prospector.go:141 Prospector with previous states loaded: 0
2018-01-23T05:00:58.506Z INFO log/prospector.go:111 Configured paths: [/var/log/test.log]
2018-01-23T05:00:58.506Z DEBUG [prospector] prospector/prospector.go:87 Starting prospector of type: log; ID: 14439312048545787300
2018-01-23T05:00:58.506Z INFO crawler/crawler.go:82 Loading and starting Prospectors completed. Enabled prospectors: 1
2018-01-23T05:00:58.506Z DEBUG [prospector] log/prospector.go:147 Start next scan
2018-01-23T05:00:58.506Z DEBUG [prospector] log/prospector.go:361 Check file for harvesting: /var/log/test.log
2018-01-23T05:00:58.506Z DEBUG [prospector] log/prospector.go:434 Start harvester for new file: /var/log/test.log
2018-01-23T05:00:58.506Z INFO prospector/prospector.go:138 Stopping Prospector: 14439312048545787300
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8662b0c]
goroutine 33 [running]: |
|
I think the issue is on this line here: beats/filebeat/prospector/log/prospector.go Line 594 in 28ea9e0 It seems for whatever reason @urso could you have a look if there can be any reason that the atomic value above does not exist? @andrewkroh Did you test on any other systems? |
- Add virtualenv for running Ansible in a reproducible manner. - Change regex for matching Metricbeat output from the system-cpu metricset The order of the JSON keys in the `metricset` object is different in the output than before (I haven't determined why.) - Update the win_copy dest argument to include the file name and not just the destination directory. - Refactor the Makefile and update the README. - Temporarily disable Filebeat testing on Windows while elastic/beats#6145 is resolved.
There was a bug impacting 32-bit platforms where an atomic.Uint64 was not aligned to a 64 bit boundary, causing the log prospector to panic on startup. Instead of reordering the field to the start of the struct to guarantee alignment, which is brittle, this patch just changes the harvester limit to be a 32-bit unsigned integer. Closes elastic#6145
There was a bug impacting 32-bit platforms where an atomic.Uint64 was not aligned to a 64 bit boundary, causing the log prospector to panic on startup. Instead of reordering the field to the start of the struct to guarantee alignment, which is brittle, this patch just changes the harvester limit to be a 32-bit unsigned integer. Closes #6145
There was a bug impacting 32-bit platforms where an atomic.Uint64 was not aligned to a 64 bit boundary, causing the log prospector to panic on startup. Instead of reordering the field to the start of the struct to guarantee alignment, which is brittle, this patch just changes the harvester limit to be a 32-bit unsigned integer. Closes elastic#6145 (cherry picked from commit 9039cf7)
There was a bug impacting 32-bit platforms where an atomic.Uint64 was not aligned to a 64 bit boundary, causing the log prospector to panic on startup. Instead of reordering the field to the start of the struct to guarantee alignment, which is brittle, this patch just changes the harvester limit to be a 32-bit unsigned integer. Closes #6145 (cherry picked from commit 9039cf7)
…ic#6155) There was a bug impacting 32-bit platforms where an atomic.Uint64 was not aligned to a 64 bit boundary, causing the log prospector to panic on startup. Instead of reordering the field to the start of the struct to guarantee alignment, which is brittle, this patch just changes the harvester limit to be a 32-bit unsigned integer. Closes elastic#6145 (cherry picked from commit 40489ff)
While running beats-tester there is a panic at startup for Filebeat.
For confirmed bugs, please report:
filebeat.log.txt
filebeat.yml.txt
The text was updated successfully, but these errors were encountered: