Hi,
Max Nikulin wrote:
> > > A bit off-topic question. In what wiki page you would expect to find
> > > suggestions to inspect ~/.xsession-errors file and journalctl output?
I wrote:
> > I pasted ".xsession-errors" into the "Search:" field at the up
On 23/07/2024 19:20, Thomas Schmitt wrote:
A bit off-topic question. In what wiki page you would expect to find
suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any
On Tue, Jul 23, 2024 at 14:20:43 +0200, Thomas Schmitt wrote:
> The only helpful match is
>
>
> https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text
>
> "What Does The Log Say?
>...
>I
Hi,
Max Nikulin wrote:
> A bit off-topic question. In what wiki page you would expect to find
> suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any Debian wiki
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 deleted
* 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?
>
> - Do
d any 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
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
> &
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?
ghtdm, 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 par
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
t; (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//.xsess
r instance, 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
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 2005-02-27
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 conf
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 differ
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).
>
> Yo
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
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 th
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
On Mon, 15 Sep 2014 15:07:48 +0800
Bret Busby wrote:
> On 15/09/2014, Chen Wei 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 15/09/2014, Chen Wei 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
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 necessar
Bret Busby 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 had known
> earlie
Bret Busby 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: You could try nemo
\.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 descripto
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
t).
>>
>> 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 at zero size hasn't
> reclaimed the disk space?
>
> What does df -h show?
>
I think th
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 /h
g to reboot 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?
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing t
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 op
On 10/09/2014, Brian 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, be
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,
> s
age 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
>&
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---
he 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
--
"If you're not careful, the newspapers
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
> .xsessio
file size to content 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 logro
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 in
> > 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
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.
https://bugs.debian.org/cgi-bi
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
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
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
ibgtop2-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
--
Paul Cartwright
Registered Linux User #367800 and new counte
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 ?
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 wh
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
tem is updated
> 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 &
s 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
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 ve
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&#x
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
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 | w
ID 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 & it looks like a gtk version error, but that was a
different distro I think.
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 colli
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 **:
report.cgi?bug=287876) whereas
> >> currently, 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.
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
ME at $(date)"
>
> and the contents of it are, unsurprisingly:
>
> "Xsession: 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 yo
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/cg
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.
>
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
>
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
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.cg
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 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
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 a
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 of
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:
http://bugs.debian.or
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 subje
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]
I have Debian Lenny updated all the time, why do I get this error??
LibClamAV Warning: ***
LibClamAV Warning: *** This version of the ClamAV engine is outdated. ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/f
Hi Raju,
On 6/7/08, Kamaraju S Kusumanchi <[EMAIL PROTECTED]> wrote:
> Manon Metten wrote:
>
> > The only problem I have lately is Firefox 2.0.0.14 crashing regularly.
> > Everything else is running fine.
>
> No. The opcode errors do not correspond to the firefox crashes. The best way
> to trac
?
To my surprise I'm back to where I've started from.
Yesterday I renamed '/usr/share/fonts/X11/Type1', to
'/usr/share/fonts/X11/Type1-old', then deleted '~/.xsession-errors',
logged out and back in to KDE, just to find an empty .xsession-errors
file (well, alm
Manon Metten wrote:
> Hi Michelle,
>
> On 6/8/08, Michelle Konzack <[EMAIL PROTECTED]> wrote:
>> Hi Manon,
>>
>> Am 2008-06-07 02:16:31, schrieb Manon Metten:
>>
>> > On 6/6/08, Michelle Konzack <[EMAIL PROTECTED]> wrote:
>> > > > xset: bad font path element (#71), possible causes are:
>> > >
Hi Michelle,
On 6/8/08, Michelle Konzack <[EMAIL PROTECTED]> wrote:
> Hi Manon,
>
> Am 2008-06-07 02:16:31, schrieb Manon Metten:
>
> > On 6/6/08, Michelle Konzack <[EMAIL PROTECTED]> wrote:
> > > > xset: bad font path element (#71), possible causes are:
> > > > Directory does not exist o
Hi Manon,
Am 2008-06-07 02:16:31, schrieb Manon Metten:
> On 6/6/08, Michelle Konzack <[EMAIL PROTECTED]> wrote:
> > > xset: bad font path element (#71), possible causes are:
> > > Directory does not exist or has wrong permissions
> > > Directory missing fonts.dir
> > > Incorrect f
Hi again,
Am 2008-06-05 19:05:55, schrieb Manon Metten:
> QFont::setPointSize: Point size <= 0 (-3)
OK, there is a program which try to set an FontSize of "-3" which can
not exist. We can try to locate it with:
grep 'attempt to access private resource denied' /usr/bin/*
grep --recursiv
Hi Raju
On 6/7/08, Kamaraju S Kusumanchi <[EMAIL PROTECTED]> wrote:
> Manon Metten wrote:
>
> >
> > The only problem I have lately is Firefox 2.0.0.14 crashing regularly.
> > Everything else is running fine.
>
>
> No. The opcode errors do not correspond to the firefox crashes. The best way
> t
Manon Metten wrote:
>
> The only problem I have lately is Firefox 2.0.0.14 crashing regularly.
> Everything else is running fine.
No. The opcode errors do not correspond to the firefox crashes. The best way
to track down the iceweasel crashes is to disable all the add-ons and start
iceweasel in
Hi Michelle,
On 6/6/08, Michelle Konzack <[EMAIL PROTECTED]> wrote:
> > xset: bad font path element (#71), possible causes are:
> > Directory does not exist or has wrong permissions
> > Directory missing fonts.dir
> > Incorrect font server address or syntax
>
>
> Can you show us t
1 - 100 of 135 matches
Mail list logo
