On 30/03/20 14:24, Stefan Raspl wrote: > I was using copytruncate indeed. But removing it, things still don't work > (kvm_stat continues to write to B). But maybe there's a deeper misunderstanding: > My assumption is you'd do something like 'kvm_stat -l > /var/log/kvm_stat.txt'. > If so, how could kvm_stat ever be aware of where its output gets redirected to, > nevermind open/closing any of those files? Or did you mean kvm_stat should close > & open stdout?! You're right, we need to have a file name command line option for kvm_stat, for logrotate to work. (BTW the file would be opened with O_APPEND, so the equivalent shell command line would use >> rather than >). >> You could stat the output file, and suppress the header if it is a >> regular non-empty file. But it would be a problem anyway if the header >> has changed since the last boot, which prompts the stupid and lazy >> question: how does your series deal with this? > > How could we stat the output file if kvm_stat is just writing to a console? You can fstat it---either stdout or the file opened with the new command line option. >>> As much as I sympathize with re-use of existing components, I'd like to point >>> out that my original patch was also re-using existing python code for rotating >>> logs, and made things just _so_ much easier from a user perspective. >> >> I understand that, yes. My request was more about not requiring >> kvm_stat-specific configuration than about reusing existing components, >> though. > > Taking a step back and looking at the tightly integrated kvm_stat - logrotate - > systemd approach outlined above, I'd bet most users would prefer a > self-contained solution in kvm_stat that merely requires adding a single extra > command line switch. And they can still add systemd on top, which wouldn't need > to interact with any of the other components except to start kvm_stat initally. It seems to me that using systemd and logrotate makes it possible to support progressive enhancement of kvm_stat's logging capabilities: - curses-based logging - manual CSV logging to disk (using > or >>) - CSV logging to /var via systemd unit - CSV logging to /var via systemd unit, with log rotation Indeed using logrotate would not make it possible to do manual CSV logging with log rotation, since the postrotate command uses systemctl. However it's only log rotation that would require using the systemd unit, and systemd does not have to interact with logrotate, so the integration seems relatively loose to me. Paolo
