Bug 46938 - logrotate gives errors on /var/log/pacct
Summary: logrotate gives errors on /var/log/pacct
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: psacct   
(Show other bugs)
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-02 10:23 UTC by Joerg Dorchain
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-01 05:17:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joerg Dorchain 2001-07-02 10:23:24 UTC
Description of problem:
I get mails with the followoing content

errors occured while rotating /var/log/pacct {

accton: Function not implemented
error running prerotate script --
                                leaving old log in place

How reproducible:

Steps to Reproduce:
1. Install a kernel without process accounting
2. Wait till the next new month
3. See the mail	

Actual Results:  I got the mentioned mail

Expected Results:  No mail and no complaints on whatever is wrong with the
fact that I don't need process accounting on my setup.

Additional info:

The act() system call returns with ENOSYS. (Of course, I disabled it)
gives this as Function not implemented and returns with exit code 38.
logrotate sees this as non-success.

A workaround could be to have a || true appended to the accton lines in

Comment 1 Mike A. Harris 2001-07-02 23:14:47 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.

Comment 2 Joerg Dorchain 2001-07-03 08:56:04 UTC
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.

Comment 3 Mike A. Harris 2001-07-03 09:51:52 UTC
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

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.


Comment 4 Arjan van de Ven 2001-07-03 10:12:20 UTC
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

Comment 5 Mike A. Harris 2001-07-03 10:24:43 UTC
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@xfree86.org
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)

Comment 6 Joerg Dorchain 2001-07-03 12:22:58 UTC
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

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

Comment 7 Mike A. Harris 2002-04-01 05:19:32 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.