-
Notifications
You must be signed in to change notification settings - Fork 74
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
OpenVSwitch Logs aren't rotated #100
Comments
Interesting. Let me check if I have the same behaviour in XenServer 👍 |
Same issue on XenServer, can you create a XSO here? https://bugs.xenserver.org I mean, we'll fix it, but ideally, having the "upstream" fixed is also important 😄 |
@stormi I know where to make the modification, if you can create a repo (if it doesn't exists yet), I can write a fix myself. |
Ok :) |
Okay so I need to modify This line:
Will be replaced by:
Do you concur @bplessis ? |
XSO Created https://bugs.xenserver.org/browse/XSO-919
Well there are two ways to fix this, it could be interesting to also try to change the OVS configuration so that they log in the correct directory. But having the logrotate configuration fixed so as to rotate both location could be a plus |
Changing the log location could be confusing because the old logs would still remain at the old location, so I favour the minimal change, that is fixing the log rotation only. Unless the wrong location causes issues (but changing the location might cause other issues if anything in XenServer relies on it). Repository created: https://github.com/xcp-ng-rpms/openvswitch The way to fix until it is fixed in XS is by creating a patch to xenserver/etc_logrotate.d_openvswitch See https://xcp-ng.org/forum/topic/183/git-repository-structure-and-conventions-for-rpms ("Naming patches" and "Patch creation"). |
I have pushed an update candidate for 7.6
I don't know if changes to logrotate configuration are taken into account automatically. |
Logrotate is started by cron (cron.daily/logrotate) so no need for reboot/restart, however it will take two rotation cycle for the rotation to be triggered. |
Hi! Have you been able to test the update candidate to see if it works? Note that the configuration will not be updated if you manually modified it so it would be better to test with an unaltered configuration to start with. |
Hi,
|
Hi. Could you try again now? I promise this time if you get the same error I'll react quickly and find why :) |
Hi, Still same error, and i can't seem to have any upgrade whatsoever, could this be related to the additionnel dell repo ?
|
Ok, I made a mistake when I gave you the installation command. Here's the one that works:
|
There is one file left over: ovsdb-server.log |
Well actually given the content i should try to get rid of this, this log connection attempts to a OpenVswitch controller that is not here anymore ... |
So about ovsdb-server.log is there a configuration change that we should do? |
Hi, Sorry i missed this in the noise of my mailbox. Well it is a file generated by the ovs daemon so given that it can get pretty big in some case (and that's not easily fixable btw) i would say it should be rotated with the rest of them |
I have uploaded
|
I have pushed the update to all XCP-ng 7.6 users. Closing. Thanks for the report. |
There seem to be a little bug in the current logrotate configuration, the system is rotating rotated logs:
The file selection line in /etc/logrotate.d/openvswitch
should probably be better like this:
Also maybe the "notifempty" flag could prevent loosing usefull archived data to useless empty files. I can't really grasp however why there is only one rotated xensource.log file and 17 ovs-xapi-sync.log |
+ add notifempty parameter Refs xcp-ng/xcp#100 again
Thanks for the notification. Can you test http://koji.xcp-ng.org/kojifiles/work/tasks/2782/2782/openvswitch-2.5.3-2.2.3.3.xcpng.x86_64.rpm ? |
Someone reported the issue on the forum. I did not expect the wrong pattern to create 75000 files! https://xcp-ng.org/forum/topic/1031/too-many-weird-ovsdb-server-log-file We need to test the update candidate quickly. |
Look like my mail reply didn't make it here:
and yes, it (previous update) did create an awefull lot of file, had to use "find -delete" to remove them |
When did you install the update? |
3 days ago, like 2h after your post |
Did you restart the host or restart the openvswitch service to check that the updated binaries are still functional? Since the package went through the build system again, it's not exactly the same binary though it's built from the exact same sources, so I'd like to be sure. |
Hum, no did not do that. Will do and report |
@bplessis earlier you said
At first I did not understand because my test hosts have many rotated xensource.log files, not just one. Then I saw on one of our lab hosts that there was indeed only one rotated xensource.log file and wondered why the difference. Here's the state of my analysis: #149 |
it rebooted ^^ vm running on it, looks ok |
Thanks. All fine here also, and I got positive feedback on the forum. I think we're ready to push it as an update. |
Update pushed. |
@stormi Any chance that the update could also clear up the mess of multiply-rotated logs left behind in /var/log? I'd rather not have to do this manually on every host... Perhaps as a post-install script: (which avoids anything larger than 512 bytes, just in case). |
I considered doing it, but after the first mistake, in the prospect of releasing a fix fast, I preferred not to risk writing a broken post-install script. I could create an update candidate that cleans up and find time and users to have it tested if there's enough demand for it. Do you have many hosts? |
@stormi I would also vote for a conservative way. After this "hickup" we don't need a broken post install script :-) |
For others who encounter the same problem trying to upgrade openvswitch. Delete some 0 byte files in /var/log/* |
Same problem of no available inodes on a 27 TB disk. The compressed files are deleted by another script, based on total disc use. Resolved ! |
It look like there is a discrepancy between expected openvswitch log location (
/var/log/openvswitch/*.log)
and the real log files (/var/log/ovs-*.log
so no log rotation occurs on thoses files and some can grow bigThe text was updated successfully, but these errors were encountered: