Re: Strange files, slow resopnse, evolution problem with recent updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2009-09-21 at 14:03 +0100, John Austin wrote:
> Hi
> 
> I have just returned from holiday and updated F11 to latest state
> Server Centos 5.3 also updated
> 
> There was no problem afaik before the upgrades !!!!
> 
> My F11 client uses kdm, xfce, evolution ...
> and my home directory is an nfs4 mount from the server
> 
> -------------------------------------------------------
> 1. My backup script fails - refusing to copy files of the type
> 
> cp: cannot open `/home/ja/.local/share/applications/defaults.list.3PEP0U' for reading: Permission denied
> 
> naxos ~ 78# ls -l /home/ja/.local/share/applications/defaults.list.I4ZS0U
> ---------- 1 ja sysadmin 0 1970-05-08 03:02 /home/ja/.local/share/applications/defaults.list.I4ZS0U
> 
> cp: cannot open `/home/ja/.kde/share/config/kconf_updaterc.lockGuIM8a.tmp' for reading: Permission denied
> 
> naxos ~ 87# ls -l /home/ja/.kde/share/config/kconf_updaterc.lockGuIM8a.tmp
> ---------- 1 ja sysadmin 0 1970-02-01 03:34 /home/ja/.kde/share/config/kconf_updaterc.lockGuIM8a.tmp
> 
> -------------------------------------------------------
> 
> With zero length and 000 permissions
> naxos ~ 86# find . -type f -size 0 -perm 000 |grep  ".kde/share/config/*" |wc
>   11336   11336  532781
> 
> Even more with just zero length
> naxos ~ 84# find . -type f -size 0 |grep  ".kde/share/config/*" |wc
>   23783   23783 1117791
> 
> The vast majority of the files are associated with kde !
> naxos ~ 5# ja_null_files_ls |wc -l
> 43087
> naxos ~ 6# ja_null_files_ls |grep .kde |wc -l
> 43008
> 
> There are a lot of these files in my home directory! 240,000 at one stage !!!!
> They take a very long time to delete
> 
> The dates are strange some being in years 1970 and some 2038
> 
> ############################################################
> Update
> My nfs4 mounted home directory is saved on a SSD disk
> with noatime set
> Removing the noatime seems to get rid of the 2038 dated file problem
> other problems described here are still present
> ############################################################
> 
> Why have these files appeared or have they always been there
> If so why does my simple cp now treat them differently
> 
> 
> 2. Evolution is now having great difficulty in reading/saving/deleting/filtering files
> 	Is this to do with problem 1 ?
> 	Also - when creating new message in evo a box pops up with
> Could not save to autosave file "".
> Error saving to autosave because "Could not open autosave file".
> 
> 3. Thunar has great difficulty in showing thumbnails
> and deselects thumbnails when changing directory
> pcmanfm seems to work OK
> 
> Is it a kde, nfs ... problem ?
> 
> Any suggestions welcome
> 
> John
> 
> --------------------------------------------------------------------------
> PS
> I have 4 little scripts to investigate with
> 
> For 1970 dated files 
> naxos ~ 1# cat bin/ja_null_files_ls
> #!/bin/bash
> find $HOME -type f -size 0  -mtime +10000 -print0 | xargs -0 ls -l
> --------------------------------------------------------------
> For 2038 dated files
> naxos ~ 2# cat bin/ja_null_files_ls_future
> #!/bin/bash
> find $HOME -type f -size 0  -newermt "2030-02-01"  -print0 | xargs -0 ls -l
> --------------------------------------------------------------
> Second pair of scripts have rm instead of ls -l
> --------------------------------------------------------------
> naxos ~ 9# ja_null_files_ls |less
> ---------- 1 ja sysadmin 0 1970-04-13 14:24 /home/ja/.evolution/.evolution-composer.autosave-3Q3D0U
> ---S--srw- 1 ja sysadmin 0 1970-04-11 04:20 /home/ja/.evolution/.evolution-composer.autosave-ATZC0U
> ---------- 1 ja sysadmin 0 1970-04-18 16:02 /home/ja/.evolution/.evolution-composer.autosave-DFFE0U
> ---S--srw- 1 ja sysadmin 0 1970-04-19 08:56 /home/ja/.evolution/.evolution-composer.autosave-EKHJ0U
> ---------- 1 ja sysadmin 0 1970-04-12 14:56 /home/ja/.evolution/.evolution-composer.autosave-GPAN0U
> ---------- 1 ja sysadmin 0 1970-04-17 22:57 /home/ja/.evolution/.evolution-composer.autosave-GUYR0U
> ---------- 1 ja sysadmin 0 1970-04-11 21:30 /home/ja/.evolution/.evolution-composer.autosave-GWOH0U
> ---S--srw- 1 ja sysadmin 0 1970-04-20 01:59 /home/ja/.evolution/.evolution-composer.autosave-JXSW0U
> ---S--srw- 1 ja sysadmin 0 1970-04-15 01:59 /home/ja/.evolution/.evolution-composer.autosave-OAMW0U
> ---S--srw- 1 ja sysadmin 0 1970-04-14 07:59 /home/ja/.evolution/.evolution-composer.autosave-QAJS0U
> ---S--srw- 1 ja sysadmin 0 1970-04-17 05:51 /home/ja/.evolution/.evolution-composer.autosave-RTTF0U
> ---------- 1 ja sysadmin 0 1970-04-16 12:45 /home/ja/.evolution/.evolution-composer.autosave-S9ZU0U
> ---S--srw- 1 ja sysadmin 0 1970-04-15 19:31 /home/ja/.evolution/.evolution-composer.autosave-ZYQT0U
> ---------- 1 ja sysadmin 0 1970-01-14 17:26 /home/ja/.kde/share/config/kconf_updaterc06fevc.new
> ---------- 1 ja sysadmin 0 1970-01-14 22:22 /home/ja/.kde/share/config/kconf_updaterc0A5kOa.new
> ---------- 1 ja sysadmin 0 1970-01-18 12:39 /home/ja/.kde/share/config/kconf_updaterc0EZsJa.new
> --w-rw---x 1 ja sysadmin 0 1970-01-14 22:15 /home/ja/.kde/share/config/kconf_updaterc0I2gOa.new
> -r--rwx-wx 1 ja sysadmin 0 1970-01-18 14:51 /home/ja/.kde/share/config/kconf_updaterc0Ii9Yb.new
> ---xrwx-wx 1 ja sysadmin 0 1970-01-13 17:19 /home/ja/.kde/share/config/kconf_updaterc0JJLgc.new
> ...
> 
Problem not solved but "worked round"

The heart of the problem is that fully updated F11 and/or Centos 5.3
versions of nfs4 do not seem to work correctly.
They used to !!!!

After chasing many red herrings I discovered a simple
cp /tmp/file /global/dir
where /global is an nfs4 mount does not work consistently

1. If the user does have permission to create the file
It usually fails saying it cannot create the file because of permission problems
However it creates a zero length file, with a variety of permissions set
as seen above.
However it sometimes copies the file correctly !!!!
This was observed on one particular occasion with Thunar where some of the
thumbnails were created and some not.

2. If the user does not have permission to create the file
No problem - no zero length file created

3. Root works too, the file is copied OK and belongs to root:root

Switching back to nfs3 mounts avoids the problems and all is well
-------------------------------------------------------------
Has anyone seen anything similar?

Has anyone any suggestions as to where my nfs4 configuration could be wrong ?
The two lines used nfs3/nfs4 are shown below
(I use NIS to distribute the files)

maui.jaa.org.uk ~ 6# cat /etc/auto.home
*       -fstype=nfs     148.197.29.5:/exports/home/&
#*      -fstype=nfs4,rsize=32768,wsize=32768    148.197.29.5:/home/&

maui.jaa.org.uk ~ 7# cat /etc/auto.direct
/global    -fstype=nfs  148.197.29.5:/exports/global
#/global    -fstype=nfs4,rsize=32768,wsize=32768  148.197.29.5:/global

Should I create a bug report ??

John



-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux