[PC-BSD Testing] Dolphin bug
doverosx at gmail.com
doverosx at gmail.com
Tue Jan 5 14:29:26 PST 2010
Arthur Koziol wrote:
> On 01/05/2010 4:01 PM, Kris Moore wrote:
>
>> On 01/05/2010 11:39, doverosx at gmail.com wrote:
>>
>>
>>> Kris Moore wrote:
>>>
>>>
>>>> On 01/05/2010 11:06, doverosx at gmail.com wrote:
>>>>
>>>>
>>>>
>>>>> Kris Moore wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 01/05/2010 11:01, doverosx at gmail.com wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Kris Moore wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 01/05/2010 14:55, Kris Moore wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 01/05/2010 14:14, doverosx at gmail.com wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> ...continued from "Dictionary issues again?" which were caused by /tmp
>>>>>>>>>> being used improperly.
>>>>>>>>>>
>>>>>>>>>> Various dmesg, df -h and sysctl vm.vmtotal outputs:
>>>>>>>>>>
>>>>>>>>>> /********** DMESG *********/
>>>>>>>>>> kern.maxfiles limit exceeded by uid 1001, please see tuning(7).
>>>>>>>>>> kern.maxfiles limit exceeded by uid 1001, please see tuning(7).
>>>>>>>>>> kern.maxfiles limit exceeded by uid 1001, please see tuning(7).
>>>>>>>>>> kern.maxfiles limit exceeded by uid 1001, please see tuning(7).
>>>>>>>>>> kern.maxfiles limit exceeded by uid 1001, please see tuning(7).
>>>>>>>>>> pid 52607 (kdeinit4), uid 1001 inumber 70671 on /tmp: filesystem full
>>>>>>>>>> pid 44850 (firefox-bin), uid 1001 inumber 6 on /tmp: filesystem full
>>>>>>>>>> pid 44850 (firefox-bin), uid 1001 inumber 6 on /tmp: filesystem full
>>>>>>>>>> pid 28813 (npviewer.bin), uid 1001: exited on signal 11
>>>>>>>>>>
>>>>>>>>>> *This is from the dictionary issues dmesg output and not the SMB
>>>>>>>>>> specific usage of dmesg*
>>>>>>>>>>
>>>>>>>>>> *******************************************************************************
>>>>>>>>>> During 800MB transfer, Plasma space "could not read file"
>>>>>>>>>>
>>>>>>>>>> [brodey at pcbsd]/home/brodey(120)% ls -l /tmp
>>>>>>>>>> total 6
>>>>>>>>>> drwx------ 2 brodey wheel 1024 Jan 5 13:54 kde-brodey
>>>>>>>>>> drwx------ 2 root wheel 512 Jan 5 13:27 kde-root
>>>>>>>>>> drwx------ 2 brodey wheel 512 Jan 5 13:55 ksocket-brode
>>>>>>>>>> [brodey at pcbsd]/home/brodey(121)% ls -l /tmp/kde-brodey/
>>>>>>>>>> total 605538
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:42 dolphinAy8161.tmp
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:44 dolphinHc8161.tmp
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:42 dolphinNv8161.tmp
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:54 dolphinRS8161.tmp
>>>>>>>>>> -rw-r--r-- 1 brodey wheel 107618884 Jan 5 13:56 dolphinRS8161.tmp.part
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:47 dolphinVH8161.tmp
>>>>>>>>>> -rw-r--r-- 1 brodey wheel 134364212 Jan 5 13:52 dolphinVH8161.tmp.part
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:47 dolphinVg8161.tmp
>>>>>>>>>> -rw-r--r-- 1 brodey wheel 134020904 Jan 5 13:52 dolphinVg8161.tmp.part
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:44 dolphinYZ8161.tmp
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:54 dolphinZL8161.tmp
>>>>>>>>>> -rw-r--r-- 1 brodey wheel 109270032 Jan 5 13:56 dolphinZL8161.tmp.part
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:47 dolphiner8161.tmp
>>>>>>>>>> -rw-r--r-- 1 brodey wheel 134364212 Jan 5 13:52 dolphiner8161.tmp.part
>>>>>>>>>> -rw------- 1 brodey wheel 0 Jan 5 13:44 dolphinfH8161.tmp
>>>>>>>>>> -rw------- 1 brodey wheel 1406 Jan 5 13:37 systemsettingsff5492.tmp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Ok, we may have found the issue here. Dolphin uses /tmp by default for
>>>>>>>>> file copy jobs, and when that fills up, you're sunk, as you've seen :P
>>>>>>>>>
>>>>>>>>> However, we've been limiting tmpfs to 800MB, and if we remove that, it
>>>>>>>>> should allow you to use much more space when doing large transfers. Give
>>>>>>>>> this a shot, in /etc/rc.conf look for these lines:
>>>>>>>>>
>>>>>>>>> # tmpmfs Flags
>>>>>>>>> tmpmfs="YES"
>>>>>>>>> tmpsize="800m"
>>>>>>>>> tmpmfs_flags="-S"
>>>>>>>>> clear_tmp="YES"
>>>>>>>>>
>>>>>>>>> Remove the tmpsize= and tmpmfs_flags= lines, and reboot. Then try to
>>>>>>>>> copy again, does /tmp fill up as quickly and die?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Actually scratch that last, try this instead:
>>>>>>>>
>>>>>>>> comment out all tmpfs stuff in /etc/rc.conf
>>>>>>>>
>>>>>>>> Add this line to /etc/fstab
>>>>>>>> tmpfs /tmp tmpfs
>>>>>>>> rw,mode=1777 0 0
>>>>>>>>
>>>>>>>> Reboot, and run df -h, does /tmp show up with much more space available now?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> I will scrap tmpfs stuff from rc.conf and test now. Transferring files
>>>>>>> worked without the flags but 19MB is clearly too small ;). Do you mean
>>>>>>> tmpmfs in fstab?
>>>>>>>
>>>>>>> Brodey
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Yea, I would go ahead and disable tmpfs lines in rc.conf entirely, and
>>>>>> add the /etc/fstab line I specified above. That seems to work fine on my
>>>>>> system here, shows /tmp has having all my RAM + Swap space size
>>>>>> available to work with.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> yeahh...tmpfs it is! 6.9GB available. Though, cleartemp option sounds
>>>>> like a good idea to keep around (?)
>>>>>
>>>>>
>>>>>
>>>> Great!! I'm not sure the cleatmp option is required though, since tmpfs
>>>> already gets blown away / recreated when you restart anyway :)
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Removing places, "preview this file.." service hasn't done anything to
>>> fix up the issue. I will try removing the "Information" feature right now.
>>>
>>> As an aside, when transferring files to/fro my FreeNAS box I reach
>>> 2.0+MiB/s but the info box is only a few hundred KB. That darn forum
>>> thread is exactly what I'm going through!
>>> _______________________________________________
>>>
>>>
>> Well, it sounds like you've been able to isolate a nice Dolphin bug :)
>>
>> I would check bugs.kde.org and see if any of the guys from the forum
>> posts reported it yet. If not, go ahead and open a new bug up there so
>> we can get it resolved right away.
>>
>>
>>
> There are rumblings of a 4.3.5 release so if this gets submitted, maybe
> it'll make it in.
>
> Arthur
> _______________________________________________
> Testing mailing list
> Testing at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/testing
>
>
https://bugs.kde.org/show_bug.cgi?id=221455
Bug report created!
More information about the Testing
mailing list