I just ran into a disk space problem, where the disk space was getting used up faster than I could remove things. After booting into another install, and searching for large files I found /home/dave/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.log using 13G on a 32GB filesystem. There are a lot of lines in the file such as 22:38:20 Reference to page with free remap dp = 14992, remap = 14992 $ grep 22:38:20 soprano-virtuoso.log|wc -l 125994 Two problems. First what is the cause of the error message. Second, why is it generating over 100,000 copies of the message, per second. I've disabled nepomuk for now, to keep the system usable.
Changing the srpm, as lsof showed it was virtuso-t writing the file.
Source RPM: soprano-2.7.5-1.mga2.src.rpm => virtuoso-opensource-6.1.4-2.mga2.src.rpm
CC: (none) => balcaen.john, fundawang, nicolas.lecureuil
Adding the upstream bug report url.
URL: (none) => https://bugs.kde.org/show_bug.cgi?id=264465
I'm not sure if this is the same thing, but I'm seeing exactly the same thing, but with a different file. In my case, all of the nepomuk messages are going to /home/(user)/.cache/gdm/session.log. But, as in your case, it fills the partition to the tune of about 13GB. This was on a freshly-installed system with the userid involved logged-in. It took a while to track down where the space was being used, as du doesn't honor -x in a particularly useful way, and "du -s *" ignores hidden files like .cache. Nepomuk-stub-server eventually segfaulted and put up a KDE bug-report dialog. I've left it up and will get the details tomorrow. In the meantime, I'm attaching a fragment of the session.log. I had to truncate the original file to 0 to get the system operational, but before doing so, I did a tail -f to get the fragment. The lines are exceedingly long, and the 10 lines total about 201K. The target system is still using the same boot on which nepomuk-stub-server segfaulted, and the truncated file is not being written to. But I suspect that if I reboot the system, nepomuk will start up again and start writing data. I'll see tomorrow.
CC: (none) => ftg
Created attachment 3317 [details] .cache/gdm/session.log
Created attachment 3319 [details] KDE crash report for nepomuk-stub-server
This behavior resumes with each logout/login: [ftg@ftgme2 ~]$ cd .cache/gdm [ftg@ftgme2 gdm]$ ls -l -rw------- 1 ftg ftg 88863 Jan 6 09:04 session.log [ftg@ftgme2 gdm]$ ls -l total 92 -rw------- 1 ftg ftg 91480 Jan 6 09:07 session.log [ftg@ftgme2 gdm]$ ls -l total 52264 -rw------- 1 ftg ftg 53516480 Jan 6 10:42 session.log The file has grown to 53M in less that two hours of login time.
Still valid?
CC: (none) => nic
I don't think so. I haven't seen it in recent installs, the program virtuso-t is not in the Mageia 4 repos, and the upstream report has been closed as unmaintained. I'll close the bug as old. Frank, if you do see it again, please either reopen this bug report, or open a new one.
Status: NEW => RESOLVEDResolution: (none) => OLD