browsercache (tries to fix probs in Puppy)

[MU]

Running Firefox or Seamonkey in Muppy 008.3 on a computer with 256 MB Ram.
Even though I have a swap partition, they "freeze" after a while.
I found no logic reason for this.
I suspect, there might be issues with Unionfs.

For this reason I wrote this script, the freezes seem to be solved now.

What it does:
It searches the Cache-Folders of Firefox, Seamonkey and Opera.
In /root and /home

Then it deletes them, and creates symlinks instead pointing to new folders in /tmp

ATTENTION:
Some versions of Puppy use a Ramdisk for /tmp.
These are 2.17, 3.01.
Here you should NOT use this script, as the Ramdisk easily fills up.
Or set the Cache-settings in your browser to a smaller value.
To find out the size of your /tmp ramdisk on those versions of Puppy,type:
df -m


I run this script in /root/.xinitrc
By adding this new line after #!/bin/sh:
browsercache

NOTE: as it replaces Cache folders, these must exist.
So it will not work immedeatly in a "clean" installation.
You just need to start Firefox/seamonkey once, or add the "Cache" folders manually (important if you create pupletts), then run the script.
On my system these are:
/root/.mozilla/Cache
/root/.mozilla/default/Cache
/root/.mozilla/firefox/ep9865bu.default/Cache
/root/.opera/cache4

The script then will find them, and replace them with symlinks.
In my Muppy buildsystem, I already add the symlinks to the buildsystem.

The script is attached, use it at own risk, it is new and not tested over a longer period:
/usr/sbin/browsercache

Mark

[BarryK]

Very interesting. I don't have a problem with SeaMonkey freezing, but your fix is definitely worth looking into, maybe even put it in in case.

[dvw86]

I noticed that too while running Seamonkey for a few days, but only when running totally in RAM. When booted as a frugal install I do not have this problem at all. My thought was to just write a Bash or Cron script that cleans out Seamonkey's cash once a day. This is in Puppy 3.01.

[Lobster]

If I open sufficient windows usually about 10, Seamonkey can freeze for aprox 20-30 secs but it has not frozen (might be something to do with cache clearing), it then resumes . . .
I have 512MB of Ram

Hope that is relevant

[john biles]

Hello MU,
I hope this works as I have also suffered the same problem in testing TEENpup with Firefox, Flock and other browser's while running live.
Excellent work!

[MU]

I made a small change.
Now files in the Cache-folders in /tmp are deleted when the script is run (so when X starts).
I was browsing intensively on different sites yesterday for several hours using Firefox,no problems so far
Mark

[MU]

Interesting:
when I was shutting down recently, unionfs sent some error-messages about the files in the Cache-folders (in /tmp).
This strengthens my assumption, that the freezes were related to unionfs.
So /tmp is no 100% solution, but in /tmp this seems to have less critical consequences.
I now went one step further, and added this in the beginning of
/etc/rc.d/rc.shutdown

Code: Select all

rm -rf /tmp/Cache-Firefox/*
rm -rf /tmp/Cache-Seamonkey/*
rm -rf /tmp/Cache-Opera/*
sync

So now when Puppy shuts down, the browser cache is deleted.
This should help unionfs to have less "orphaned inodes" at next startup due to the not possible proper unmount of the layered filesystem.
Mark

[Yogi]

I posted this yesterday under "Users" but it might also pertain here.

I'm using Mean Puppy 2.02-opera.iso and have similar problems. I'll be surfing the net and usually within an hour Opera will just close by itself. I can't reopen it unless I reboot. The error messages on screen are all:

/tmp xxxxx - no space left on device

with xxxx referring to each of the seven files within /tmp.

I have "disk and memory cache" empty on exit and during a normal boot of Mean Puppy the save file isn't any larger. However, if it crashes then upon reboot I have noted the "extra" images and files in 'cache4'. But it's not in an amount that would have exceeded the capacity of the "save file". That's why I don't understand the meaning of the above error message.

Also, a new problem recently. Whenever I login to this forum and have , say, 3 or 4 pages open, cpu usage goes to 99% and Opera locks up. But it doesn't do that whenever I'm just surfing random sites and have even more tabs open. Very strange.

I'm running a frugal install and have 1 gig of ram. Flash 7 installed in plugins. My save file is 128 mb with approx 50 mb of free space left. So what gives? I've never had this problem using Firefox or SeaMonkey in other Puppys. I really like this combo of Mean Puppy and Opera but I don't know. Any ideas?

[Lobster]

I have discovered this unusual way of seeing the browser cache (might not work in pre dingo because a different wallpaper setter is used)
http://www.murga-linux.com/puppy/viewto ... 623#192623

the key seems to be the semi transparent image (sorry about the mantra but that is the image I was using) - wait a minute jpeg does not do transparency?

Help!
Prepare my padded room . . .

[MU]

Yogi

Also, a new problem recently. Whenever I login to this forum and have , say, 3 or 4 pages open, cpu usage goes to 99% and Opera locks up. But it doesn't do that whenever I'm just surfing random sites and have even more tabs open. Very strange.

Don't know, but I had a slowdown on sites using google analytics.
Don't know if the google ads of the forumuse it.
I added this line to /etc/hosts:

Code: Select all

google-analytics.com 127.0.0.1

That should block it.

Concerning your /tmp issues, not shure either.
I think Puppy 202 did not yet use a Ramdisk for /tmp, so in that concern, there should be no trouble.
That can be found out by typing
df -m
There should be no line with /tmp and tmpfs in the same line.

If you have an external Linux Partition available, you could try this:
create there a folder /tmp
Then exit X, and mount it.
If it is on hda5, use such a command:
mount /mnt/hda5/tmp /tmp

In Puppy 202 an older Kernel is used, what might cause more bugs in Unionfs (as it is an older version).
By mounting /tmp on an external partition, unionfs is no longer used for that folder, what might give you more stability.

Mark

[Yogi]

Used Mean Puppy w/Opera tonite and noticed Opera slowing down again. Was able to close it before it crashed but it wouldn't re-open. Tried to open KP to see/kill whatever process was at fault but even KP would not open. I've had this behavior happen before. So I used rxvt to try and open these programs and this is what I got:

sh-3.1# kp
Error in startup script: couldn't create error file for command: no space left on device
while executing
"open $cmd r"
(procedure "scan_proc" line 14)
invoked from within
"scan_proc"
(file "/usr/sbin/kp" line 298)
sh-3.1# opera
opera: Module initialization failure. No memory to complete operation (-2)
sh-3.1# df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 3 3 0 90% /initrd
/dev/hda4 107253 86896 14909 85% /initrd/mnt/dev_save
/dev/loop0 48 48 0 100% /initrd/pup_ro2
/dev/loop1 124 44 73 38% /initrd/pup_rw
none 171 92 73 56% /
s

Notice the "no space left on device" error message. I'm positive this is the key to Opera's poor performance and problems in Mean Puppy. But I don't know why. I have to reboot to restore everything but in less than an hour (or 30 minutes even) Opera is crawling/crashing again. I'm posting this from Dillo.

[Yogi]

Addendum:

Mark,

I just tried altering my /etc/hosts and it wouldn't. So tried an end around by copying the hosts file first and then altering it and look what I got:

Copying /etc/hosts as /etc/host~
cp: cannot create regular file '/etc/hosts~': No space left on device
Failed to copy '/etc/hosts'
Done
There was one error.

"No space left on device", again!
What am I missing? I have enough ram so what device is this error message refering to?

[MU]

I am still testing the issues.

Current status:
I still have crashes after a while.
But they are less seldom.
Also now, they are less severe.

Situations:
Old: (unaltered Cache-folders) Firefox freezed.
The whole filesystem freezed, so also Rox-Filer.
I sometimes could open an rxvt, but that freezed, too (parsing /etc/profile maybe)

New: (Cache-folders symlinked to /tmp) Firefox freezed.
Filesystem is accessable, except when I try to access /root/.mozilla.
If I try that, the filemanagers freeze.
This usually happens,If I start other Ram-intensive applications, like Gimp or Seamonkey Composer.

Very new: (Cache-folders symlinked to /tmp)
All these tests were done using a 106 MB msy_083.sfs (pup_301.sfs).
Firefox itself was not included, but in an additional addons_083.sfs, mounted via bootmanager.
I now created ONE big msy_083.sfs (pup_301.sfs), it is 600 MB in size, and includes all except the Kernelmodules (zdrv_301.sfs).

Now I can open Firefox, Gimp, Seamonkey Composer, Opera...
I even can run mksquashfs (100% CPU-Usage) at the same time - no crash/freeze yet!

Conclusion:
I have to overthink under these conditions, if it makes sense to release a "mini + addons".
If the addons run unstable, there is no sense in gaining some advantage from running a small base-system in Ram.

I'll keep you informed...

Mark

[MU]

darn, my conclusion was too quick.
After 1 1/2 hours, I have the same error as described in new.
It is not possible to start firefox again without reboot.

"ps" shows me:

Code: Select all

20608 root       2988 SW  /bin/sh /usr/local/bin/defaultbrowser 
20610 root       2988 SW  /bin/sh /usr/local/bin/firefox 
20611 root       3020 SW  /bin/sh ./firefox 
20614 root       3052 SW  /bin/sh ./run-mozilla.sh ./firefox-bin 
20619 root            Z   [firefox-bin]

So firefox has become a zombie process, blocking something.
/root/.mozilla is not accessable.
I post this now using Opera, that works so far.

Mark

[MU]

I think I could sort out the reasons for the crashes.

Muppy included /root/.mozilla/ with some default-settings.
So it was "Write-protected" in the SFS-files.
Unionfs had trouble in managing this, as the browsers store there tons of files.

I now did this:
In the SFS, this folder no longer exists.
Instead, when you run Puppy, it will extract them from an archive.
So they exist ONLY in pup_save.2fs.
It seems, that now unionfs can handle the writes.

I encountered problems, implementing this.
If I extracted the archive from /etc/rc.d/rc.local or /root/.xinitrc, again, Unionfs was confused.
Sometimes no desktop started.
Sometimes, Rox lost the pinboard.
I finally added the extraction-script to my /root/autostart, that is executed with some seconds of delay, after the Desktop started.
After testing for several hours in Standard and Mini, I encountered no crashes so far.
My extraccted /root/.mozilla still uses my symlinks to /tmp, but this might no longer be required.
I will not check that any more, as the current solution seems to work fine.
And /tmp assures, that the Caches are deleted at reboot or when X restarts.

Mark

[MU]

It now took 4.30 hours using Mini+addon to freeze Firefox.
I had many, many programs opened, copied some Gigabyte, uploaded a lot, mounted files using loop-devices, so the machine was heavily treated.
For the moment I have no further idea.
Lets hope, that Firefox 3 behaves differently.

For the moment I must live with that error, or use Opera.

Mark

[MU]

when I powered off the computer, Unionfs told me this:
there was a "branch error" with Firefox.
A deleted entry about xyz.gif, that was deleted before.

From Minisys we know, that Unionfs sometimes thinks, that there is a file, though it was deleted. You then get the request, if it shall be overwritten.
It seems, that firefox can not handle this confusing situation, and turns into a zombie.

Mark