Hi Tim, It's strange because i can see in the .nfs** file : information from startkde. Like this : In .nfs00000000000e0495000016f4 " Xsession: X session started for XXXXX at jeudi 7 novembre 2013, 09:01:38 (UTC+0100) /usr/bin/xmodmap: unable to open file '/usr/share/apps/kxkb/ubuntu.xmodmap' for reading /usr/bin/xmodmap: 1 error encountered, aborting. [startkde] Starting startkde. [startkde] This script is /usr/bin/startkde4 [startkde] TDE version is 3.5.13.1 [startkde] TDE base directory is /opt/trinity [startkde] KDEHOME is not set. [startkde] Set KDEHOME to /home/XXXX/.trinity. [startkde] Setting KDEROOTHOME to /root/.trinity. [startkde] KDEDIR: /opt/trinity [startkde] KDEDIRS: [startkde] Starting Trinity... kdeinit: Launched DCOPServer, pid = 30319 result = 0 kdeinit: Launched KLauncher, pid = 30325 result = 0 kdeinit: opened connection to :1114.0 kdeinit: Launched KDED, pid = 30326 result = 0 kdeinit: Got EXT_EXEC 'kbuildsycoca' from launcher. kbuildsycoca running... Reusing existing ksycoca kdeinit: PID 30328 terminated. kdeinit: Got EXEC_NEW 'kconf_update' from launcher. kdeinit: PID 30329 terminated. kdeinit: PID 30326 terminated. reading '/home/XXXX/.kompmgr.pid' as kompmgr pidfile [startkde] TDE_FULL_SESSION: true [startkde] KDE_SESSION_UID: 81206 kdeinit: Shutting down running client. kdeinit: Killing kdeinit/klauncher. ..... " For .DCOP file, i have some : dcopserver [kdeinit] --nosid --suicide process Thanks for your help. Sincerely, Jean 2013/11/8 Timothy Pearson <kb9vqf(a)pearsoncomputing.net> -- MILOT Jean Tél. : 0659514624 milot.jean(a)gmail.com

On 8 Nov 2013, Timothy Pearson verbalised: [...] The .nfs files are NFS 'silly-delete' files. In Unixlike operating systems, it is expected behaviour that you can delete a file you have open and continue using it -- but an NFS server, being stateless, has no idea what files its clients have open. So as a hack around this, when an NFS client gets asked to delete a file it has open, it requests that the server rename it to .nfs{random junk} instead, then sends a delete for that when it is closed. This is a hack and clearly cannot work in all cases (i.e. a process on one client holds a file open, and a process on another client deletes it) -- but in practice it works well enough to be getting on with, except if the client crashes. Then it cannot ever send the delete request for the silly-delete files, and they build up. Because they are the wreckage of old files (often temporary files) that were deleted but not closed, it is normal for them to contain actual, real, useful data. -- NULL && (void)