Announcement

Collapse
No announcement yet.

Anybody has a giant /var/tmp/kdecache-(user name)?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Anybody has a giant /var/tmp/kdecache-(user name)?

    Noticed that free disk space on Kubuntu partition was dwindling quickly. It turned out, that folder was over 2GB in size. I was wondering if this was due to recent upgrade to 4.7.4? Does anybody observes something similar?
    Ok, got it: Ashes come from burning.

    #2
    KDE Forum / kdecache is huge, for God's sake! : http://forum.kde.org/viewtopic.php?f=22&t=96677

    Bug 190209 - /var/tmp/kdecache-USER/kpc grows to enormous size (+150MB for each plasma theme tried) : http://bugs.kde.org/show_bug.cgi?id=190209

    Bug 283921 - Switching/customising desktop themes causes massive cache expansion : https://bugs.kde.org/show_bug.cgi?id=283921

    It is a cache - you could clean it.

    KDE Forum / What are the consequences if I delete KDE cache files: http://forum.kde.org/viewtopic.php?f=66&t=89866

    KDE Forum / Accumulating data in kdecache/kpc folders. Erasable?: http://forum.kde.org/viewtopic.php?f=17&t=45909
    Last edited by OneLine; Feb 07, 2012, 05:19 PM.
    Have you tried ?

    - How to Ask a Question on the Internet and Get It Answered
    - How To Ask Questions The Smart Way

    Comment


      #3
      OK, thanks,

      I have already deleted all files there. Just not used to seeing such large files in previous versions. So a cron job could be handy here.
      Ok, got it: Ashes come from burning.

      Comment


        #4
        Is there any reason for stuff in /var/tmp to persist reboots? I haven't come across one. So I've configured both temporary directories to run in RAM disks. Reduces unnecessary wear on SSDs, perks up system performance a bit, and cuts down on bloat accumulation.

        My /etc/fstab:
        Code:
        # /etc/fstab: static file system information.
        #
        # Use 'blkid -o value -s UUID' to print the universally unique identifier
        # for a device; this may be used with UUID= as a more robust way to name
        # devices that works even if disks are added and removed. See fstab(5).
        #
        # <file system> <mount point>   <type>  <options>       <dump>  <pass>
        proc            /proc           proc    nodev,noexec,nosuid 0       0
        # / was on /dev/sda1 during installation
        UUID=3175f1e1-f320-496d-b32e-7c43d466c7f1 /               ext4    noatime,discard,data=writeback  0       1
        # swap was on /dev/sda2 during installation
        UUID=25a3c459-8fb3-4c3a-89ae-55f6bbe13934 none            swap    sw              0       0
        #
        tmpfs  /tmp      tmpfs  noatime,mode=1777  0 0
        tmpfs  /var/tmp  tmpfs  noatime,mode=1777  0 0
        To do this:

        1. sudo rm -rfv /tmp/*
        2. sudo rm -rfv /var/tmp/*
        3. Edit your /etc/fstab and add the two lines you see in the bottom of the one I posted above
        4. sudo mount -a

        Comment


          #5
          Originally posted by steveriley View Post
          Is there any reason for stuff in /var/tmp to persist reboots?
          That's meant to be the point of it over /tmp.... some programs rely on it being persistent storage across reboots, though I do not know what is actually being stored here ^^

          Comment


            #6
            Been running this way in Ubuntu for two years now, not noticed a problem...

            Comment


              #7
              AFAIK RHEL distros clean /var/tmp every 30 days by default. I suspect the contents of /var/tmp might make bootup or desktop loading a bit faster, but won't prevent booting.

              As I only boot when there's a new kernel or driver I need, I doubt it makes much difference to me. My typical uptime runs into weeks/months not minutes/hours like you laptop users... lol

              Please Read Me

              Comment


                #8
                Originally posted by oshunlulvr View Post
                My typical uptime runs into weeks/months not minutes/hours like you laptop users... lol
                My laptop generally has a higher uptime then my desktop, as I tend to turn my desktop off at night ^^ where as my laptop just sleeps

                Comment


                  #9
                  +1 on keeping all the temporary files in RAM. Let the system speed your stuff up, that's why you paid for the RAM. A basic example:
                  tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
                  tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
                  tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

                  Though /var/spool, /var/mail and stuff can go there as well. Gecko browsers can keep their cache in RAM too - about:config, create a string value for browser.cache.disk.parent_directory with /dev/shm/browsercache
                  Last edited by Guest; Feb 08, 2012, 07:18 AM.

                  Comment


                    #10
                    Originally posted by oshunlulvr View Post
                    AFAIK RHEL distros clean /var/tmp every 30 days by default. I suspect the contents of /var/tmp might make bootup or desktop loading a bit faster, but won't prevent booting.

                    As I only boot when there's a new kernel or driver I need, I doubt it makes much difference to me. My typical uptime runs into weeks/months not minutes/hours like you laptop users... lol
                    Got me there, James...

                    Please Read Me

                    Comment


                      #11
                      Originally posted by lo_koraco View Post
                      tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
                      Ah, the log directory...I prefer to keep that one on the hard drive. Makes diagnosing problems between reboots much easier. Plus, /var/log/apt/history.log is a useful thing to keep around.

                      Comment


                        #12
                        Good point. I usually make sure my machines run perfectly before I mount log into RAM.

                        Comment

                        Working...
                        X