X-Slacko-4.4 with Xfce

[Mike Walsh]

Hiya, Geoff.

Thanks for that suggestion. I'll give that a try, too!

Just like me to be using the older version of XFCE with all the buggy behaviour, ain't it? (*sheesh*)

However, aside from this one annoying little thing, I really like 2.3.2. Runs a treat on ye ancient Dell, it surey does.

Let me pick your brains for a second, if I may? (I'm pretty sure I know the answer to this one.....but I'll ask, anyway.)

Is there any possibility a save-folder from 2.3.2 would run with 3.0?

No biggie if it won't; just curious, that's all.


Mike.

[Mike Walsh]

@Marv

Tried X-slacko on my dual core pae lappy and it seems the same as with windows, fan stays on low speed.

Tried X-slacko-non-pae on my pentium M-1.5, fan starts on high then throttles to low and eventually shuts off at idle.

A reply to a very old post (3 1/2 yrs!)

X-Slacko 2.3.2 on a 14 yr old Dell Inspiron lappie with a P4; this has had the latest BIOS upgrade in order to max the shared video RAM, as per 01micko's instructions for using the 'i915.modeset=0' kernel-line parameter for the Intel 82845 graphics chip (dreadful thing; but when it works, it gives an absolutely pin-sharp display..!)

Fan starts off at full-speed; after about 15 seconds, cuts back to low, then throttles off completely. Cuts in & out on low during usage; only time it goes on to high is when I'm running apps under WINE. Par for the course, really.....I'm happy with that.

(Remember, the earlier P4's didn't have the SpeedStep technology...not until Intel introduced the HT models.)


Mike.

[Geoffrey]

Hiya, Geoff.

Thanks for that suggestion. I'll give that a try, too!

Just like me to be using the older version of XFCE with all the buggy behaviour, ain't it? (*sheesh*)

However, aside from this one annoying little thing, I really like 2.3.2. Runs a treat on ye ancient Dell, it surey does.

Let me pick your brains for a second, if I may? (I'm pretty sure I know the answer to this one.....but I'll ask, anyway.)

Is there any possibility a save-folder from 2.3.2 would run with 3.0?

No biggie if it won't; just curious, that's all.


Mike.

I really couldn't say Mike, version 3.0 was updated to slacko-6 (5.9.3 beta2) and has xfce 4.12 so that's a bonus

change log says

3.0
---
fix gvfs-ftp
fix pac-tools
fix xfce4-appearance-wrapper
update remasterpup2
update shutdownconfig
update to bash-4.3.39
update to dbus-1.8.16
update to dbus-glib-0.104
update to firefox-31.7.0esr
update to kernel 3.14.20
update to mtpaint-3.44.93
update to openssl-1.0.2a
update to pburn-4.3.14
update to PPM2
update to slacko-6 (5.9.3 beta2)
update to wget-1.16.3
update to XFCE-4.12.x
update to yad-0.28.1


2.3.2
-----
fix fixmenus
fix icon_switcher

[Mike Walsh]

Morning, all.

Got another interesting one here...!

@Geoff:- D'you remember a while back, when I first installed X-Slacko? I wanted the weather plugin for the panel; tried the one from the repo (which kept trying to restart itself).....and you advised me to use the Carolina one.....which worked perfectly.

I've just installed X-Precise 2.4. Everything was going swimmingly. I'd been tweaking quite happily for about 2 1/2 hours or so, when for no apparent reason, every single item on the panel (with the exception of the Whisker Menu) pulled exactly the same stunt. Crashed, tried to restart, and I got the same window umpteen times for each item.

'X has unexpectedly left the panel. Do you want to restart it (blah, blah, blah...)'

Is there a Carolina 'fix' for the entire panel? Or is this indicative of a more serious underlying problem? Because I installed X-Precise to a thumb-drive a few months back (this time, it's on the external Seagate); first time round, I never had this problem..!

Okay, I admit I just did a 'quick'n'dirty' install this time, instead of faffing around with the PUI; copied the ISO contents across, and ran Grub4DOS. Always works.

Everything else is working perfectly.....it's just the damn panel! You can work without it; but it's a bit awkward..... Oh, and adding a new panel doesn't make a scrap of difference; the instant you try to add anything to it, it's crashing straight away.

Any thoughts?


Mike.

[Moat]

Howdy, Mike -

Something along these lines, perhaps (with suitable modifications, of course)?

Code: Select all

$ pkill gvfs-metadata
$ rm -rf ~/.local/share/gvfs-metadata
$ pkill gvfs-metadata

Pretty dern close - I'm running with this below, and with one eye on the task manager and the other on the /root/.local/share/gvfs-metadata directory, it appears to do the trick;

Code: Select all

#!/bin/sh

pkill gvfsd-metadata

sleep 5 && rm -rf /root/.local/share/gvfs-metadata

Notice the 'd' in 'gvfsd-metadata' - at least that's the runaway process here on X-Tahr 2.0, AFAICT (hasn't acted up lately).

All's left to then do is drop the shellscript in /usr/bin, make a .desktop file for it in /usr/share/applications, and find a nice, fitting icon to point the .desktop file to. That'll give me quick access to it via menu or panel launcher/button.

Bob

[Marv]

Howdy, Mike -

Something along these lines, perhaps (with suitable modifications, of course)?

Code: Select all

$ pkill gvfs-metadata
$ rm -rf ~/.local/share/gvfs-metadata
$ pkill gvfs-metadata

Pretty dern close - I'm running with this below, and with one eye on the task manager and the other on the /root/.local/share/gvfs-metadata directory, it appears to do the trick;

Code: Select all

#!/bin/sh

pkill gvfsd-metadata

sleep 5 && rm -rf /root/.local/share/gvfs-metadata

Notice the 'd' in 'gvfsd-metadata' - at least that's the runaway process here on X-Tahr 2.0, AFAICT (hasn't acted up lately).

All's left to then do is drop the shellscript in /usr/bin, make a .desktop file for it in /usr/share/applications, and find a nice, fitting icon to point the .desktop file to. That'll give me quick access to it via menu or panel launcher/button.

Bob

Hi Moat,
Just for giggles, I tried running the kill script as a crond process every 10 minutes on one of my most troubled Pentium Ms where I previously had to disable gvfsd. On my laptops I have it set up as a .desktop for my own use now and can tell when to hit the button but that laptop is a users and overall the cpu racing/lockup just caused heart palpitations there. Shades of windows! Or rude! Using a daemon to control a daemon. So far it has been working. No addl. overhead observable and the time crosssection/intersection seems low enough so nothing has shown up yet in apps that I know use gvfs. Don't try this in your Out house

[Geoffrey]

Morning, all.

Got another interesting one here...!

@Geoff:- D'you remember a while back, when I first installed X-Slacko? I wanted the weather plugin for the panel; tried the one from the repo (which kept trying to restart itself).....and you advised me to use the Carolina one.....which worked perfectly.

I've just installed X-Precise 2.4. Everything was going swimmingly. I'd been tweaking quite happily for about 2 1/2 hours or so, when for no apparent reason, every single item on the panel (with the exception of the Whisker Menu) pulled exactly the same stunt. Crashed, tried to restart, and I got the same window umpteen times for each item.

'X has unexpectedly left the panel. Do you want to restart it (blah, blah, blah...)'

Is there a Carolina 'fix' for the entire panel? Or is this indicative of a more serious underlying problem? Because I installed X-Precise to a thumb-drive a few months back (this time, it's on the external Seagate); first time round, I never had this problem..!

Okay, I admit I just did a 'quick'n'dirty' install this time, instead of faffing around with the PUI; copied the ISO contents across, and ran Grub4DOS. Always works.

Everything else is working perfectly.....it's just the damn panel! You can work without it; but it's a bit awkward..... Oh, and adding a new panel doesn't make a scrap of difference; the instant you try to add anything to it, it's crashing straight away.

Any thoughts?


Mike.

Sounds like a dependency that's common to all the plugins maybe the problem, starting from scratch might be the best choice.

[Moat]

Hey Marv, running it as a cron job - now there's an idea.

Using a daemon to control a daemon. So far it has been working.

My only fear would be it inadvertently triggering right in the middle of it's (seemingly rare?!) doing something useful/intended. Let us know if any issues crop up as time goes by, using that method.

It's an intrusive, obnoxious bugger, even on my very recent Mint 18.1 Mate laptop install - where it fires off every single time I open Synaptic, peaking one CPU core for about a minute, then settling back down/disappearing. Only fires about once or twice a week on my older Mint Mate 17.1 install. Gettin' even buggerer, it seems!

Bob

[Marv]

@Moat,
I thought about the possibility of just that interaction and decided to just have a go at it, goofy as it is. I was at the farm where that Pentium M lappie lives today and the Bay Trail box there (running 3b5 for a long time now utterly trouble free rg66 ) was nagging about a full savefile. All of the user storage is symlinked to external locations so I had a look. 200Mb of cruft in /root/.cache and the gvfsd directory. Some browsers are good about cleanup if properly set, some aren't and if they are just left open... Cleaned house, added a /root/.cache cleaner line to the kill file and installed it there also. It's not a mission critical box (one of 3 pup setups there) and Kevin is pretty clear about explaining any probs so.... I'm setting up a new printer there also so I can mother hen a bit if needed. We'll see.

Edit: I'm now checking the size of .cache when the script runs and only cleaning if it is over say 10 or 20 Mb. Not sure of the exact size but I think in general that's neater. Could do the same for the gvfs directory. I know it's hard to say but have you ever seen a runaway with only a few files in that dir?

Edit2: Have it as a pet now. Adds needed files for crond start to X- series pups and sizechecks cache but not gvfs. Running on X-slacko 4.2, X-Tahr 2.0 and LxPupSc 17.021 for now on Pentium M, core 2 duo lappies and Bay Trail desktop. Still 'seeing'.

Jim

[Marv]

Hey Marv, running it as a cron job - now there's an idea.

Using a daemon to control a daemon. So far it has been working.

My only fear would be it inadvertently triggering right in the middle of it's (seemingly rare?!) doing something useful/intended. Let us know if any issues crop up as time goes by, using that method.

It's an intrusive, obnoxious bugger, even on my very recent Mint 18.1 Mate laptop install - where it fires off every single time I open Synaptic, peaking one CPU core for about a minute, then settling back down/disappearing. Only fires about once or twice a week on my older Mint Mate 17.1 install. Gettin' even buggerer, it seems!

Bob

Four days up and ok so far. Did an hourlong unsquash/HC resquash on the Pentium M wiithout any problems -highly unusual-, lots of access of PDF files on my remote storage -evince uses the gvfs-metadata for sure-, just normal daily use web browsing & editing. Mostly on X-slacko 4.2 and X-Tahr 2.0 as that is where I see the runaways most. I'll attach what I use as a pet. First cut, has a splash for diagnostics, has the files and pinst for the X- series pups. So far works here. Mostly so you can extract it and see what I've done. The 10 minute interval was just my first thought, often enough so I could see it work but not bug me. Again, rude but so is the gvfs bugger.

Jim

[Moat]

Awesome, Marv! Great to hear the reports of no issues so far, four days in and running every 10 minutes. Downloaded your .pet, and will have a look at your handiwork.

I haven't observed the anomaly often enough to determine how many/how big/which type/etc. of files are present in /.local/share/gvfs-metadata when things go all wonky - would be nice to suss that one out, tho... IF one had some solid data regarding the above, some coder who's smarter than me could create a little script that does something such as periodically grep (?) the number/size/type/etc. of /.local/share/gvfs-metadata's contents and if above some relevant value... cleans things up (maybe retaining the few, latest and most important bits? Whatever those may be...).

Good stuff, Marv!

Bob

[Marv]

Hi Moat, Originally in the script I did test both the size of the .cache and the gvfs-metadata directories and only deleted and killed gvfsd if that dir was over a threshold. Ran that way and without the size test and really couldn't see a difference. For now, I'm only using a size threshhold on the .cache directory in the script. Simple to add the gvfs size test back in but as you point out, how much or big is bad? I also have a ver 1.1 that tests for and only adds the crond files if they are missing (they are already in the newer LxScPups etc.) so it is more general.

Jim

[Mike Walsh]

Hiya, Marv.

Now, then. How good is this .pet of yours.....and would you mind awfully explaining what's actually going on when it runs, please? I ask, because I'm re-discovering quite a taste for XFCE, long after my Xubuntu days..! In addition to X-Slacko 2.3.2 (with the XFCE 4.10 desktop), I've just recently installed X-Tahr 2.0; I've always got on very well with Tahr (stable as they come).....and I've been following the last few day's-worth of posts with interest.

I, too, have noticed the CPU performance going lairy....especially after installing any sizeable application. Is this kinda 'normal' behaviour we're seeing here.....or is it simply an as yet unfettled 'bug' in the current release of the XFCE/Thunar combo?

Whaddy'all think of it so far?





This is a USB install, with the menu.lst's kernel-line modified with the 'i915.modeset=0' parameter so's I can run it with the old Dell lappie's ancient Intel graphics, or the big Compaq as the fancy takes me.

It's got Grub4DOS installed to the drive itself, and I've added it to each machine's main Grub4DOS menu, too.....so they can pick it up without having to go into the BIOS and/or one-off boot menu.

I'm all for an easy life, me..!


Mike.

[Marv]

Hi Mike,
Can't say how good it is in the grand scheme, but it seems to solve a longstanding problem for me.

Basically the problem is that periodically the gnome virtual file system daemon, gvfsd-metadata, can't write sucessfully to its directory /root/.local/share/gvfs-metadata and goes into a tight loop and CPU use skyrockets, not uncommon to see 100%. When you suspect it, just open the task manager and look at the most CPU intensive processes. It's a long-standing problem across many (gnome based) OS.

It is a function of hardware, worse on my older machines than on the newer ones, of file/file size operations, and IMO of software age, much less a problem in the current LxPupSc for example.

What the pet does is start crond, a task scheduling daemon, installing the start files in the X-series pups but not in the newer LxPups as they are already there (ver 1.1 of the pet). A script, gvfsd_kill.sh is then scheduled to run every 10 minutes (my arb choice). It does two things. Stop the gvfsd-metadata daemon (wait til stopped, typically less than 100 ms) and empty its directory. The capability is there (again in 1.1) to only do the operation if the size of the dir is greater than xxMb. As a bonus, it checks /root/.cache size and empties it if it is greater than 10Mb (again my arb choice). crond is a busybox process and is present and tested with this in X-slacko 4.2, X-Tahr 2.0 and LxPupSc by me. Should be ok in most pups.

For context, the high CPU use by gvfs is my number 2 phone call after 'my cd/dvd doesn't play when I put it in' so for me it is an issue. May not be for everybody. As Moat and I have discussed above and elsewhere there is certainly a possibility for an interaction but the cross-section seems low. I haven't seen it now in 4 or 5 days on 4 or 5 machines up 24h with a variety of uses.

Whew,

Edit: ver 1.11 uploaded above. Same function, fixes a whiteout problem on removal and avoids using /tmp, cleaner uninstall.

Jim

[Mike Walsh]

Mornin', Marv.

Thanks for the explanation. I'll give it a go. Currently I'm restarting X every time it happens....which is a pain in the..... !!

Talking of which, what's going on here? Every time I boot into X-Tahr, my desktop icons are all 'arranged' over on the far left-hand side. I seem to recall XFCE in Xubuntu had an option to 'lock' the desktop.....but Pup doesn't appear to have it.

So what's the answer? X-Slacko 2.3.2 doesn't do this; I've never had the problem with it. I know it's an older version of XFCE, true, but even so.....

It's annoying!!!


Mike.

[Marv]

Mornin', Marv.

Thanks for the explanation. I'll give it a go. Currently I'm restarting X every time it happens....which is a pain in the..... !!

Talking of which, what's going on here? Every time I boot into X-Tahr, my desktop icons are all 'arranged' over on the far left-hand side. I seem to recall XFCE in Xubuntu had an option to 'lock' the desktop.....but Pup doesn't appear to have it.

So what's the answer? X-Slacko 2.3.2 doesn't do this; I've never had the problem with it. I know it's an older version of XFCE, true, but even so.....

It's annoying!!!


Mike.

The pet also installs a .desktop , gvfsd_clean, which calls the kill script. Add it to a panel and it kills without restarting X. To disable the scheduled task once the pet is installed just use the boot manager>services to turn off crond. Or just copy and paste the .desktop and script from the pet.

Next time I boot into X-Tahr I'll look at the icons. I pretty much run with an empty desktop so I never thought about it.

Edit: Version 1.12 above uses file number and size tests, logs to gvfsd_log in /tmp, gives immediate mode (.desktop) over-ride precedence, and (I hope) uninstalls better to accomodate other crond tasks pre-existing in pups that have crond enabled while still installing the needed crond files in those pups that don't have them.

Edit: Booted into both X-Tahr 2.0 and X-slacko 4.2 as part of the work above and while there deliberately spewed my icons about on the desktop. Drives, folders, trash, and a launcher or two. Restarted X, rebooted, and the repositions stuck FOR A WHILE, then reverted to the left. So no help on that. Running bog standard Grub4Dos frugal install with smallish (256Mb) EXT2 savefiles. The icon positions are saved at root/.config/xfce4/desktop/, don't know where the call to use that is though. The odd thing is that I know they were still spewed for a time because I started writing this (Opera, fullscreen), then checked again and they had reverted. ???

Jim

[Mike Walsh]

Hiya, Marv.

Well, your .pet is the mutt's nuts, mate. I installed it in X-Tahr yesterday, and haven't had a single instance of the CPU going bonkers since! Done quite a bit of file-transfer stuff in that time-frame (over the network, as well).....and everything's purring like a kitten. Smooth as so much oiled silk.

Nice one. Cheers!

----------------------------------------------------

As for the desktop icons; I gave 'em up as a bad job. I don't know what's going on there myself, but I've ended up using a second panel as a launcher bar. They seem to be behaving themselves on there..!


Mike.

[Marv]

Thanks Mike, I've been using it on all my laptops now and haven't had any runaways either. Since it logs, and I've been flogging several of the machines installing new printers and putting a newer laptop in service in place of one of the Pentium Ms, I have a better idea how the load builds and have an alternate script that is even more selective. It checks for time since file creation (modification actually) in both the cache and gvfs directory and uses that information as well as size to decide when to kill/clean. The immediate mode still exists from the .desktop. No changes at all to the structure of the 1.12 pet, just the gvsd_kill.sh script in /usr/sbin. I'll gzip just the script and attach it below for a look-see. I think it's pretty self explanatory.

[Mike Walsh]

Morning, Marv.

Thanks for that. I'm in 571 at the moment, but I'll do the swap in X-Tahr later today, and see how it goes. I'll keep you updated along the way.

Cheers.


Mike.

[Marv]

Fixed a misplaced " in the kill file 2 posts up, next to last line. Re-uploaded, sorry. Happened when I added cache info to the logfile.