On Sun, Nov 1, 2020, 11:48 AM Teemu Likonen wrote:
> * 2020-11-01 11:09:50+01, Anders Andersson wrote:
>
> > On Mon, Oct 26, 2020 at 5:43 PM Teemu Likonen wrote:
> >> From my backups I found an ~/.xsession-errors file of size 111
> >> megabytes. Probably I
* 2020-11-01 11:09:50+01, Anders Andersson wrote:
> On Mon, Oct 26, 2020 at 5:43 PM Teemu Likonen wrote:
>> From my backups I found an ~/.xsession-errors file of size 111
>> megabytes. Probably I deleted the file at that point and it started
>> grow again.
>
> Amateur
On Mon, Oct 26, 2020 at 5:43 PM Teemu Likonen wrote:
>
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
>
> -
code that referenced
> > "xsession-errors" or "ERRFILE" or any logfile except
> > "~/.cache/lxsession/LXDE/run.log".
>
> The relevant code apparently exists in the greeter app (or whatever it's
> called) I use (lightdm):
>
> src/session.c
On 2020-10-28, David wrote:
>
> Yes, I don't feel that I found the full answer. Because I spent a while
> using https://codesearch.debian.net/ to examine the source code
> of lxsession but I was unable to find any code that referenced
> "xsession-errors" or "
On Tue 27 Oct 2020 at 07:53:01 (-0400), Greg Wooledge wrote:
> On Tue, Oct 27, 2020 at 11:28:12AM +1100, David wrote:
> > On Tue, 27 Oct 2020 at 10:56, David Wright wrote:
> > > fuser -v "$j"
> > > [ $? -ne 0 ] && gzip "$j" && mv -i "$j.gz"
> > > "$HOME/.monitors/xsession/"
> >
> >
, Tixy wrote:
> > > > > On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > > > > > It seems that ~/.xsession-errors file can still grow to infinity in
> > > > > > size. Sometimes it grows really fast. This is nothing new: we have
> &
:35 +0200, Teemu Likonen wrote:
>
> > > > > It seems that ~/.xsession-errors file can still grow to infinity in
> > > > > size. Sometimes it grows really fast. This is nothing new: we have all
> > > > > seen it and talked about it. What do you do to maintain this f
, LXDE and minimal
> > Xorg).
>
> I had a curiosity about this, because some people are reporting that they
> need to manage their growing .xsession-errors file by various methods,
> but I never have seen this.
>
> I see the same behaviour as Andrei, and I also use parts of
On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU wrote:
> On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> > On Mon, Oct 26, 2020 at 11:07:37PM +, Tixy wrote:
> > > On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > > > It seems that ~/.xsession-errors f
gt;> (Why doesn't Debian have this automatically?)
I simply (like someone else mentioned on the list) truncate the file
periodically (actually, once every minute) using a crontab with a task like
this:
* * * * * echo "Cleared on $(date) by $USER cron" >
/home//.xsessi
tance, such logrotate policy
> would be denied by SELinux.
> That, and inviting running-as-root logrotate to cleanup user files opens
> all kinds of trouble.
I'm using KDE Plasma desktop and my .xsession-errors grows quite fast.
I'll probably write some rotation system for the f
On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> On Mon, Oct 26, 2020 at 11:07:37PM +, Tixy wrote:
> > On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > > It seems that ~/.xsession-errors file can still grow to infinity in
> > > size. Sometimes it grows r
On Mon, Oct 26, 2020 at 11:07:37PM +, Tixy wrote:
> On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > It seems that ~/.xsession-errors file can still grow to infinity in
> > size. Sometimes it grows really fast. This is nothing new: we have all
> > seen it and
On Tue, Oct 27, 2020 at 11:28:12AM +1100, David wrote:
> On Tue, 27 Oct 2020 at 10:56, David Wright wrote:
> > fuser -v "$j"
> > [ $? -ne 0 ] && gzip "$j" && mv -i "$j.gz" "$HOME/.monitors/xsession/"
>
> > (Script improvements always appreciated.)
> https://www.shellcheck.net says:
On Tue, 27 Oct 2020 at 10:56, David Wright wrote:
> fuser -v "$j"
> [ $? -ne 0 ] && gzip "$j" && mv -i "$j.gz" "$HOME/.monitors/xsession/"
[...]
> (Script improvements always appreciated.)
Hi, you might be interested in the info below :
my test script:
"""
#!/bin/sh
[ $? -ne 0 ]
On Mon 26 Oct 2020 at 18:35:45 (+0200), Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
>
>
Tixy writes:
> I guess as I never hibernate my laptop and turn it off every day, it
> never gets to an annoying size.
I haven't rebooted my desktop for three months. ls -l .xsession-errors
shows 468223. I consider that trivial and ignore it.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
Don't do anyt
Teemu Likonen writes:
It seems that ~/.xsession-errors file can still grow to infinity in
size. Sometimes it grows really fast. This is nothing new: we have all
seen it and talked about it. What do you do to maintain this file?
Until now, I had not seen it as a problem. But it is quite large
* 2020-10-26 18:12:43+01, Sven Joachim wrote:
> If you have a good idea how to fix that, please send it to bug
> #287876[1] or one of its siblings.
> 1. https://bugs.debian.org/287876
There are already ideas and even patches in the bug report. For example
a logrotate patch was sent in
On 2020-10-26 18:35 +0200, Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
>
> - Do you just
Hi.
On Mon, Oct 26, 2020 at 06:35:45PM +0200, Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain
It seems that ~/.xsession-errors file can still grow to infinity in
size. Sometimes it grows really fast. This is nothing new: we have all
seen it and talked about it. What do you do to maintain this file?
- Do you just delete it when you happen to notice it's too big?
- Do you configure
Hi there,
I found the following in the ~/.xsession-errors :
dbus-update-activation-environment: warning: error sending to systemd:
org.freedesktop.DBus.Error.Spawn.ChildExited: Process
org.freedesktop.systemd1 exited with status 1
I was trying to search the net but no luck. Any suggestions
On 2018-04-06 18:56, Greg Wooledge wrote:
> On Fri, Apr 06, 2018 at 06:45:20PM +0200, Mikhail Morfikov wrote:
>> Basically even the standard "exec ..." in the /etc/X11/Xsession file (with
>> changed $ERRFILE) works fine, but I have to "cat" the FIFO device first
>> (without
>> using systemd). The
On Fri, Apr 06, 2018 at 06:45:20PM +0200, Mikhail Morfikov wrote:
> Basically even the standard "exec ..." in the /etc/X11/Xsession file (with
> changed $ERRFILE) works fine, but I have to "cat" the FIFO device first
> (without
> using systemd). The same with your exec command -- there's no
On 2018-04-06 17:53, Greg Wooledge wrote:
> On Fri, Apr 06, 2018 at 05:48:35PM +0200, Mikhail Morfikov wrote:
>> If I set $ERRFILE to the FIFO device, processing of the script will be
>> stopped
>> in the point where "exec ..." appears (before sourcing the
>> /etc/X11/Xsession.d/
>> dir).
>
>
On 2018-04-06 18:29, Don Armstrong wrote:
> On Fri, 06 Apr 2018, Mikhail Morfikov wrote:
>> Basically, all messages returned by X-applications are redirected to the
>> ~/.xsession-errors file.
> [...]
>> Unfortunately, the ~/.xsession-errors file grows in size, and a
On Fri, 06 Apr 2018, Mikhail Morfikov wrote:
> Basically, all messages returned by X-applications are redirected to the
> ~/.xsession-errors file.
[...]
> Unfortunately, the ~/.xsession-errors file grows in size, and after a
> few hours it's around 20-30 MiB, and the content of th
On Fri, Apr 06, 2018 at 05:48:35PM +0200, Mikhail Morfikov wrote:
> If I set $ERRFILE to the FIFO device, processing of the script will be stopped
> in the point where "exec ..." appears (before sourcing the
> /etc/X11/Xsession.d/
> dir).
You need to run something in the background which opens
On 2018-04-06 15:48, to...@tuxteam.de wrote:
> On Fri, Apr 06, 2018 at 03:18:08PM +0200, Mikhail Morfikov wrote:
>> Basically, all messages returned by X-applications are redirected to the
>> ~/.xsession-errors file [...]
>
>> till a terminal with "cat" is st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 06, 2018 at 03:18:08PM +0200, Mikhail Morfikov wrote:
> Basically, all messages returned by X-applications are redirected to the
> ~/.xsession-errors file [...]
> till a terminal with "cat" is started inside of the
Basically, all messages returned by X-applications are redirected to the
~/.xsession-errors file. In some desktop environments this file is emptied with
each X session restart. At least that was the case of my Openbox + LightDM
setup. Now, I'm trying to migrate to KDE/Plasma5, and as a part
Le Fri, 10 Jul 2015 06:30:02 +0200, Stéphane GARGOLY a écrit :
Moi, ce qui m'interpelle surtout, c'est de se retrouver avec un fichier
'.xsession-errors' de plus de... 200 Gio (soit plus de 200 000 Mio ou
encore plus de 200 000 000 kio). o_O
Je me demande comment cela est possible
On 10/07/2015 08:38, moi-meme wrote:
surtout que ce n'est pas une maladie du DD.
C'est la deuxième fois que cela se produit.
Juste par curiosité, tu peux publier un extrait ?
--
Fabien
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour
Le Fri, 10 Jul 2015 09:30:01 +0200, Fabien R a écrit :
C'est la deuxième fois que cela se produit.
Juste par curiosité, tu peux publier un extrait ?
--
tu le veux les 220G en totalité ? :-)
Non poubelle mais à la fin du fichier il disait en boucle qu'il ne
trouvait pas un fichier, je ne
pour éviter que le fichier explose ?
(limiter sa taille)
Moi, ce qui m'interpelle surtout, c'est de se retrouver avec un fichier
'.xsession-errors' de plus de... 200 Gio (soit plus de 200 000 Mio ou encore
plus de 200 000 000 kio). o_O
Je me demande comment cela est possible.
Cordialement et
un peu gros et ça ne laisse pas de place pour travailler :-(
Suite à petit problème X ça m'a tout bloqué.
Effacé le fichier : c'est reparti.
Mais comment faire pour éviter que le fichier explose ?
(limiter sa taille)
--
Lisez la FAQ de la liste avant de poser une question :
On 15/09/2014, Chen Wei weichen...@icloud.com wrote:
On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote:
.xsession-errors, which is currently sitting at about 740MB, and has
been growing in the last hour.
entries from before the current boot session) entries, so as to reduce
the file
On Mon, 15 Sep 2014 15:07:48 +0800
Bret Busby bret.bu...@gmail.com wrote:
On 15/09/2014, Chen Wei weichen...@icloud.com wrote:
On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote:
.xsession-errors, which is currently sitting at about 740MB, and
has been growing in the last hour
On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote:
.xsession-errors, which is currently sitting at about 740MB, and has
been growing in the last hour.
entries from before the current boot session) entries, so as to reduce
the file size to content that is necessary to retain
the computer?
So you are saying that with the .xsession-errors at zero size hasn't
reclaimed the disk space?
What does df -h show?
I think that the problem has now been disappeared.
A number of things have happened since (I think that it is since) I
last posted about this problem, which, I
-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
-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
Bret Busby bret.bu...@gmail.com writes:
I note that, with that file that is being accessed by Nautilus,
assuming that the number 1169162 , is the size of the file, I have
tried, but, apparently, can not reduce that to zero, as that number
does not change, with my attempts.
On a side note:
Bret Busby bret.bu...@gmail.com writes:
So, I believe (unttil and unless, advised otherwise) that the
deleteing the file (which did not free up the disc space, in itself),
and then, renaming the xsystem-errors.old file, to xsystem-errors,
appears to have disappeared the problem, which, if I
Hello.
In trying to work out why my disk space gets progressively consumed so
that I repeatedly run out of disc space without any known reason, in
examining my hidden files in my home directory, I found the file
.xsession-errors, which is currently sitting at about 740MB, and has
been growing
that is necessary to retain for debugging?
xsession-errors should be re-created when a new session starts (see
/etc/X11/Xsession for the details). Long-running X session can produce
annoyingly large .xsession-errors indeed.
The solution to this problem comes in the form of logrotate:
$ cat /etc
On 09/09/14 at 03:29pm, Bret Busby wrote:
Hello.
In trying to work out why my disk space gets progressively consumed so
that I repeatedly run out of disc space without any known reason, in
examining my hidden files in my home directory, I found the file
.xsession-errors, which is currently
incantation is one answer:
tal% ls -alh .xsession-errors
-rw--- 1 chrisb chrisb 33K Sep 9 17:40 .xsession-errors
tal% : .xsession-errors
tal% ls -alh .xsession-errors
-rw--- 1 chrisb chrisb 0 Sep 9 21:25 .xsession-errors
--
If you're not careful, the newspapers will have you hating the people
such damage would occur by deleting it, but
the following incantation is one answer:
tal% ls -alh .xsession-errors
-rw--- 1 chrisb chrisb 33K Sep 9 17:40 .xsession-errors
tal% : .xsession-errors
tal% ls -alh .xsession-errors
-rw--- 1 chrisb chrisb 0 Sep 9 21:25 .xsession-errors
to the boot session, would occur.
I very much doubt that any such damage would occur by deleting it, but
the following incantation is one answer:
tal% ls -alh .xsession-errors
-rw--- 1 chrisb chrisb 33K Sep 9 17:40 .xsession-errors
tal% : .xsession-errors
tal% ls -alh .xsession-errors
-rw
On Wed 10 Sep 2014 at 01:24:24 +0800, Bret Busby wrote:
Just out of interest, top shows the system as having been up for 21
days, so, the xsession-errors file grew to 743MB, in 21 days. I saw,
at the top of that file, before I deleted it, reference to 21 August,
so, the file apparently, grows
On 10/09/2014, Brian a...@cityscape.co.uk wrote:
On Wed 10 Sep 2014 at 01:24:24 +0800, Bret Busby wrote:
Just out of interest, top shows the system as having been up for 21
days, so, the xsession-errors file grew to 743MB, in 21 days. I saw,
at the top of that file, before I deleted
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
disc space.
I have had to move files off the HDD, to make it usable (it does not
work with no free space, which is what the file did to it).
Does a way exist, for me to reclaim the vanished disc space, without
having to reboot the computer?
So you are saying that with the .xsession-errors
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
Hallo,
In het bestand .xsession-errors op mijn dikke, slome laptop staan veel
foutmeldingen die wijzen op configuratiefouten van gnome-session en
DBus, te beginnen met:
(gnome-settings-daemon:3923): color-plugin-WARNING **: failed to get
devices: Failed to GetDevices
I have been noticing this error in .xsession-errors file lately:
glibtop: Non-standard uts for running kernel:
release 3.12-1-686-pae=3.12.0 gives version code 199680
Can someone explain what's this about ? Should I be concerned?
Thanks
--
To UNSUBSCRIBE, email to debian-user-requ
On Tuesday, February 18, 2014 12:12:20 PM Frank McCormick wrote:
I have been noticing this error in .xsession-errors file lately:
glibtop: Non-standard uts for running kernel:
release 3.12-1-686-pae=3.12.0 gives version code 199680
Can someone explain what's this about ? Should I
On 2014-02-18 18:12 +0100, Frank McCormick wrote:
I have been noticing this error in .xsession-errors file lately:
glibtop: Non-standard uts for running kernel:
release 3.12-1-686-pae=3.12.0 gives version code 199680
Can someone explain what's this about ?
It's glibtop complaining about
Version: 2.28.5-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
..xsession-errors entry:
glibtop: Non-standard uts for running kernel:
release 3.12-1-amd64=3.12.0 gives version code 199680
--
Paul Cartwright
Registered Linux User #367800 and new counter #561587
uts for running kernel:
Package: libgtop2-7
Version: 2.28.5-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
..xsession-errors entry:
glibtop: Non-standard uts for running kernel:
release 3.12-1-amd64=3.12.0 gives version code 199680
I have a comment to the bug...re
code:
Fwd: Bug#739444: glibtop: Non-standard uts for running kernel:
Package: libgtop2-7
Version: 2.28.5-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
..xsession-errors entry:
glibtop: Non-standard uts for running kernel:
release 3.12-1-amd64=3.12.0 gives version code
On 18/02/14 02:02 PM, Sven Joachim wrote:
On 2014-02-18 18:12 +0100, Frank McCormick wrote:
I have been noticing this error in .xsession-errors file lately:
glibtop: Non-standard uts for running kernel:
release 3.12-1-686-pae=3.12.0 gives version code 199680
Can someone explain what's
On Tue, 2014-02-18 at 11:19 -0600, y...@marupa.net wrote:
This is probably not the best advice but: If nothing slows
down/crashes/screws up data, then you can probably ignore it.
It's a good advice, it's only missing that people should do some
Internet research.
Bug#739444
Oops, by accident I posted a wrong link.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392754630.2586.42.camel@archlinux
caras del cubo 3D
que se puede ver.
Despues desaparecio el menu, ya no sale. Despues de me quede sin
espacio siendo que el disco era de 1 thera y no encontraba la solucion
hasta que investigando llegue a que el archivo xsession-errors es el
que se llena rapido y ocupa todo el disco duro. Para trabjar
desaparecio el menu, ya no sale. Despues de me quede sin espacio
siendo que el disco era de 1 thera y no encontraba la solucion hasta que
investigando llegue a que el archivo xsession-errors es el que se llena
rapido y ocupa todo el disco duro. Para trabjar tuve que borrarlo en su
totalidad e hice un
and I found
some that I would like to check if they are already known or if they are
specific to my hardware. Checking the .xsession-errors file I found the
following messages:
*Window manager warning: CurrentTime used to choose focus window; focus
window may not be correct.
Window manager warning
and it is being shown as a very stable platform, even though this branch
is called Testing. I have being checking the logs, looking for errors
and I found some that I would like to check if they are already known or
if they are specific to my hardware. Checking the .xsession-errors
file I found
Bonjour,
J'ai une machine wheezy/amd64 qui affiche en boucle des vidéos avec
mplayer2.
depuis quelques temps (remplacement de mplayer par mplayer2 ou mise à
jour la semaine dernière, je ne sais plus...), j'ai un
fichier .xsession-errors qui enfle rapidement jusqu'à remplir l'espace
disponible
Le 08/02/2012 16:09, Christophe Maquaire a écrit :
Bonjour,
J'ai une machine wheezy/amd64 qui affiche en boucle des vidéos avec
mplayer2.
depuis quelques temps (remplacement de mplayer par mplayer2 ou mise à
jour la semaine dernière, je ne sais plus...), j'ai un
fichier .xsession-errors qui
On Wed, 8 Feb 2012 16:09:40 +0100
Christophe Maquaire christophe.maqua...@free.fr wrote:
J'ai une machine wheezy/amd64 qui affiche en boucle des vidéos avec
mplayer2.
Houlà, c'est au moins 4 ans de prison et 50M d'amende ça,
si ACTA passe;)
Playing /home/affiche/videos/2-sidn.avi.
As-tu
On Wed, 08 Feb 2012 16:14:18 +0100
prego Jérémy jer...@prego-network.net wrote:
et lancer mplayer en mode -quiet ?
Je viens de feuilleter la page man de mplayer et çà semble être une bonne piste.
Le test est en cours...
Christophe Maquaire
--
Lisez la FAQ de la liste avant de poser une
On Wed, 8 Feb 2012 16:48:57 +0100
Bzzz lazyvi...@gmx.com wrote:
On Wed, 8 Feb 2012 16:09:40 +0100
Christophe Maquaire christophe.maqua...@free.fr wrote:
J'ai une machine wheezy/amd64 qui affiche en boucle des vidéos avec
mplayer2.
Houlà, c'est au moins 4 ans de prison et 50M d'amende
On Wed, 08 Feb 2012 16:14:18 +0100
prego Jérémy jer...@prego-network.net wrote:
et lancer mplayer en mode -quiet ?
C'est ce que je cherchais, merci!
Christophe Maquaire
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER,
On 02/21/2011 09:16 PM, Dave Witbrodt wrote:
I've been plagued by this one for over a year. The Debian BTS has a bug
report for it already, and in comment 35 there I listed similar reports
on other bug tracking systems:
thanks for the update!
I'm hoping that the upcoming libgtk version
I have lots lots of these errors:
in .xsession-errors:
(firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead
(firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead
(firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead
(firefox-bin:15563): Gdk-WARNING **: XID
On 02/21/2011 02:26 PM, Paul Cartwright wrote:
I have lots lots of these errors:
in .xsession-errors:
(firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead
(firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead
(firefox-bin:15563): Gdk-WARNING **: XID collision, trouble
On 02/21/2011 03:47 PM, Ron Johnson wrote:
(firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead
is it my configuration, or a major gtk issue?
a) They are warnings, not errors.
b) They are *stupendously* common.
$ grep 'XID collision, trouble ahead' .xsession-errors | wc
On 02/21/2011 05:36 PM, Michelle Konzack wrote:
I think I have to write some bug reports since there are three programs
DOSing the .xsession-errors. 680 MByte in 3 days is inacceptable.
However, if I stay as usualy one month and longer online my partition
will crash...
yes, I deleted
Hello Paul Cartwright,
Am 2011-02-21 16:01:58, hacktest Du folgendes herunter:
$ grep 'XID collision, trouble ahead' .xsession-errors | wc
275772 1930404 18116684
wow, ya got me beat:)
$ grep 'XID collision, trouble ahead' .xsession-errors | wc
137884 965188 9100344
I was googling
On 02/21/2011 05:36 PM, Michelle Konzack wrote:
Hello Paul Cartwright,
Am 2011-02-21 16:01:58, hacktest Du folgendes herunter:
$ grep 'XID collision, trouble ahead' .xsession-errors | wc
275772 1930404 18116684
wow, ya got me beat:)
$ grep 'XID collision, trouble ahead' .xsession-errors
, my ~/.xsession-errors kept logs back to stone age.
For what reason can't you simply modify you Xsession file to do as you
like? It is a conffile, so your changes would be preserved through
upgrades.
Read the above url again, carefully. The answer is right there before you
eyes. You don't
On Wed, 19 May 2010 11:33:02 -0500, Boyd Stephen Smith Jr. wrote:
I took a look, the reason and cure is very simple -- having X to trunk
it each time when started
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287876) whereas
currently, my ~/.xsession-errors kept logs back to stone age
Hi,
I am astonished to find out that my ~/.xsession-errors grows to a
humongous 640M! My wife's is nearly 400M as well. This is way way too
big.
I took a look, the reason and cure is very simple -- having X to trunk it
each time when started
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug
On Wednesday 19 May 2010 11:18:57 T o n g wrote:
I am astonished to find out that my ~/.xsession-errors grows to a
humongous 640M! My wife's is nearly 400M as well. This is way way too
big.
I took a look, the reason and cure is very simple -- having X to trunk it
each time when started
On 2010-05-19 18:18 +0200, T o n g wrote:
I am astonished to find out that my ~/.xsession-errors grows to a
humongous 640M! My wife's is nearly 400M as well. This is way way too
big.
I took a look, the reason and cure is very simple -- having X to trunk it
each time when started
(http
On Wed, May 19, 2010 at 06:45:04PM +0200, Sven Joachim wrote:
On 2010-05-19 18:18 +0200, T o n g wrote:
I am astonished to find out that my ~/.xsession-errors grows to a
humongous 640M! My wife's is nearly 400M as well. This is way way too
big.
I took a look, the reason and cure
T o n g wrote:
Hi,
I am astonished to find out that my ~/.xsession-errors grows to a
humongous 640M! My wife's is nearly 400M as well. This is way way too
big.
I took a look, the reason and cure is very simple -- having X to trunk it
each time when started
(http://bugs.debian.org/cgi-bin
: X session started for dawud at mié may 19 18:25:05 CEST
2010
$ ll .xsession-errors
-rw--- 1 dawud dawud 72 may 19 18:25 .xsession-errors
Looks like somebody truncated the file for you, maybe the display
manager. FWIW, stock XDM would do that if it were not disabled by a
Debian patch
Hello.
/etc/X11/Xsession creates a ~/.xsession-errors and then creates a
symlink from that file to /tmp/xsession-$USER. But if that fails, it
tells the user that it has tried it the other way round.
Doing it the other way would not only fit to the message, but would also
make more sense to me
On my machine the file ~/.xsession-errors grows and grows without
limits. I have to remove it regularly before it takes over my
whole disk; this has been the case for years. Last time I removed
it was September 21; now it is again already 135M in size! It
grows by the minute. It is mainly full
Jan Willem Stumpel wrote at 2009-10-15 08:44 -0500:
On my machine the file ~/.xsession-errors grows and grows without
limits. I have to remove it regularly before it takes over my
whole disk; this has been the case for years. Last time I removed
it was September 21; now it is again already
On 15:44 Thu 15 Oct , Jan Willem Stumpel wrote:
I think I had this problem many years ago. I dont remember if it was in my old
redhat days or after I moved to debian in ?2003 or so. I remember I had a 50G
or 100G .xsession-errors file or
something like that.
The solution is simple. You
Hugo Vanwoerkom wrote:
Hugo Vanwoerkom wrote:
Hi,
I get a lot of:
error 182 request 157 minor 8 serial 773
where 'serial'keeps climbing.
Anybody knows what it means?
Its meaning is still a mystery. But they show up after issuing:
xcompmgr -c -f
I've filed a bug:
Hugo Vanwoerkom wrote:
Hi,
I get a lot of:
error 182 request 157 minor 8 serial 773
where 'serial'keeps climbing.
Anybody knows what it means?
Its meaning is still a mystery. But they show up after issuing:
xcompmgr -c -f
Hugo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Hi,
I get a lot of:
error 182 request 157 minor 8 serial 773
where 'serial'keeps climbing.
Anybody knows what it means?
Hugo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 176 matches
Mail list logo
