Bug#637295: Breaks log analysing tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, Am Mi den 10. Aug 2011 um 15:59 schrieb Christian Kastner: On 08/10/2011 12:43 PM, Klaus Ethgen wrote: The solution of #609780 breaks all log analysing tools. First, it most certainly does not break all log analyzing tools. Most notably, logcheck works fine with this solution. Please provide some specific examples of such tools so that we may better form our opinion. If it really breaks a lot of tools we might revert it. Am Do den 11. Aug 2011 um 0:38 schrieb Javier Fern?ndez-Sanguino Pe?a: Breaks all seems rather harsh (and untrue, we did review logcheck). Anyway, if a log analysing tool breaks because of this change you should bug *them*, not us. The cron log format is not set on stone and (in Debian) they will have until the next release to adapt. Well, You may checked logcheck but not logwatch. In logwatch the lines are summarised. With the PID twice in the file that cannot be done anymore. Also all other tools that relies on a more ore less constant message for the same think, not related if they are official or hand written, will not work anymore. Please bear in mind that this is Debian's unstable, and our interest is to improve CRON not to keep log analysis tools happy. Well, that is clear. But also in sid this is a bug. And you might have seen that I tagged the bug normal and not grave as it would be breaking other applications. Am Mi den 10. Aug 2011 um 15:59 schrieb Christian Kastner: More over it makes no sense to log the PID twice in the logs. [...] The reason #609780 was re-opened is precisely because it is *not* the same PID twice. I checked twice in my log file and all entries from cron have the same PID twice in the same line. So there is never a difference and this message is unusable at all. The start message CMD is logged by the fork()ed child before it exec()s, the end message END by the parent. Therefore the syslog PID is always at least off-by-one. I have no message in the file about an end. There is only the line with the CMD in the file. Am Do den 11. Aug 2011 um 0:38 schrieb Javier Fern?ndez-Sanguino Pe?a: In logfiles the PID is expected direct behind the binary and is recorded by the syslog (The PID is part of syslog protocol). Putting the same PID in the message do not only add redundancy that is not needed, it breaks other tools too as log analysing tools or intrusion detection systems. You don't seem to have read the bug report that motivate the change and you don't seem to understand the change fully either. I had. But there is no sense for me to add such information. However, I believe that there _is_ for _some_ people. But then please make this configurable and not on by default. For me this additional (same) PID is boring, broken, unuseful and makes lot of troubles that I might overlooked the real important messages in my log summary. Please revoke that broken patch. We will not revoke that patch. Uh. Please calm down. I please you to do not ordered. We might adjust it to avoid redundant information (for the 'CMD' call at least) but it is certainly our intention to keep the change. To revoke a patch and make it new and not broken is no bad solution. It is common in software development. This particular patch is broken. And as such has to be revoked in my eyes. That do not include that a revoked patch that is more smooth cannot be added in future. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQGcBAEBCgAGBQJOQ5VuAAoJEK8RO3RE9oVxwMoL/06xiJQh8GNAEyYsrg6idF1Q j4DE8Mf6uDO+zQiRaYpc8+o+IF1klybnZczzIIW7xL+Fz79qptmaFNaOF6wBECEk NLR8G02oiNHV/8JTetOf8HzRVvbl3lYYeSL19XL59z/WW8td5lfH3NeD6PLQbU1a 3kXhx9QCbPiH3jPS4XKsV5xZWkHVLYY4uYbIoT2V3MhfgUgLst4gsI1dt3o6z95h oWlMuJEsdrDim/OKfz9s4KvNcSnHVIw1VAF5+4EEPsTikpjU6AGt5+f8IjYxFtlU 6O+FE7cOdWmKciEpVJXzFOm083Y7QD1bvlBosGvAhZ9vraajnh9jiajhjtXeLTZO +5fuE0MvXoh9HY5/FixCRfdFkLJFVbAkaXfqRlQBbYNXEr+urnXTqNNeYDvLrq6f zWNIXXcREe0bC7vC84YxF3+/wvC1Qhc7VBggAFlrCVwZBzWayfIrbGaO+k6hNTch QrHpoYItyTt24669igUQoc9a2/oM4Tdw1WvZUHUtzw== =Tpy3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637295: Breaks log analysing tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: cron Version: 3.0pl1-119 Severity: normal Tags: sid The solution of #609780 breaks all log analysing tools. More over it makes no sense to log the PID twice in the logs. In logfiles the PID is expected direct behind the binary and is recorded by the syslog (The PID is part of syslog protocol). Putting the same PID in the message do not only add redundancy that is not needed, it breaks other tools too as log analysing tools or intrusion detection systems. Please revoke that broken patch. Bug was introduced in version 3.0pl1-119. - -- Package-specific info: - --- EDITOR: - --- usr/bin/editor: /usr/bin/vim.gnome - --- /usr/bin/crontab: - -rwxr-sr-x 1 root crontab 34048 Aug 7 22:20 /usr/bin/crontab - --- /var/spool/cron drwxr-xr-x 1 root root 42 Jun 18 2010 /var/spool/cron - --- /var/spool/cron/crontabs drwx-wx--T 1 root crontab 10 Jun 19 2010 /var/spool/cron/crontabs - -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (800, 'unstable'), (700, 'stable'), (60, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Versions of packages cron depends on: ii adduser3.113 add and remove users and groups ii debianutils4.0.2 Miscellaneous utilities specific t ii dpkg 1.16.0.3+nmu1 Debian package management system ii libc6 2.13-15 Embedded GNU C Library: Shared lib ii libpam-runtime 1.1.3-2 Runtime support for the PAM librar ii libpam0g 1.1.3-2 Pluggable Authentication Modules l ii libselinux12.0.98-1.1SELinux runtime shared libraries ii lsb-base 3.2-27Linux Standard Base 3.2 init scrip Versions of packages cron recommends: ii exim4-daemon-light [mail-tran 4.76-2 lightweight Exim MTA (v4) daemon Versions of packages cron suggests: pn anacron none (no description available) ii checksecurity 2.0.14 basic system security checks ii logrotate 3.7.8-6Log rotation utility Versions of packages cron is related to: pn libnss-ldap none (no description available) pn libnss-ldapd none (no description available) pn libpam-ldap none (no description available) pn libpam-mount none (no description available) pn nis none (no description available) pn nscd none (no description available) - -- Configuration Files: /etc/pam.d/cron changed [not included] - -- no debconf information - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQGcBAEBCgAGBQJOQmC+AAoJEK8RO3RE9oVxipsL/RCrmfw+MXkYdipqYeMqp6be d9wiqihy6T/PF0o+5Q//a4SOXCqMdb30l2zLqGu0Ai8+RVced8EpMpJf1sNvReL+ 4Znj+wXzwCrWV5FRpmHDjaLOJm3Ad0TM1rX2Snbsc1BwkOfrWMQIjOhSzWNDjN58 vc/TSkAFaHSP3605a98EygUrptBkAWScKdP55f0EkSpf6gktkbRDwWDRF5pPE87D o1ktfKrspXDjlYQO3RWuxKl/I72of8NtTxKmTtKCLuo6PIUuQM3PQLPdTp83MjHM wJGeVycjUaU8YJuX20wmJFYFDyB1fntxDe5UJgUqSzq4OWi7yofZbxBMIMuSw3v0 SxcV1CWlrW45MIyZ3lV83PlU6NOhBIHLMLdY2ih/yRgbHjGhB3N1/8pTs40D+i0f LbveEtU8/eIVAKPZ25a13by2bZKkFWCGY0p7+cTLlEV4Yy1cTS67ocuUWJLfv8c9 /VTha4fdFA8pN210znNvdqz2hy/aC7B7DDwtp5F0tw== =A1CA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637295: Breaks log analysing tools
On 08/10/2011 12:43 PM, Klaus Ethgen wrote: The solution of #609780 breaks all log analysing tools. First, it most certainly does not break all log analyzing tools. Most notably, logcheck works fine with this solution. Please provide some specific examples of such tools so that we may better form our opinion. If it really breaks a lot of tools we might revert it. More over it makes no sense to log the PID twice in the logs. In logfiles the PID is expected direct behind the binary and is recorded by the syslog (The PID is part of syslog protocol). Putting the same PID in the message do not only add redundancy that is not needed, it breaks other tools too as log analysing tools or intrusion detection systems. The reason #609780 was re-opened is precisely because it is *not* the same PID twice. The start message CMD is logged by the fork()ed child before it exec()s, the end message END by the parent. Therefore the syslog PID is always at least off-by-one. One possible solution could be to keep the CMD message as pre-119, and only add the PID fix to END messages, since these are 1) a Debian extension and 2) disabled by default. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#637295: Breaks log analysing tools
On Wed, Aug 10, 2011 at 11:43:28AM +0100, Klaus Ethgen wrote: The solution of #609780 breaks all log analysing tools. More over it makes no sense to log the PID twice in the logs. Breaks all seems rather harsh (and untrue, we did review logcheck). Anyway, if a log analysing tool breaks because of this change you should bug *them*, not us. The cron log format is not set on stone and (in Debian) they will have until the next release to adapt. Please bear in mind that this is Debian's unstable, and our interest is to improve CRON not to keep log analysis tools happy. In logfiles the PID is expected direct behind the binary and is recorded by the syslog (The PID is part of syslog protocol). Putting the same PID in the message do not only add redundancy that is not needed, it breaks other tools too as log analysing tools or intrusion detection systems. You don't seem to have read the bug report that motivate the change and you don't seem to understand the change fully either. The goal of the change is to add in the log messages the PID of the child processes so tools that analyse the cron log's output can actually determine how much time did a task take to run. Before the change the PID that is in the syslog is not good enough to analyse the logs generated because of the way that cron behaves. For reference please see /usr/share/doc/cron/examples/cron-stats.pl which has not been adapted (yet) to the change. Without the information we are providing *now* tools can just wild guess what the PID of the cron child who executes the cron task is. Please revoke that broken patch. We will not revoke that patch. We might adjust it to avoid redundant information (for the 'CMD' call at least) but it is certainly our intention to keep the change. I will repeat it again: it is not such an intrusive change and if log analysis tools break because of these change, they have plenty of time to be bugged and fixed. As log analysis software tool authors know, it is *their* tool to keep with the pace of changes in the format of log messages generated by the software. Regards Javier signature.asc Description: Digital signature
