Re: Query about .xsession-errors file
On Wed, 10 Sep 2014, Bret Busby wrote:
On 10/09/2014, davidson@ling.ohio-state.edu wrote:
On Tue, 9 Sep 2014, Jonathan Dowland wrote:
On Wed, Sep 10, 2014 at 01:54:08AM +0800, Bret Busby wrote:
The file has (kind of) gone, now (it is no longer accessible, but,
appears to still exist, in the ether of the unknown; still taking up
disc space, whilst, in theory, non-existent),
A file continues to use up disk space until all open file handles are
closed.
Quite likely Xorg still has the file open, even though you've removed all
the
hard links (paths) to it on the filesystem. If you still have the system
up in
the same state, you might see it in /proc/$(pidof Xorg)/fd (or it might
be
another process other than Xorg, or I might be wrong entirely)
if you have lsof installed, you can find out what processes are still
using the deleted file quite easily:
$ lsof |grep '\.xsession-errors'
might produce lines like
xterm 2237 busbyenator 1w REG 8,1 0 359981
/home/busbyenator/.xsession-errors (deleted)
xterm 2237 busbyenator 2w REG 8,1 0 359981
/home/busbyenator/.xsession-errors (deleted)
the second field is the pid. the fourth field is the file descriptor
(in this case suffixed with 'w', indicating the process has write
access).
the lines above indicate that the xterm process with pid 2237 is
writing its standard output (fd 1) and standard error (fd 2) to a file
formerly known to the filesystem as .xsession-errors, and which can
still be accessed at /proc/2237/fd/1 (and at /proc/2237/fd/2).
so, in the case above,
$ cat /proc/2237/fd/1
will output the contents of the file formerly known to the filesystem
as .xsession-errors, and
$ cp /proc/2237/fd/1 preciousss_xsession-errors
saves them for posterity.
please note, obviously, that pid 2237 is just an example.
-wes
What I get now, is
"
:~$ lsof |grep '\.xsession-errors'
nautilus 2366 bret 54u REG 8,8
0 1169162 /home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
"
Looks like your 750M error log is truly gone, then. The file listed
above is probably some kind of meta-info your file manager
wants/wanted to keep track of. I wouldn't mess with it.
Just fyi, here's some interpretation of your shell commands:
Running ls -l, gives
"
:~$ ls -l .xsession-errors
-rw------- 1 bret bret 0 Sep 10 00:23 .xsession-errors
"
Okay, an empty file. No relation to the lsof output.
So, I assume that, for the present, all is well with it, as it
(amongst other things) has read and write access, and, that nothing
more should be done, at this time, about the particular file, unless I
am advised otherwise.
Sure, I don't see anything to be done at this point.
Next time though, as Chris suggested, it might be interesting to read
the error messages.
I note that, with that file that is being accessed by Nautilus,
assuming that the number 1169162 , is the size of the file,
Yes, that is the size of the file *formerly* referred to as
/home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
and *still* (at least at this point) referred to as
/proc/2366/fd/54
I have tried, but, apparently, can not reduce that to zero, as that
number does not change, with my attempts.
Well, I believe you *could*, but I wouldn't.
:~$ lsof |grep '\.xsession-errors'
nautilus 2366 bret 54u REG 8,8
0 1169162 /home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
bret@bret-dd-workstation:~$ cp .xsession-errors
.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
Erm, fyi, the cp command immediately above just created a new file.
An empty one.
bret@bret-dd-workstation:~$ lsof |grep '\.xsession-errors'
nautilus 2366 bret 54u REG 8,8
0 1169162 /home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
Nothing surprising here. The file used by nautilus, *formerly* linked
to by the name .xsession-errors.trashinfo.H87KLX, was not affected by
your cp command.
had you wanted to refer to that file, currently opened by nautilus for
reading and writing, you would have had to refer to it by
'/proc/2366/fd/54', rather than its former name.
But, like I said, I wouldn't have messed with it anyway.
bret@bret-dd-workstation:~$ lsof |grep '\.xsession-errors'
nautilus 2366 bret 54u REG 8,8
0 1169162 /home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
bret@bret-dd-workstation:~$ >
.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
"Nothing happens."
The command immediately above just truncated a file which was already
empty.
bret@bret-dd-workstation:~$ lsof |grep '\.xsession-errors'
nautilus 2366 bret 54u REG 8,8
0 1169162 /home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
Again, no surprises.
bret@bret-dd-workstation:~$ >
.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX (deleted)
bash: syntax error near unexpected token `('
You appear to be trying to truncate /proc/2366/fd/54
Why would you want to mess with nautilus's head like that?
However, in having closed all windows in the File Browser (as I had
assumed that that was the Nautilus, that was accessing the file,
before the above commands, which appears to have not ceased the
accessing of the file), and, then, after running the above commands,
opening the File Browser, and, examining the file information, it
shows the filesize to be zero, and, ls -l gives
"
:~$ ls -l .local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
-rw------- 1 bret bret 0 Sep 10 15:09
.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
"
Yes, you created this empty file yourself, with a cp command. See
above.
so, I do not know what that number 1169162, shown in the lsof output,
represents.
Well, that's the size of a file that nautilus had open for reading and
writing.
The fact that lsof appended ' (deleted)' after its name indicates that
the name
/home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
is a *former* name. It no longer links to that file.
To inspect it, clobber it, copy it, or whatever, you could have used
the handle /proc/2366/fd/54
But, again, I wouldn't have bothered. It wasn't the droid you were
looking for.
But, apart from what that number represents, as I have said, the
problem appears to have been disappeared.
Well, they do say that all's well that ends well.
-wes
--
"95% of JS scripts are written with feet." --- Bzzzz
Reply to: