I ran into problems starting acpid on my laptop. I traced it down to a log file (/var/log/acpid) being over 2 GB in size. When I renamed the log file, acpid would start properly. Does anyone have a solution to this problem, such as a script run by cron, to rename the file on a weekly basis or some other such thing? Is this something that should be built into /etc/init.d/acpid to control this problem? I'm asking this in the sense of improving the general operation of the distribution for users who have limited technical abilities. Thanks... Tom.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Cada wrote:
I ran into problems starting acpid on my laptop. I traced it down to a log file (/var/log/acpid) being over 2 GB in size. When I renamed the log file, acpid would start properly.
Does anyone have a solution to this problem, such as a script run by cron, to rename the file on a weekly basis or some other such thing?
Sure.
Create a file /etc/logrotate.d/acpid (as root), with the following content:
/var/log/acpid {
missingok
notifempty
compress
dateext
rotate 9
size=+4096k
create 0640 root root
postrotate
/etc/init.d/acpid reload
endscript
}
Make sure logrotate is installed (rpm -q logrotate).
Actually that stuff should be included in the acpid RPM.
Anyone has some 5min to open a bug ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Mon 14. Nov - 10:43:21, Tom Cada wrote:
I ran into problems starting acpid on my laptop. I traced it down to a log file (/var/log/acpid) being over 2 GB in size. When I renamed the log file, acpid would start properly.
Does anyone have a solution to this problem, such as a script run by cron, to rename the file on a weekly basis or some other such thing?
Is this something that should be built into /etc/init.d/acpid to control this problem? I'm asking this in the sense of improving the general operation of the distribution for users who have limited technical abilities.
This should be already fixed. Remove the logfile and run the you update and the problem should not appear again. Regards, Holger
On Wednesday 16 November 2005 7:55 am, Holger Macht wrote:
On Mon 14. Nov - 10:43:21, Tom Cada wrote:
I ran into problems starting acpid on my laptop. I traced it down to a log file (/var/log/acpid) being over 2 GB in size. When I renamed the log file, acpid would start properly.
Does anyone have a solution to this problem, such as a script run by cron, to rename the file on a weekly basis or some other such thing?
Is this something that should be built into /etc/init.d/acpid to control this problem? I'm asking this in the sense of improving the general operation of the distribution for users who have limited technical abilities.
This should be already fixed. Remove the logfile and run the you update and the problem should not appear again.
Tried it and it appears to have worked. Before the update, acpid was going into a loop condition that generated many error messages, filling the log file, along with grabbing all available cpu cycles. A further question though. Can running YOU step on already installed programs that have been modified to meet the SLICK requirements? I guess I am wondering if the kernel can be inadvertently upgraded, loosing the CK patches? Thanks...Tom.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Cada wrote: ...
A further question though. Can running YOU step on already installed programs that have been modified to meet the SLICK requirements? I guess I am wondering if the kernel can be inadvertently upgraded, loosing the CK patches?
Yes, definately.
YOU, YaST2, smart, y2pmsh, apt-rpm, yum only look for package names and version numbers. They don't
care where the package "comes from".
If your SLICK kernel package is called kernel-default-2.6.13-15.ck and Novell puts up a newer kernel
version (e.g. kernel-default-2.6.13.1-... or kernel-default-2.6.14-...) or a newer kernel package
release (e.g. kernel-default-2.6.13-16), then it will be upgraded ("stepped on", as you wrote).
But that's not necessarely a bad thing, as you get the security or bug fixes, which is much more
important than the 5% of performance you gain from the few additional CK patches in the SLICK kernel
(the SUSE Linux kernel already has around 80% of the CK patches included anyway).
And as soon as someone from the SLICK team puts up an updated SLICK kernel (e.g.
kernel-default-2.6.13.1-92 for SUSE Linux => kernel-default-2.6.13-92.slick for SLICK) that includes
the fixes from Novell's package, it will be updated again (but using YaST2/smart/yum/apt instead of
YOU).
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
participants (3)
-
Holger Macht -
Pascal Bleser -
Tom Cada