Bug 46938
Summary: | logrotate gives errors on /var/log/pacct | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Joerg Dorchain <joerg> |
Component: | psacct | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-04-01 05:17:47 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joerg Dorchain
2001-07-02 10:23:24 UTC
Uninstall the process accounting package if you do not need it. We do not support homemade kernels. I have made a note however to try and make if fail more gracefully in the future. Is not supportingcustom kernels an official statement? Sorry to say, but this another step towards a closed system, which might be a reason for me to change the distribution. What the heck is the kernel-source-rpm for then? If only for reference, then root it under /usr/share/doc. Besides, if you support psacct only with with Redhat blessed kernels, then you might want to include a depency on the kernel package in psacct IMHO is is not too difficult to handle slight deviations gracefully. Sorry to say, I am a bit dissappointed by your statement. No, this is not a step towards a closed system in any way shape or form. You totally misunderstand my statements and have blown them out of proportion. "Support" is the key word here. A user compiling their own kernel can cause all sorts of things to break. A homemade kernel has not been subject to our quality assurance testing, and we cannot support every random kernel out there compiled with every permutation of random options with every random C compiler. We need some quality control in order to provide support. This is no different from any other vendor out there. That does not mean that we will not help you, or try to enhance the distribution based on suggestions you make, it means that if you rebuild the kernel and it breaks, you get to keep both pieces. Your request is really an enhancement request - one that I agree with or else I would have closed it as NOTABUG or WONTFIX. If such a request is beneficial to people and is not difficult to implement, and doesn't break anything, then it certainly is reasonable to ask for, and most likely have it implemented. I've deferred it so I can work on it later when I am planning on updating the psacct package. If that is not support, I don't know what is. I've said I'll add the needed bits which is more or less "yes, sounds good". What more could I possibly do? Please do not misunderstand me, I aim to help, not to hinder. If you are disturbed still by my comments after reading this, perhaps Arjan, our kernel RPM maintainer could comment better on what is meant by "support" for kernels. We certainly have no interest in tying anyone's hands to certain software or we wouldn't be here. Linux is about freedom of choice. IMHO Red Hat as a whole, and all of us engineers, etc. individually are here to serve the open source community, and our customers, users, etc. We are always 'ears wide open' to good user contributed ideas. If you have more suggestions such as this, please by all means submit more requests for enhancement against any packages you have suggestions for. There are very good chances that they will be beneficial to many and integrated if they are deemed good ideas. Thanks, TTYL Kernelwise, we obviously support the rpms we provided. This includes the kernel-source RPM. If people have problems building their own kernel I will do my best to help them with that. If things break when you select other options than we did, and the options are "sane" [1], I try to help with problems. If a problem is "non-critical" (one mail once a month isn't super critical, although annoying) and caused by a changed config, then fixing it for "the next package version" is something I do for my packages, provided it doesn't interact with current setups. Critical problems (dataloss, no operation etc) get obviously a higher priority. [1] with that I mean that if someone, say, disables support for the EXT2 filesystem and then complains that / doesn't mount, I'd call that NOTABUG. Simlar reasoning for, say, enabling devfs and then complaining /dev looks strange. Yes, that sounds very sane to me also, and is very much how I maintain XFree86, and other packages. I handle critical stuff first, followed by important stuff that affects the most number of users, etc.. down the priority line. Sometimes I squeak a simple quickie request in here and there also. If someone rebuilds XFree86 and the rpm has a problem, I will try to fix it or offer suggestions when possible. If someone tries to rebuild X with a non Red Hat provided compiler however and/or with their own custom host.def, random patches, or removed patches, and has problems though, I scratch my head and point them to xpert unless of course I can be helpful without going out of my way for 8 hours being a tech support guy. ;o) Sometimes even then I help out anyways because I love helping people. ;o) Time and TODO list size, engineering deadlines are the only constraints.... ;o) Well, ok, this explanation sounds clearer to me. The problem is (was) that the first answer contained nothing I did not know already. Besides, opening with an offending statements provokes quick shots, which is what I did and apologise for. I know that for quality control you need a defined test bed, wich excludes customs kernel configs that are unusable or insane in one way or another (the problem is that I don't know of any computer implementation of common sense to automate the decision ;-) I am merely a bit unpleased by the recent responses to my bug (or improvement) reports. Perhaps they are meant ok, perhaps it is because I am not a native english speaker, but somehow the form did not please me. Your last sentence confirms my again that Redhat has an open ear for user requests. Having some of my ideas going into the distribution is one of my major reasons for using Redhat. (The others are that I like the RPM package format and being able to rebuild the whole distro on my own when I had time or need to) So I am sorry if I took you wrong and looking forward to the next psacct release from updates The psacct package now contains its own initscript, and defaults to being disabled upon installation. Unless a user enables psacct now, it remains off. If a user recompiles a kernel without process accounting support, they can now disable the feature without removing psacct. This change is part of our skipjack beta, and rawhide and will be in the next release. Thanks. |