Skip to content
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

unable to get access or read file - notification in log-courier log #327

Closed
MKuzma opened this issue Jun 16, 2016 · 4 comments
Closed

unable to get access or read file - notification in log-courier log #327

MKuzma opened this issue Jun 16, 2016 · 4 comments

Comments

@MKuzma
Copy link

MKuzma commented Jun 16, 2016

This is not really an issue, more like an enhancement. Once we switch log-courier daemon user from root to log-courier it may not have access to all previously harvested files. I believe the only way to observe this is that there is missing a line containing "Started/Resuming harvester" in the log-courier log file. It might be useful in the future to include a log line that log-courier actually can't access the file, if that would be possible.

@driskell
Copy link
Owner

Due to supporting Glob patterns for the file paths it makes this difficult as Go doesn't report errors. However, what might be useful is at least checking the root directory is accessible as that is likely the most common problem.

I'll implement something to locate the "stem" of the Glob so we can check permissions there.

@MKuzma
Copy link
Author

MKuzma commented Jun 16, 2016

After your comment and as I'm slowly diving into Go language I can see the main cause :)

@driskell driskell modified the milestones: v2.0.5, v2.1.0 Oct 11, 2017
@driskell driskell removed this from the v3.0.0 milestone Feb 11, 2023
@driskell
Copy link
Owner

I don't have bandwidth for this as it's a fairly involved piece so will close. But happy to receive a PR

@driskell
Copy link
Owner

Found a package that will do /**/ support as a drop in replacement for Glob, and it also has ability to report IO errors. The plan is to only report a single IO error and then start ignoring them (as it aborts the scan if there is an IO error). If a configuration reload happens on the next scan it will then report a single one again. I considered doing it during configuration parsing but for a big ol' tree of logs that will slow down configuration parsing.

For the scenario noted here it should be enough, as you'd be able to check logs and see immediately the first scan didn't work and see just one error on where it had issues. And a reload will then alert on any further after fixing that error.

@driskell driskell reopened this Feb 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants