/home/username/.xsession-errors constantly grows until about once a month or so, it reaches an enormous size, taking up my entire drive that I have set to be used as the /home directory. Once this happens, anything and everything graphical still works, but gets very slow and unresponsive, and I get a warning that /home has low disk space, so I delete .xsession-errors manually on the command line using the rm -rf command. Once I delete it, the command line acts as though it has been immediately deleted, but it is such a large file, that it is actually still in the process of being deleted for many hours, sometimes even more than a day, so the computer does not become quick and responsive again for a very long time, often requiring a reboot, but the reboot cannot happen properly since the file is still in the process of being deleted, so then reiserfs file system errors always occur on reboot, and it takes a few tries at rebooting it, which scares me, because this is a web server, not just a personal comupter, so I don’t want to corrupt the file system and have the system offline for any longer than necessary. I’m not sure what is causing .xsession-errors to constantly grow like that. Is there any way to prevent the file from being written in the first place? I’m never going to use it for anything anyway; all it does is cause me problems. This is an openSUSE 12.1 system with all updates available already applied to it. Thanks for any assistance.
-rw------- 1 rickert users 115627 Aug 7 13:21 .xsession-errors
That’s after around 3 days. I logout and log back in twice a week.
I am not sure that removing “.xsession-errors” does anything. When I check with “lsof” there are a bunch of processes that have it open for file descriptors 1 and 2. They will keep it open, even if deleted. So deleting removes the directory entry, but not the file. Only terminating all of the processed that have the file open will free up the file and the space that it uses.
I recommend that you occasionally logout, then login again. Another possibility is:
cd
cp /dev/null .xsession-errors
That should clear out most of the disk space. The file might still look huge, but will probably be a sparse file with most of the fine content not really existing.
Best advice is still to occasionally logout then login.
On 2012-08-09 05:16, please try again wrote:
>
> robin_listas;2479046 Wrote:
>> On 2012-08-08 14:06, please try again wrote:
>>>
>>> @vojtaeus,
>>> Nothing to worry about. Just log out from time to time!
>>
>> Before hibernation started to fail on me, I stayed on the same session
>> for a month, and the file was small.
>>
>>
>
> You’re not using KDE, which generates a huge amount of pointless
> warnings.
Could be.
And they can not be tuned out, those messages?
Perhaps using a named pipe? (wild idea)
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 “Asparagus” GM (bombadillo))
>
>Code:
>--------------------
>
> -rw------- 1 rickert users 115627 Aug 7 13:21 .xsession-errors
>
>--------------------
>
>That’s after around 3 days. I logout and log back in twice a week.
>
>I am not sure that removing “.xsession-errors” does anything. When I
>check with “lsof” there are a bunch of processes that have it open for
>file descriptors 1 and 2. They will keep it open, even if deleted. So
>deleting removes the directory entry, but not the file. Only
>terminating all of the processed that have the file open will free up
>the file and the space that it uses.
>
>I recommend that you occasionally logout, then login again. Another
>possibility is:
>
>Code:
>--------------------
>
> cd
> cp /dev/null .xsession-errors
Hmmm. Not "cp but “mv”; cp won’t remove the source file.
>
>--------------------
>
>That should clear out most of the disk space. The file might still
>look huge, but will probably be a sparse file with most of the fine
>content not really existing.
>
>Best advice is still to occasionally logout then login.
When an existing process has the file open, then it is referencing the file by its inode, not by the file name. Using “mv” changes the file name, but keeps the inode. Processes that are writing to the file will continue to write to the same file, even though it now has a different name.
What about redirecting the whole garbage to /dev/null by symlinking?
Switch to runlevel 3 so that X does not run and the file is not in use,
then login as your user in runlevel 3
switch back to run level 5 and see how it goes.
Of course in case you really want at some day look into the file to see
real errors it is no longer possible to do so.
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.1 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.5 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
Am 12.08.2012 17:06, schrieb dd@home.dk:
> On 08/12/2012 02:43 PM, Martin Helm wrote:
>> What about redirecting the whole crap to /dev/null by symlinking?
>
> or how about not running an instance of X 24x7 on a server?
>
> just boot to run level 3.
>
> then when/if the ‘administrator’ needs a window s/he can init 5 to a
> gui, then back to init 3 (as the deity intended)…
>
+1
–
PC: oS 12.2 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.8.4 | GeForce GT 420
ThinkPad E320: oS 12.1 x86_64 | i3@2.30GHz | 8GB | KDE 4.8.5 | HD 3000
eCAFE 800: oS 12.1 i586 | AMD Geode LX 800@500MHz | 512MB | KDE 3.5.10
On 08/12/12 11:31, Martin Helm pecked at the keyboard and wrote:
> Am 12.08.2012 17:06, schrieb dd@home.dk:
>> On 08/12/2012 02:43 PM, Martin Helm wrote:
>>> What about redirecting the whole crap to /dev/null by symlinking?
>> or how about not running an instance of X 24x7 on a server?
>>
>> just boot to run level 3.
>>
>> then when/if the ‘administrator’ needs a window s/he can init 5 to a
>> gui, then back to init 3 (as the deity intended)…
>>
> +1
>
Actually just use startx. When you log out you’ll be at the tty prompt
without “X” running.
>
>nrickert;2479585 Wrote:
>> That misses the whole point.
>>
>> When an existing process has the file open, then it is referencing the
>> file by its inode, not by the file name. Using “mv” changes the file
>> name, but keeps the inode. Processes that are writing to the file will
>> continue to write to the same file, even though it now has a different
>> name.
>
>+1
>That’s true.
>
>@josephkk:
>
>You can see it if you do:
>
>
>Code:
>--------------------
>
> $ lsof ~/.xsession*
> $ mv ~/.xsession-errors ~/.xsession-errors.old
> $ lsof ~/.xsession*
>
>--------------------
>
>
>You will see that all processes are now writing to .xsession-errors.old
Hot damn. Shoot my mouth of and get to learn something. Cost effective
education.
On 08/12/12 17:56, please try again pecked at the keyboard and wrote:
> kensch;2479706 Wrote:
>> Actually just use startx. When you log out you’ll be at the tty prompt
>> without “X” running.
> Did you try that under openSUSE ? … or supposing you’re not an expert
> or haven’t read 11.4 Releases Notes? (and you’re not starting X as
> root).
>
>
Been using S.u.S.E./openSUSE since 1998 ver. 5.something. You run startx
as a user and su (-) to root to run what you need to run. Actually I ssh
-X to the box I want to admin so still no need to have “X” running on a
server.
> Been using S.u.S.E./openSUSE since 1998 ver. 5.something. You run startx as a user and su (-)
> to root to run what you need to run. Actually I ssh -X to the box I want to admin so still no
> need to have “X” running on a server.
It is a procedure not recommended by the devs, so much so that it doesn’t work by default any
longer. And if you do manage to make it work, then there are further problems, with some
functionalities of the desktops not working because they depend on kdm/gdm.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Pass NET::WMDesktop to KWindowInfo