Skip to content

Same inode being used - SinceDB not updated properly with logstash-input-file v4.2.1 #279

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
moulisea opened this issue Oct 21, 2020 · 2 comments

Comments

@moulisea
Copy link

Please post all product and debugging questions on our forum. Your questions will reach our wider community members there, and if we confirm that there is a bug, then we can open a new issue here.

For all general issues, please provide the following details for fast resolution:

  • Version: v4.2.1
  • Operating System: windows server 2012 R2
  • Config File (if you have sensitive info, please remove it):
  • Sample Data:
  • Steps to Reproduce:
    when log rotation happens, same inode being used. After reading end of file(xx.log), when log rotation happens, it starts reading(xx.log.2020-10-dd - the file which got rotated). It supposed to read(xx.log file) but thats not happening.

when I delete sincedb file, stop and start logstash with start_position => beginning, the new inode is being generated and the entire records from xx.log is being sent to kafka.

Using logstash 7.9 with logstash-input-file v4.2.1.

This issue is mostly similar to what is mentioned here - #207

Below is the config we use:

input {
  file {
    path => "C:/Users/xx.log"
  }
}

filter {
  mutate {
    remove_field => ["@timestamp", "@version", "path", "host"]
  }
}

output {
  kafka {
    bootstrap_servers => "broker"
    codec => plain { format => "%{message}" }
    topic_id => "topic" 
    client_id => "xxlogs"
    id => "xxlogs"
    jaas_path => ""
    kerberos_config => ""
    sasl_kerberos_service_name => ""	
    sasl_mechanism => ""
    security_protocol => ""
    ssl_endpoint_identification_algorithm => ""
    ssl_key_password => ""
    ssl_keystore_location => ""
    ssl_keystore_password => ""
    ssl_keystore_type => ""
    ssl_truststore_location => ""
    ssl_truststore_password => ""
    ssl_truststore_type => ""
  }
}
@moulisea
Copy link
Author

moulisea commented Oct 21, 2020

@guyboertje if you have any recommendations, let us know. Thanks

@kares
Copy link
Contributor

kares commented Nov 11, 2020

this specific case is fixed in 4.2.2 (#276), please give it a go (updated plugin is shipped with LS >= 7.9.3)

@kares kares closed this as completed Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants