[Bug 1921747] Re: Backport missing %gnice CPU value for tickless CPU in sysstat.
I don't know how to trigger and therefore test this and sadly don't have the time to play around with this as well. So no, I can't guarantee anything. If that fix is contained in UB 20.04 already and it's too risky for you to backport to UB 18.04, I'll simply continue ignoring the problem, as I need to upgrade to 20.04 anyway. Did I understand correctly that the fix is part of UB 20.04 LTS already? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921747 Title: Backport missing %gnice CPU value for tickless CPU in sysstat. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysstat/+bug/1921747/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921747] Re: Backport missing %gnice CPU value for tickless CPU in sysstat.
> @Thorsten - is there a reasonable way to trigger the issue[...] I really don't know how to manually trigger that issue beyond what is described in the commit message already. I only recognized the problem and reported it after ignoring it in the past. > A field (which should be displayed as 0.00) was missing in CPU statistics displayed by "sar -u ALL" for tickless CPUs. https://github.com/sysstat/sysstat/commit/c542c259ba9e71a5ade235dfbcde67ac8b510c4f The only relevant things I "customize" in my UBs ist installing the HWE- kernel by following the official docs and storing more SAR files than the default. Everything else regarding especially the kernel is handled by APT and the package maintainers afterwards. Once the HWE-kernel is installed, I simply am using ONLY that as well, didn't ran into problems yet which might have forced me to use the non-HWE ones again. Though, I don't remove those beyond what "apt autoremove" allows me to do. So in the end, things are pretty default in my opinion. The following is the config of sysstat, if it makes any difference. The ".ioconf" file is NOT customized. ``` # sysstat configuration file. See sysstat(5) manual page. # How long to keep log files (in days). # Used by sa2(8) script # If value is greater than 28, then use sadc's option -D to prevent older # data files from being overwritten. See sadc(8) and sysstat(5) manual pages. HISTORY=28 # Compress (using xz, gzip or bzip2) sa and sar files older than (in days): COMPRESSAFTER=30 # Parameters for the system activity data collector (see sadc(8) manual page) # which are used for the generation of log files. # By default contains the `-S DISK' option responsible for generating disk # statisitcs. Use `-S XALL' to collect all available statistics. SADC_OPTIONS="-S DISK" # Directory where sa and sar files are saved. The directory must exist. SA_DIR=/var/log/sysstat # Compression program to use. ZIP="xz" # By default sa2 script generates yesterday's summary, since the cron job # usually runs right after midnight. If you want sa2 to generate the summary # of the same day (for example when cron job runs at 23:53) set this variable. #YESTERDAY=no # By default sa2 script generates reports files (the so called sarDD files). # Set this variable to false to disable reports generation. #REPORTS=false ``` Sometimes I get possibly related error messages from CRON, though: Mail subject: Cron command -v debian-sa1 > /dev/null && debian-sa1 60 2 Mail text:flock: Resource temporarily unavailable -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921747 Title: Backport missing %gnice CPU value for tickless CPU in sysstat. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysstat/+bug/1921747/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1921747] [NEW] Backport missing %gnice CPU value for tickless CPU in sysstat.
Public bug reported: Sysstat provided by UB 18.04 contains an error leading to missing column values for "%gnice" under some circumstances. That error has been fixed by changing only two lines of code. So it would be great if you would consider backporting that fix for UB 18.04 and 20.04, because I would like to continue using packages of the distribution. Thanks! https://github.com/sysstat/sysstat/issues/288 https://github.com/sysstat/sysstat/commit/c542c259ba9e71a5ade235dfbcde67ac8b510c4f $ lsb_release -rd Description:Ubuntu 18.04.5 LTS Release:18.04 $ apt-cache policy sysstat sysstat: Installed: 11.6.1-1ubuntu0.1 Candidate: 11.6.1-1ubuntu0.1 Version table: *** 11.6.1-1ubuntu0.1 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 11.6.1-1 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages ** Affects: sysstat (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1921747 Title: Backport missing %gnice CPU value for tickless CPU in sysstat. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysstat/+bug/1921747/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1825824] [NEW] Segfault in svnserve on UB 16.04 LTS, patch available most likely.
Public bug reported: Hi all, to make a long story short: There's a segfault in svnserve 1.9.3 distributed by UB 16.04 LTSm which is very likely available in 1.9.7 distributed with UB 18.04 LTS as well and has been fixed upstream by the following patch in version 1.9.9: https://svn.apache.org/viewvc?view=revision=1818584 https://lists.apache.org/thread.html/a60674fd3169cc66a73dd2fd12b60b56fc7d1332c6baa264fb0ae91a@ The more detailed background can be found on Launchpad and the users@ and dev@ mailing lists of SVN: https://answers.launchpad.net/ubuntu/+question/404322 https://lists.apache.org/thread.html/d51cd58613c1033a0e53210346f901cb264d7da77723e4a80412ebc8@ https://lists.apache.org/thread.html/6271afd4bd30f20512d371fc9483338f76996f907d5f9a0d904bbad7@ Some more details from the links: Some days ago I recognized a segfault in svnserve which seems to have been documented for UB 16.04 LTS already: > Apr 12 09:58:55 [...] kernel: [214930.125762] svnserve[556]: segfault at > 7f5f75994f00 ip 7f5f74ea1065 sp 7ffddc1353f0 error 4 in > libsvn_subr-1.so.1.0.0[7f5f74e43000+d3000] > Apr 12 10:11:41 [...] kernel: [215695.854475] svnserve[3769]: segfault at > 7f5f75994f00 ip 7f5f74ea1065 sp 7ffddc1353f0 error 4 in > libsvn_subr-1.so.1.0.0[7f5f74e43000+d3000] https://answers.launchpad.net/ubuntu/+question/404322 In all cases the version seems to be the default one distributed by UB, 1.9.3, and one additional thing in common seems to be the usage of hooks at least in some repos. The thread starter e.g. sends mails, while in one of my repos I'm distributing commits using svnsync. The problem is that it seems a bit difficult to reproduce what triggers the segfault: After recognizing it, I committed in some test repo without any hook and in the repo with the hook and in both cases wasn't able to trigger the problem. Notice that I dind't restart svnserve or the whole system before the tests, just as is. Looking at the past logs, the problem somtimes happens every few minutes, somtimes a few times a day and sometimes even not at all. The interesting thing in my case is that I have some repo to which things get committed multiple times a day automatically. That's as well the repo with the hook. So there shouldn't be any day without any commit to at least one repo, but I still have days without the problem. If the segfaults happen, it seems to be exactly the same error message until the main process gets restarted. My logs contained only one exception from the rule: 7f5f75994640 > Apr 9 12:50:14 [...] kernel: [1677281.956916] svnserve[30221]: segfault at > 7f0258833640 ip 7f0257d40065 sp 7ffe29fd1de0 error 4 in > libsvn_subr-1.so.1.0.0[7f0257ce2000+d3000] > Apr 9 12:55:09 [...] kernel: [1677577.574064] svnserve[31221]: segfault at > 7f0258833640 ip 7f0257d40065 sp 7ffe29fd1de0 error 4 in > libsvn_subr-1.so.1.0.0[7f0257ce2000+d3000] [...] > Apr 10 09:04:14 [...] kernel: [38850.248311] svnserve[19575]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 10 09:06:11 [...] kernel: [38967.469929] svnserve[19596]: segfault at > 7f5f75994640 ip 7f5f74ea1065 sp 7ffddc1353f0 error 4 in > libsvn_subr-1.so.1.0.0[7f5f74e43000+d3000] > Apr 10 09:13:25 [...] kernel: [39401.078386] svnserve[20429]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 10 09:15:44 [...] kernel: [39539.710149] svnserve[21583]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] [...] > Apr 11 12:07:13 [...] kernel: [136227.892728] svnserve[10466]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 11 12:08:38 [...] kernel: [136313.617840] svnserve[10515]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 11 12:08:38 [...] kernel: [136313.619646] svnserve[10512]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 11 12:09:41 [...] kernel: [136376.041439] svnserve[10591]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 11 12:10:10 [...] kernel: [136404.999582] svnserve[10629]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 11 12:11:25 [...] kernel: [136480.403404] svnserve[11437]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in > libsvn_subr-1.so.1.0.0[7fe569079000+d3000] > Apr 11 12:11:25 [...] kernel: [136480.414366] svnserve[11438]: segfault at > 7fe569bcbc30 ip 7fe5690d7065 sp 7ffd951fdad0 error 4 in >
[Bug 1694923] Re: Log rotating of tomcat7 finds too old files.
> My unimportant opinion is - yes - it should find and try to compress all old > files. > Because there is no guarantee the job ran on the former days. I get your point and therefore simply disabled compression for now, which was responsible the error mails from cron. > Also thinking about your case it will zip 2017-05.log on the second day of > may, > and then refuse to overwrite the zipped file right? Yes. > So you end up with a small log from day 1 zipped and a huge unzipped log of days 2-days-of-month. Partly correct, because it's about my own web apps, not Tomcat itself, and those log errors only. As errors don't occur very often, the file might be pretty small for a whole month, even of size 0. So the problem is not file size, but the approach trying to compress it each and every day even if it's size 0, just because all "old" files should be compressed. And because those files are of size 0 most of the time, it doesn't make sense to name them by day in opinion. > Plus day-of-month-1 warnings that there was a file in the way right? Correct and that's a bit annoying. > I think since you customized from the default which is logs per day to become logs per month. I didn't change Tomcat itself, only my own web apps are logging per month by default into subdirs of /var/log/tomcat7. So in fact I have both, Tomcat still logging per day, me logging per month. Simply because I prefer per month, but don't care enough for Tomcat itself to change it and customize working default configs. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694923 Title: Log rotating of tomcat7 finds too old files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/1694923/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1694923] [NEW] Log rotating of tomcat7 finds too old files.
Public bug reported: I've additionally described that problem on some other topic on SO: https://superuser.com/questions/1214566/why-does-the-behaviour-of-find- differ-using-daystart-and-mtime-0-vs-0 My web apps hosted by Tomcat7 log into /var/log/tomcat7 as well, with the only difference that I name my log files per month instead of per day. The problem is that the default log rotating script with compression enabled finds those log files even though they didn't change at a particular day like "yesterday", but only some days before the last time. That leads to unnecessary error mails from cron because the files can't be zipped if they already have been zipped before in the same month. The reason for that is name clashes of course, because my names potentially exist pretty often already per month. In general I can live with those messages coming once a while per month, because my log files only contain error messages, which simply don't occur that often. So the files shouldn't change very often and log rotating shouldn't try to zip the old files. But in fact it does try to zip those files every day even if they didn't change for some days. Look at the following example, where in one of my own log dirs a log file is present which was last changed some days ago, at 29.05.2017, while we today have the 01.06.2017. That log file from the last month is found when executing the find used in the log rotating script, which is something I wouldn't expect. > root@...:/var/log/tomcat7/.../RebootDevice# ls -lisa > [...] > 1089049 0 -rw-r--r-- 1 tomcat7 tomcat70 Mai 29 09:09 2017-05.log > 1089047 4 -rw-r--r-- 1 tomcat7 adm 402 Mai 26 10:22 2017-05.log.gz > root@...:/var/log/tomcat7/.../RebootDevice# find . -name \*.log -daystart > -mtime +0 > ./2017-05.log So what is the intended behaviuor of the log rotating script? Should it find all modified files AT LEAST changed 24 hours ago, but arbitrary old? If so, shouldn't that script have an upper limit to make it more compatible with names like mine? How about something like the following: > find . -name \*.log -daystart -mtime +0 -a ! -mtime +1 Using +2 and +3 seems to properly find my file changed some days ago, while +3 and +4 or +1 and +2 don't. ** Affects: tomcat7 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1694923 Title: Log rotating of tomcat7 finds too old files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/1694923/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1585121] [NEW] awstats produces regex warnings in version 7.4 with Perl 5.22 on Ubuntu 16.04 LTS
Public bug reported:
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/\"%{ <-- HERE Referer}i\"/ at /usr/lib/cgi-bin/awstats.pl
> line 9043.
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/\"%{ <-- HERE User-Agent}i\"/ at /usr/lib/cgi-bin/awstats.pl
> line 9044.
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/%{ <-- HERE mod_gzip_input_size}n/ at
> /usr/lib/cgi-bin/awstats.pl line 9045.
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/%{ <-- HERE mod_gzip_output_size}n/ at
> /usr/lib/cgi-bin/awstats.pl line 9046.
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/%{ <-- HERE mod_gzip_compression_ratio}n/ at
> /usr/lib/cgi-bin/awstats.pl line 9047.
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/\(%{ <-- HERE ratio}n\)/ at /usr/lib/cgi-bin/awstats.pl line
> 9048.
Those warnings occur whenever we execute awstats and they can easily be
fixed by escaping the "{" and "}" at the mentioned lines. In fact
awstats 7.5 fixed those lines already itself:
> AWStats Changelog
> -
>
> * 7.5 *
>
> - Compatibility with Perl 5.22
Please consider backporting those fixes, because awstats is most likely
executed by cron or such and this produces unnecessary mails with those
warnings. Disabling mails on warnings/errors is of course no solution,
because one would miss real configuration errors or such this way.
** Affects: awstats (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1585121
Title:
awstats produces regex warnings in version 7.4 with Perl 5.22 on
Ubuntu 16.04 LTS
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/awstats/+bug/1585121/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
