Announcement

Collapse
No announcement yet.

Soprano or Nepumuk spamming ~/.xsession-errors when dis-abled

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

    Soprano or Nepumuk spamming ~/.xsession-errors when dis-abled

    I was trying to figure out why my system won't shutdown or reboot since I installed Precise and discovered my ~/.xsession-errors file was huge (70mb) and being constantly spammed by activitymanagerd. Stumbled upon this bug blaming kactivitymanager so I killed it (honestly, I haven't figured out what the activities things is even for. I can't see a need for it). This resulted in the exact same errors now being reported as from /usr/bin/kfilemetadatareader which is not an active process. Apparently if you enable nepomuk, this goes away. So, current Precise will be painfully slow either because of the Semantic desktop thing (which I don't need) or from continual error reporting.

    Any ideas on how to squash this for the time being? It's making my log-in slow and using up disk space (and time) for useless reporting.

    SIDEBAR: I noticed an unexpected behavior. I was trying to view my .xsession.errors file but it kept being spammed to, thus making me reload or ignore the changes every few seconds (using kate) so I moved the file to xsession.errors (unhidden). What I expected was that a new .xsession.errors file would be created - WRONG! The error reporting followed the file! I even renamed it again to "old-errors" with the same results. I then copied the file and deleted old-errors. This ended the reporting totally - at least to anyway in my home directory. I suspect the messages are going somewhere, but I haven't a clue where. Whatever is actually causing it is not obvious since I have disabled everything referred to in the error.

    Please Read Me

    #2
    I think there are similar threads here on KFN, but some ideas at http://ubuntuforums.org/showthread.php?t=1517991

    Comment


      #3
      Yep, I see it. Sometimes strigi just needs to run the initial indexing to completion, then it settles down and stops sucking resources. I don't know whether one of these other processes is now compounding the strigi problem, or what. Honestly it all smells like a large reversion to about 2009.

      Comment

      Working...
      X