[Holger Levsen]
Readahead works for me on etch since I upgraded to 2.6.22-4, still
using 1.20060421.1016-1~bpo+40+1
I've reported this in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465273#25
I know, but I have a hard time to believe that readahead-watch is able
to store its pid file
Hi Petter,
On Saturday 03 May 2008 09:30, Petter wrote:
I know, but I have a hard time to believe that readahead-watch is able
to store its pid file before /var/run/ is writable, and thus leaving
stop-readahead with no pid file to read to figure out the pid to stop
at the end of the boot.
[Holger Levsen]
After the one profiling I have done, I immediatly rebootet the
computer after logging in. /etc/readahead/boot was updated,
/etc/readahead/profile not.
I believe the explanation is here. The shutdown killed
readahead-watch, and not the boot. So you got readahead for the files
tags 465273 + patch
thanks
I tested this issue in Lenny, and am sure the problem is non-writable
/var/run/ at the very start of the boot. The mv to move the pid file
fail, and setting RAMRUN=yes solve it.
This patch should solve the issue, by moving the pid file to
/lib/init/rw/, and should get
Am Freitag, den 02.05.2008, 09:15 +0200 schrieb Petter Reinholdtsen:
tags 465273 + patch
thanks
I tested this issue in Lenny, and am sure the problem is non-writable
/var/run/ at the very start of the boot. The mv to move the pid file
fail, and setting RAMRUN=yes solve it.
This patch
[Julian Andres Klode]
Does not seem to conform to FHS, and could break Ubuntu. I have not
checked it, though.
You are correct. I was unable to convince the debian developers that
we needed to make /var/run/ a tmpfs to make sure it was writable at
the very start of the boot (as Ubuntu has
Hi,
On Friday 02 May 2008 09:15, Petter wrote:
I tested this issue in Lenny, and am sure the problem is non-writable
/var/run/ at the very start of the boot. The mv to move the pid file
fail, and setting RAMRUN=yes solve it.
This patch should solve the issue, by moving the pid file to
Hi,
On Saturday 05 April 2008 10:06, you wrote:
I believe I found the problem. readahead-watch store its pid file in
/var/run/, which is only writable that early during boot if RAMRUN=yes
is set in /etc/default/rcS.
A better fix to get it working also for the RAMRUN=no setting, is to
I believe I found the problem. readahead-watch store its pid file in
/var/run/, which is only writable that early during boot if RAMRUN=yes
is set in /etc/default/rcS.
A better fix to get it working also for the RAMRUN=no setting, is to
change the pidfile path of readahead-watch to
[Holger Levsen]
I'm running a etch system, with a 2.6.21-2 from bpo, and selfmade
readahead and usplash backports.
Does this kernel have inotify support? I believe that is the kernel
feature used by readahead for profiling, and it was added after the
2.6.18 etch kernel. Do not remember
package: readahead
version: 1.20060421.1016-1~bpo+40+1
Hi,
After I booted with the profile kernel option and logged into my window
manager session, readahead-list was still running. Nothing in /etc/readahead/
was updated.
I ran /etc/init.d/readahead stop and nothing in /etc/readahead/ was
Hi Petter,
On Monday 11 February 2008 19:56, you wrote:
Does this kernel have inotify support? I believe that is the kernel
feature used by readahead for profiling, and it was added after the
2.6.18 etch kernel. Do not remember exactly when.
Yes, it does:
$ grep -i inotify
12 matches
Mail list logo
