Your message dated Tue, 07 May 2013 01:35:33 +0200 with message-id <[email protected]> and subject line Re: Bug#381864: Issue still present in version 9.0.6 has caused the Debian Bug report #381864, regarding sysstat: returns last months numbers to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 381864: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381864 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: sysstat Version: 6.1.3 ish One for upstream probably. I'm using 6.1.3 with the patch I submitted for #378995. Running "sar" I get this: Linux 2.6.8-2-386 (IS-938) 07/07/06 00:04:10 CPU %user %nice %system %iowait %steal %idle 00:14:10 all 0.31 0.45 0.16 0.06 0.00 99.02 ... 23:53:03 all 0.31 0.41 0.14 0.06 0.00 99.09 23:58:03 all 0.34 0.46 0.17 0.06 0.00 98.98 00:03:03 all 0.73 0.42 0.21 0.11 0.00 98.53 00:00:13 all 1.33 0.68 0.51 3.18 0.00 94.30 00:01:13 all 0.15 0.72 0.22 0.10 0.00 98.82 .. 12:47:07 all 0.20 0.80 0.30 0.08 0.00 98.62 Now those first lot are from 7th July however the second lot are from 8th August which are the ones I really want. I've had a look at the code and the datecmp is only checking times (not dates). The file_hdr is used, but that says 07/07. It looks like the file_hdr hasn't been updated. I also don't want last month's number - it's very confusing. I've put this quite horrible hack to work around this in sar.c, but it doesn't apply to other files and doesn't fix up the report header which still reports the old date. The patch as you can see includes bits of the previous patch I submitted. Adrian--- sysstat-6.1.3.orig/sar.c +++ sysstat-6.1.3/sar.c @@ -1288,6 +1289,9 @@ int rows = 23, eosaf = TRUE, reset = FALSE; long cnt = 1; off_t fpos; + unsigned long recent = 0; + struct tm recent_tm; + struct tm * today; if (!dis_hdr) /* Get window size */ @@ -1304,6 +1308,23 @@ /* Perform required allocations */ allocate_structures(USE_SA_FILE); + /* sometimes we have a file with a header from _last_ month + * containing data from last month and this month. + * TODO: should really update file_hdr too */ + recent = time(NULL); + today = localtime(&recent); + memcpy(&recent_tm, today, sizeof(struct tm)); + if (file_hdr.sa_day > recent_tm.tm_mday) + { + /* date must be in last month */ + if (recent_tm.tm_mon == 0) + recent_tm.tm_mon = 11; + else + recent_tm.tm_mon = recent_tm.tm_mon - 1; + } + recent_tm.tm_sec = recent_tm.tm_min = recent_tm.tm_hour = 0; + recent = mktime(&recent_tm); + /* Print report header */ print_report_hdr(S_O_NONE, flags, &loc_time, &file_hdr); @@ -1313,7 +1334,7 @@ * If this record is a DUMMY one, print it and (try to) get another one. * We must be sure that we have real stats in file_stats[2]. */ - do { + while(1) { if (sa_fread(ifd, &file_stats[0], file_hdr.sa_st_size, SOFT_SIZE)) /* End of sa data file */ return; @@ -1321,17 +1342,52 @@ if (file_stats[0].record_type == R_DUMMY) write_dummy(0, tm_start.use, tm_end.use); else { - /* - * Ok: previous record was not a DUMMY one. - * So read now the extra fields. - */ - read_extra_stats(0, ifd); - set_loc_time(0); + /* skip anything from more than a month ago */ + if (file_stats[0].ust_time < recent) + { + read_extra_stats(0, ifd); + continue; + } + + if ((! tm_end.use) && (! tm_start.use)) + { + read_extra_stats(0, ifd); + set_loc_time(0); + break; + } + + if (tm_end.use) + { + set_loc_time(0); + if (datecmp(&loc_time, &tm_end) <0) + { + read_extra_stats(0, ifd); + break; + } + } + + if (tm_start.use) + { + set_loc_time(0); + if (datecmp(&loc_time, &tm_start)>=0) + { + /* jump back to the start of this record, + * all stats are in file_stats[2] so we need + * to copy these to file_stats[0] */ + if ((fpos = lseek(ifd, - file_hdr.sa_st_size, SEEK_CUR)) < 0) { + perror("lseek"); + exit(2); + } + set_loc_time(2); + copy_structures(0, 2, USE_SA_FILE); + break; + } + read_extra_stats(0, ifd); + /* we now save this "previous" entry so we can restore it above */ + copy_structures(2, 0, USE_SA_FILE); + } } } - while ((file_stats[0].record_type == R_DUMMY) || - (tm_start.use && (datecmp(&loc_time, &tm_start) < 0)) || - (tm_end.use && (datecmp(&loc_time, &tm_end) >=0))); /* Save the first stats collected. Will be used to compute the average */ copy_structures(2, 0, USE_SA_FILE);
--- End Message ---
--- Begin Message ---Source-Version: 10.0.5 Reto Galante writes: Hi, > This issue is still present in systat version 9.0.6: It was fixed by upstream in version 10.0.5: 2012/05/16: Version 10.0.5 - Sebastien Godard (sysstat <at> orange.fr) * [Vitezslav Cizek]: sadc now overwrites its standard daily data file when this file is from a past month. Please note that sysstat 10.0.5 is included in the recently released Debian 7.0 (wheezy). If for some reason you don't want to upgrade your system yet, as a workaround for older versions, please make sure the old sysstat data files are removed by the /etc/cron.daily/sysstat cron job -- please check that: - the cron job is run regularly - the cron job calls /usr/lib/sysstat/sa2 script - either HISTORY or COMPRESSAFTER variable in /etc/sysstat/sysstat is set to value lesser then 28. Regards, robert
signature.asc
Description: OpenPGP digital signature
--- End Message ---
