Hi
This new machine I'm using sports a core i5 Skylake, and a hefty 16GB of RAM.
I noticed recently that right after startup, it's sometimes extremely slow, even for simple tasks such as opening caja.
Here's what my standard battery of indicators was showing during one such occurence:
(CPU, Memory, Network, Disk I/O)
Note that the disk activity is intensive and that a significant amount of CPU is used waiting for I/O too. (Dark blue stuff on the image)
I further installed iotop
and here's what it was showing:
It seems kind of abusive, I can't see this being intended behavior.
Any one else noticed something like this?
The system is Ubuntu MATE 16.04.1 with MATE 1.12.1
The whole ~/.cache/dconf/
is indeed only accessible by root.
I have three machines in that state, however.
The bug might have happened in the others without me noticing since those others machines all have SSD drives.
I was assuming that it was intended to be owned by root. Was I wrong? Can someone contribute who’s the owner on their systems?
( Please provide output of sudo ls -alh ~/.cache/dconf/
)
Thanks for your time, @anon42388993. :]
total 12K
drwx------ 2 root root 4.0K Aug 7 05:22 .
drwx------ 15 m1 m1 4.0K Sep 7 08:36 ..
-rw------- 1 root root 2 Aug 7 05:22 user
Edit:
Why are we in the uncategorized forum?
I'm almost sure I created this in support, but I'm very tired atm so it might be my fault.
I moved the thread to support.
1 Like
Okay, so...
I messed up. Bad.
For a while now I've been using sudo pluma to edit system files and the other day on IRC @Akuli kind of set me straight:
<bro_marc> guys, how to i make the grub menu appear on boot instead of this grey box?
<bro_marc> do*
<ouroumov_> hey bro_marc
<ouroumov_> bro_marc, you mean you can`t see grub menu items?
<bro_marc> i only get a grey box
<bro_marc> covering the whole screen
<ouroumov_> bro_marc: sudo pluma /etc/default/grub
<ouroumov_> Uncomment line 20 GRUB_TERMINAL=console
<ouroumov_> save, close, then: sudo update-grub
<bro_marc> alright, i'll try
* bro_marc (~marc@2a02:8108:45bf:c3f0:4d53:ac02:2124:2124) has quit (Remote host closed the connection)
<Akuli> ouroumov_, sudo nano or gksudo pluma, not sudo pluma
<nomic> pluma = gedit
<nomic> rite
<Akuli> yes nomic
<nomic> figured out that gedit didn't work anymore on mate
<ouroumov_> Akuli, are you saying that because it's a security issue Akuli ? Because it works.
<Akuli> ouroumov_, gui apps like to change ownership of stuff in your home folder to root when you run them with plain sudo
<ouroumov_> Seriously? Could that be the cause of ~/.config/cache being owned by root Akuli ?
<Akuli> yes
<ouroumov_> Holly damn.
<ouroumov_> Akuli, are you running Ubuntu MATE 16.04 ?
<Akuli> you can run `sudo chown -R $USER ~` if you have trouble with it :)
<Akuli> ouroumov_, devuan 8
<Akuli> an important note: both $USER and ~ are evaluated before the command is given to sudo
<Akuli> try this out: echo $USER ~
<ouroumov_> Damn, I'll need to test this
* skeletonkey ([email protected]) has quit (Quit: leaving)
<Akuli> i'm not actually sure how much truth there is in that ownership changing myth, but once some of my files were owned by root and some by me after running gui apps as root
<Akuli> with sudo
<ouroumov_> I'll have to check the permissions on a fresh install
<ouroumov_> If I've been recommending something dangerous to people that needs to stop.
<Akuli> i just use nano :)
<Akuli> anyone can learn it in just a few seconds, its so simple
<Akuli> awesome for quick config file editing stuff
This is definitively the cause of those files owned by root.
So yeah, I'm gonna chown those files back to my user on my machines, and never again tell to people to use sudo pluma.
2 Likes
Interesting and thanks for a heads up or I could easily be doing same.
I typically run gksu caja /
from a hotkey which appears to be ok opening scripts and confs with pluma. The sudo/gksu environments are obviously totally different.
So I removed those files owned by root.
I thought at first it had fixed it.
Turns out, no, it was just taking a while to start hammering.
I made a diff of lsof
output for mate-settings-daemon
before and during the runaway:
Then I took a peek at that directory, turns out it was host to a truckload of thumbnails that were produced as a result of the step to reproduce I made for the memory leak bug.
ouroumov@Bloc:~/.cache/thumbnails$ ls normal/ | wc
41442 41442 1533354
Those were all thumbnails for the images produced:
Apparently mate-settings-daemon is listing this directory on startup, and there does not appear to be a size limit.
@Wimpy, could a max number of thumbnails settings be added somewhere, or an arbitrary limit be enforced?
I have now rebooted, and I can confirm my system is back to his snappy self.
Thanks
1 Like