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

ERROR: Closing data source tag in filename of datetime output #270

Closed
5 tasks done
casesolved-co-uk opened this issue Aug 7, 2024 · 2 comments · Fixed by #274
Closed
5 tasks done

ERROR: Closing data source tag in filename of datetime output #270

casesolved-co-uk opened this issue Aug 7, 2024 · 2 comments · Fixed by #274

Comments

@casesolved-co-uk
Copy link

Checklist before starting to submit this bug report

I confirm that:

  • I am submitting a bug report! :)
  • I have tested this with the latest stable Snoopy version (or the latest master build).
  • I have checked the FAQ.
  • I have read Snoopy's documentation here and here.
  • I have searched Snoopy issues for an existing issue that matches my problem, and found none.

Bug description

Got the following file in /var/log when I enabled logging to file with the datetime format:

snoopy.log-[ERROR: Closing data source tag ('}') not found.]

Bug reproduction steps

  1. Ubuntu 20.04.06 LTS (AWS version)
  2. Install using install-snoopy.sh as root (version 2.5.1)
  3. reconfigure to output using: output = file:/var/log/snoopy.log-%{datetime:%Y-%m-%d}
  4. disable and enable snoopy
  5. View file in /var/log

Expected result

Normal filename

Actual result

Strange filename above

@casesolved-co-uk casesolved-co-uk changed the title <BUG TITLE HERE> ERROR: Closing data source tag in filename of datetime output Aug 7, 2024
@bostjan
Copy link
Member

bostjan commented Aug 9, 2024

Hey @casesolved-co-uk, thanks for reporting this. By the looks of it, it seems the format parser doesn't correctly recognise the } character, for whatever reason (maybe because it's the last character in a string, and the parser fails to deal with that location correctly), and thus the creation of datetime string fails, resulting in an error. Clearly there are some (quite literally) edge case tests missing here. I'll look into this soon-ish.

@bostjan
Copy link
Member

bostjan commented Sep 5, 2024

The fix will be released in v2.5.2. Thanks for reporting this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants