strftime for syslogd?

T

thogard

Is there a reason that no one has added strftime formatting to the filename parsing for syslogd?
It seems to me that a line in /etc/syslog.conf like:
security.* /var/log/security/+%Y-%m-%d
would be very useful. In today's world of append only filesystems that take care of compression, wouldn't others find this useful?
The old rotate and compress was a hack to save disk space but that hasn't been an issue on my systems this century.

I'm asking here in General because I've heard nothing back from other places I've asked this question. The patch should be simple, (look for %+, call strftime with a buffersize -1 to ensure a null at the end), but no one has done this in the 40 years that syslog has been around.

Modern logging standards (for a few decades now) have been to keep logs as immutable as possible yet the move and compress process violates that and the filesystem will compress anyway and can keep a thousands of years worth of log filenames.

So what am I missing?
 
I would consider it to have little to no value since ls -l shows last update time on the syslog file. why strive to compliate your mousetrap? Kind of like all the kiddies who think it is cool to embed color coding in command line program output. ... just my opinion

I guess the other thing that has me worried about this kind of question is that seem a step toward advocating systemd/journald style logging.
 
thogard said:
Is there a reason that no one has added strftime formatting to the filename parsing for syslogd?
Click to expand...
This is just my 2 cents but I'd say that the reason behind this is because it doesn't add anything useful.

In fact, I'd even argue the direct opposite because such time stamps would only complicate things. Log rotation for example can focus on main logfiles without having to bother with date calculations. For bigger farms all those unnecessary calculations could easily add up with regards to resource requirements.

Also... as an administrator I would also never want to implement something like this. When I need to check the current logs I don't need the extra burden of having to think about current dates and what not, instead I need results now. So basically doas less /var/log/security vs. doas less /var/log/security`date +%y%m%d`; the latter can easily become a huge problem when log rotation hasn't taken place yet because then you suddenly need to check when the last rotation has ran (or ls /var/log/sec*; happy typing afterwards!), thus fully deviating you from your main goal and thus wasting precious time.

Why would anyone want to bother with that?

functionality > theory
 
Does anyone use immutable or append only file systems for their logs? Data standards such as PCI DSS 10.3.2 seem to imply it should be done on both the originating server and the core logging servers.

I figure the +% parsing won't break anyone's system. It is useful for additional protection of logs. tail -f already knows how to deal with rollover if you do need to look at a log that way. Log rotation would typically be on a calendar boundary, not on file size so automatic tools are easy to create. I've been doing this with web server and email logs without any issue for a long time. A common problem was that the newsyslog type rotation would rotate logs before the writing process was finished. This helps with that slow log write issue too.
 
You must log in or register to reply here.
Back
Top