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

[package request]: logrotate #2657

Open
Ferroin opened this issue Aug 8, 2024 · 7 comments
Open

[package request]: logrotate #2657

Ferroin opened this issue Aug 8, 2024 · 7 comments

Comments

@Ferroin
Copy link

Ferroin commented Aug 8, 2024

logrotate is the de-facto standard on Linux (and to a lesser extent other UNIX_like systems) for managing log file rotation, which is in turn a core part of sane system administration.

There appears to have been a previous attempt a few weeks ago to add logrotate in #2222 that was closed without any comments as to why by both the contributor who opened the PR or anybody else.

@q66
Copy link
Member

q66 commented Aug 8, 2024

the issue with logrotate is that it's inherently bad design that's impossible to fix (it's racey; it's impossible to reconcile log rotation and logging in separate processes, as the rotator cannot "pause" logging for when the logger is doing its thing, which can lead to wacky and potentially dangerous scenarios)

we have plans to revamp logging entirely with some new solution that will be builtin to the system, similarly to how systemd-journal works, though it will take some time to materialize

@mobin-2008
Copy link

Hmm, I think the s6-log is suitable program for a modern logging system. See https://skarnet.org/software/s6/s6-log.html

@q66
Copy link
Member

q66 commented Aug 8, 2024

i already ruled that out ages ago for a variety of reasons

@Ferroin
Copy link
Author

Ferroin commented Aug 9, 2024

I get that there are issues with logrotate, though every time I’ve ever seen an actual problem arise from using it it’s pretty much invariably the fault of whatever is logging doing questionable things that would be risky no matter what is trying to work with the log files. It also happens to work just fine for a majority of users in a majority of cases (because while there are a number of edge cases, most users will never actually encounter them), hence why it’s what I was suggesting here.

If the consensus is that those cases where it doesn’t work are so bad that it’s impossible to justify including it, might I suggest that the syslog-ng configuration that Chimera ships be changed so that it handles log rotation (because that actually is something syslog-ng can do if you use timestamps as part of the file templating), at least until whatever new system is being implemented is actually implemented? People generally expect to not need to manually rotate log files on Linux these days.

@nekopsykose
Copy link
Contributor

syslog-ng configuration that Chimera ships be changed so that it handles log rotation

this seems like a good thing to put in the default config, yeah

@nekopsykose
Copy link
Contributor

(because that actually is something syslog-ng can do if you use timestamps as part of the file templating)

hm, how do you set this up? syslog-ng configuration is.. hard to find specifics on, and there's nothing seemingly 'explicitly' rotation-related

the first thing i'd assume that means is to log to file("/var/log/messages-$somedatetemplatething") and then have a periodic job that prunes old logs, but that doesn't give you a nice unsuffixed 'current' log name, etc

@Ferroin
Copy link
Author

Ferroin commented Aug 12, 2024

the first thing i'd assume that means is to log to file("/var/log/messages-$somedatetemplatething") and then have a periodic job that prunes old logs, but that doesn't give you a nice unsuffixed 'current' log name, etc

Yes, that functionality is what I was referring to. I believe you want ${R_YEAR}, ${R_MONTH} and ${R_DAY}, which are the year, month, and day the message was received by syslog-ng. There are also technically S_ and C_ prefixed variants for the date in the log message and the date the message is actually processed respectively, but the consensus seems to be that the R_ variants are the most stable/reliable since they don’t depend on anything in the log message itself and don’t potentially change each time they get evaluated for a given message.

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

4 participants