search

dCache / dcache

dCache - a system for storing and retrieving huge amounts of data, distributed among a large number of heterogenous server nodes, under a single virtual filesystem tree with a variety of standard access methods
https://dcache.org
285 stars 136 forks source link

access/event logs shouldn't go to /var/log/dcache #3743

Open calestyo opened 6 years ago

calestyo commented 6 years ago

Hi.

This is just ticket to not forget this (I likely provide patches for it later myself).

As of now, access and even logs are written by the default logback.xml config to

${dcache.log.dir}/${dcache.domain.name}.access
${dcache.log.dir}/${dcache.domain.name}.event

which is usually /var/log/dcache, where also the "normal" log files go to.

I always felt this makes the dir less "readable" so I changed that for myself to ${dcache.log.dir}/access/${dcache.domain.name}.log ${dcache.log.dir}/event/${dcache.domain.name}.log long ago, but here's one more reason that doesn't depend on my personal taste (though this should of course also be an ultimate decision maker O;-) :-D):

We have, at least in Debian packages: /etc/logrotate.d/dcache which does logrotation of any /var/log/dcache/*.log (which doesn't include *.log in subdirs of it). If some user changes his logback.xml to e.g. use paths like: ${dcache.log.dir}/${dcache.domain.name}.event.log, maybe because this is better for is favourite windows text viewer ;-) ... he likely gets into troubles.

logback already does its own rotation so even in the old sysvinit days it would have caused issues. With my (not yet ready, but proposed patches in pull request 3730, which improve the rotation if rsyslogd is used, it would be even more reasonable trying to avoid that non-rsyslogd logs are accidentally rotated.

Cheers, Chris.

paulmillar commented 6 years ago

The logrotation configuration has been part of the Debian package long before the effort towards systemd integration (since at least 1.9.13), so this issue is actually long standing.

The access and event log filenames were changed so they don't end .log specifically to avoid both logback and logrotate try to rotate the same file.

So, yes, an admin can "break" a working setup by giving the event and access log files filenames that end .log -- however, this is nothing new.

What we can do is make this dependency clearer; for example, but included a note in the logback configuration describing how .log files are rotated by logback while other files are not.

calestyo commented 6 years ago

The later I did already in PR 3730.

Still if you'd agree I'd simply prvoide another PR which changes the locations into action/ and event/ subdirs, and the extensions to the more common .log ?

paulmillar commented 6 years ago

There is a potential issue here: the access and event log files are rotated much more aggressively than normal dCache (domain) log files. The logrotate configuration would need to reflect this. You would also need to remove the log-rotation that logback is doing, to avoid duplicate work (with potential conflicts).

However, I don't understand the motivation here.

You describe a hypothetical situation where an admin can create a broken deployment. We can add documentation to try to prevent that in the future, but, in general, we can't prevent admins from creating broken configuration.