Re: Logs like .xsession-errors
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 upper right > > corner of any Debian wiki page and clicked the "Text" button. > I had in mind some moment before you learned that > errors may appear in ~/.xsession-errors, so you could not use it as a > keyword in search queries. It did not come to me to look in the wiki for information how to debug fvwm problems. > > The only helpful match is > > https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value > > =.xsession-errors&fullsearch=Text > I assume it is > https://wiki.debian.org/TroubleShooting I should copy before i paste. Further i should give JigdoOnLive, XorrisoDdTarget, RepackBootableISO, and MergeDebianIsos a test run, whether they are still up to date. They are not overly prone to release changes because the topics are rather inert. The overall structure of Debian ISOs is among the most conservative aspects of the Debian GNU/Linux project. (Nearly all other distros got new ISO boot lure layouts during the years. The last big change in Debian amd64 ISOs was support for EFI in Debian 7.) > and certainly it lacks details how to obtain error messages. Yeah. I agree with you and Greg Wooledge. But i have few experience with the new stuff and changes which would have to be added to that wiki page. Have a nice day :) Thomas
Re: Logs like .xsession-errors, was: fvwm on Debian 12: Modules do not start ...
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 Debian wiki page and clicked the "Text" button. https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text Sorry, I was not clear. I had in mind some moment before you learned that errors may appear in ~/.xsession-errors, so you could not use it as a keyword in search queries. It is not uncommon on this mailing list when users, asking for help, have no idea where error messages may be found. I am curious if they will have a chance to discover debugging recipes if they are documented. The only helpful match is https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text I assume it is https://wiki.debian.org/TroubleShooting and certainly it lacks details how to obtain error messages. Perhaps links to similar pages from other distributions may become an improvement.
Re: Logs like .xsession-errors, was: fvwm on Debian 12: Modules do not start ...
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? >... >If you're doing something with your window manager or other X client >programs, then their output probably won't be visible to you >immediately. The location of their output will depend on how you >started X. If you used startx(1) from a console, the output probably >appeared on that console (try Ctrl-Alt-F1 to get back to it, then >Alt-F7 (usually) to get back to X). If you logged in with xdm(8), then >xdm creates a file called .xsession-errors in your home directory, and >you should look there. gdm(8) uses .gnome-errors. The other "*dm" >programs may have similar files." There's some outdated info in that paragraph. In Debian, startx uses /etc/X11/Xsession (among many other files), which redirects all output to ~/.xsession-errors if it can. ~/.xsession-errors has been the standard place to look for WM and X client errors for so long that I can't even remember where I first learned about it. Also, it's unlikely you'll be able to "get back to" the underlying console from which you ran startx in a modern version of Debian. I want to say... since jessie? Whenever the big X server changes occurred. Ever since then, on most systems, the X server runs in the same TTY where startx was typed, instead of opening a new TTY. This is actually really good, security-wise, because it means someone can't walk up to your machine, press Ctrl-Alt-F1, and then use Ctrl-C or Ctrl-Z to kill or suspend your X session and get control of your shell. That used to be a possibility.
Logs like .xsession-errors, was: fvwm on Debian 12: Modules do not start ...
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 page and clicked the "Text" button. https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text The only helpful match is https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text "What Does The Log Say? ... If you're doing something with your window manager or other X client programs, then their output probably won't be visible to you immediately. The location of their output will depend on how you started X. If you used startx(1) from a console, the output probably appeared on that console (try Ctrl-Alt-F1 to get back to it, then Alt-F7 (usually) to get back to X). If you logged in with xdm(8), then xdm creates a file called .xsession-errors in your home directory, and you should look there. gdm(8) uses .gnome-errors. The other "*dm" programs may have similar files." But i simply should have remembered that olde file or have looked for ~/.x* rather than only for ~/.X* as i did. The wiki page asks "Am I Alone?" Surely not. Time is a harsh mistress. > https://0pointer.de/blog/projects/journalctl.html I suffer substantial stack pain ... Have a nice day :) Thomas
Re: The .xsession-errors problem
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 the file at that point and it started > >> grow again. > > > > Amateur. I found a 24 GB .xsession-errors once, on a 30 GB filesystem. > > 423 million lines. > > That is some log file. One would probably want to introduce it to the > nice /dev/null device: > > ln -sf /dev/null ~/.xsession-errors > > Graphical programs are sometimes really noisy when started from command > line. And there are various output lines related to dbus, kdeinit5 and > other fancy desktop stuff which nobody understands anymore. > Also, verify that Debug Mode is not set. (I once did that with the Linux Kernel, years ago, and it filled up the Partition!) Kenneth Parker
Re: The .xsession-errors problem
* 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. I found a 24 GB .xsession-errors once, on a 30 GB filesystem.
> 423 million lines.
That is some log file. One would probably want to introduce it to the
nice /dev/null device:
ln -sf /dev/null ~/.xsession-errors
Graphical programs are sometimes really noisy when started from command
line. And there are various output lines related to dbus, kdeinit5 and
other fancy desktop stuff which nobody understands anymore.
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450
signature.asc
Description: PGP signature
Re: The .xsession-errors problem
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 you just delete it when you happen to notice it's too big? > > - Do you configure some rotating system, perhaps with logrotate(8)? > (Why doesn't Debian have this automatically?) > > - Do you add it to your backup system's ignore list so that a > potentially big file doesn't fill your backups? > > - What do Debian documentation and faq lists teach about maintaining > this potentially huge file? > > - Why is it normal that in Debian (and GNU/Linux) you need to manually > delete a hidden file to keep it from filling your hard disks? > > Note that I'm not necessarily looking for help but different views are > welcome. I'm mostly interested in the phenomenon that there still is > this well-known indefinitely growing file and seemingly no automatic > rotation. > > 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. I found a 24 GB .xsession-errors once, on a 30 GB filesystem. 423 million lines. Most of them the same: (indicator-weather:2201): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_build_variant: assertion `DBUSMENU_IS_MENUITEM(mi)' failed Buggy crap can fill it up pretty fast.
Re: The .xsession-errors problem
On Fri, 30 Oct 2020 at 05:27, Curt wrote:
> 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 "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:
>
> priv->log_filename = g_strdup (".xsession-errors");
>
> src/log-file.c:
>
> old_filename = g_strdup_printf ("%s.old", log_filename);
And the rename occurs in the next line in log-file.c:
rename (log_filename, old_filename);
So now we know that log rotation is done by the
lightdm package:
https://sources.debian.org/src/lightdm/1.26.0-7/src/log-file.c/?hl=28#L28
Thanks Curt!
Re: The .xsession-errors problem
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 "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:
priv->log_filename = g_strdup (".xsession-errors");
src/log-file.c:
old_filename = g_strdup_printf ("%s.old", log_filename);
Re: The .xsession-errors problem
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/" > > > > > (Script improvements always appreciated.) > > > https://www.shellcheck.net says: > > """ > > Line 2: > > [ $? -ne 0 ] && echo hi > > ^-- SC2181: Check exit code directly with e.g. 'if mycmd;', not > > indirectly with $?. > > """ > > In other words, instead of writing: > > fuser -v thing > [ $? != 0 ] && other thing && third thing > > You can write it this way: > > if ! fuser -v thing; then > other thing && > third thing > fi > > The $? form isn't technically *wrong*, but it's awkward, and doesn't > let you have an "else" action. Thanks to you both for reminding me of shellcheck. I think I've got a few of these to correct in .bashrc too. Running shellcheck on .bashrc is always a horror show. Ironically, though, there is one slight advantage to the explicit test of $? in my .xsession (because it's run with set -x in force): the result of the test is reflected in the log. With the improved construction, the result has to be deduced by checking which subsequent commands run (or which branch is taken when there's an else clause). Cheers, David.
Re: The .xsession-errors problem
On Thu, 29 Oct 2020 at 05:33, Celejar wrote: > On Wed, 28 Oct 2020 15:28:37 +1100 David wrote: > > 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 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 anything here. The file is created fresh at each boot and is > > > > > 30 lines long [...] > > > > Something that you're doing, or something that was done for you, is > > > > clearing that file. Your case is not the default. By default, that > > > > file is never cleared, and just keeps growing. Most people prune it > > > > manually whenever they notice it getting bigger than they like, which > > > > is usually somewhere between "once a year" and "never". > > > On my system the file is rotated (renamed to .xsession-errors.old), on > > > every login as far as I can tell. > > > Didn't find (yet) what is doing this (using lightdm, LXDE and minimal > > > Xorg). > > I investigated, guided by this teaching from Reco: > > https://lists.debian.org/debian-user/2020/04/msg00583.html > > I found that the process that renames the file to .xsession-errors.old > > is the binary /usr/bin/lxsession owned by the user, with the parent > > process lightdm owned by root. > Interesting, but there seems to be more to the story than this. I use > xfce4 with lightdm, and I also have my .xsession-errors moved > to .xsession-errors.old when I log in via lightdm, even though I'm not > using lxde and lxsession doesn't exist on my system. I haven't tried > the audit method to see what's doing it. 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 "ERRFILE" or any logfile except "~/.cache/lxsession/LXDE/run.log". The audit command I used was: # auditctl -a always,exit -F path=/home/david/.xsession-errors.old -F perm=wa It was quite easy to do. Below is the audit logging. The unusual mountpoint is just a shared data LVM volume "hart". /home is a symlink: /home -> /mnt/hart/home/d10 type=SYSCALL msg=audit(1603857141.131:195): arch=c03e syscall=82 success=yes exit=0 a0=55760a959520 a1=55760a961470 a2=0 a3=6 items=5 ppid=4477 pid=4482 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=14 com type=CWD msg=audit(1603857141.131:195): cwd="/mnt/hart/home/d10/david" type=PATH msg=audit(1603857141.131:195): item=0 name="/mnt/hart/home/d10/david" inode=527148 dev=fd:02 mode=040750 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp= cap_fi= cap_fe=0 cap_fver=0 type=PATH msg=audit(1603857141.131:195): item=1 name="/mnt/hart/home/d10/david" inode=527148 dev=fd:02 mode=040750 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp= cap_fi= cap_fe=0 cap_fver=0 type=PATH msg=audit(1603857141.131:195): item=2 name=".xsession-errors" inode=527158 dev=fd:02 mode=0100600 ouid=1000 ogid=1000 rdev=00:00 nametype=DELETE cap_fp= cap_fi= cap_fe=0 cap_fver=0 type=PATH msg=audit(1603857141.131:195): item=3 name=".xsession-errors.old" inode=527157 dev=fd:02 mode=0100600 ouid=1000 ogid=1000 rdev=00:00 nametype=DELETE cap_fp= cap_fi= cap_fe=0 cap_fver=0 type=PATH msg=audit(1603857141.131:195): item=4 name=".xsession-errors.old" inode=527158 dev=fd:02 mode=0100600 ouid=1000 ogid=1000 rdev=00:00 nametype=CREATE cap_fp= cap_fi= cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1603857141.131:195): proctitle=6C69676874646D002D2D73657373696F6E2D6368696C64003132003231 I didn't save proof, but ppid=4477 was lightdm and pid=4482 was /usr/bin/lxsession. It occurs to me now that I didn't yet look for a rename of dev=fd:02 (which perhaps would be inherited from lightdm) in the lxsession code, so maybe that's what happens. I'm just doing this as a learning exercise so am sharing this intermediate information here.
Re: The .xsession-errors problem
On Wed, 28 Oct 2020 15:28:37 +1100 David wrote: > 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 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 anything here. The file is created fresh at each boot and is > > > > 30 lines long [...] > > > > Something that you're doing, or something that was done for you, is > > > clearing that file. Your case is not the default. By default, that > > > file is never cleared, and just keeps growing. Most people prune it > > > manually whenever they notice it getting bigger than they like, which > > > is usually somewhere between "once a year" and "never". > > > On my system the file is rotated (renamed to .xsession-errors.old), on > > every login as far as I can tell. > > > Didn't find (yet) what is doing this (using lightdm, 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 LXDE. > > I investigated, guided by this teaching from Reco: > https://lists.debian.org/debian-user/2020/04/msg00583.html > > I found that the process that renames the file to .xsession-errors.old > is the binary /usr/bin/lxsession owned by the user, with the parent > process lightdm owned by root. > > /usr/bin/lxsession is a component of LXDE, so this won't apply to > users of other GUI providers. > > The rename occurs when the user logs in from lightdm. The filename > .xsession-errors is defined in the script file /etc/X11/Xsession Interesting, but there seems to be more to the story than this. I use xfce4 with lightdm, and I also have my .xsession-errors moved to .xsession-errors.old when I log in via lightdm, even though I'm not using lxde and lxsession doesn't exist on my system. I haven't tried the audit method to see what's doing it. Celejar
Re: The .xsession-errors problem
On Mi, 28 oct 20, 15:28:37, David wrote: > On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU wrote: > > > On my system the file is rotated (renamed to .xsession-errors.old), on > > every login as far as I can tell. > > > Didn't find (yet) what is doing this (using lightdm, 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 LXDE. > > I investigated, guided by this teaching from Reco: > https://lists.debian.org/debian-user/2020/04/msg00583.html > > I found that the process that renames the file to .xsession-errors.old > is the binary /usr/bin/lxsession owned by the user, with the parent > process lightdm owned by root. > > /usr/bin/lxsession is a component of LXDE, so this won't apply to > users of other GUI providers. > > The rename occurs when the user logs in from lightdm. The filename > .xsession-errors is defined in the script file /etc/X11/Xsession Indeed, I tried 'startx' and the file wasn't rotated, so it must be something about how lightdm starts the LXDE session. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: The .xsession-errors problem
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 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 anything here. The file is created fresh at each boot and is > > > 30 lines long [...] > > Something that you're doing, or something that was done for you, is > > clearing that file. Your case is not the default. By default, that > > file is never cleared, and just keeps growing. Most people prune it > > manually whenever they notice it getting bigger than they like, which > > is usually somewhere between "once a year" and "never". > On my system the file is rotated (renamed to .xsession-errors.old), on > every login as far as I can tell. > Didn't find (yet) what is doing this (using lightdm, 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 LXDE. I investigated, guided by this teaching from Reco: https://lists.debian.org/debian-user/2020/04/msg00583.html I found that the process that renames the file to .xsession-errors.old is the binary /usr/bin/lxsession owned by the user, with the parent process lightdm owned by root. /usr/bin/lxsession is a component of LXDE, so this won't apply to users of other GUI providers. The rename occurs when the user logs in from lightdm. The filename .xsession-errors is defined in the script file /etc/X11/Xsession
Re: The .xsession-errors problem
On Tuesday, October 27, 2020 11:05:31 AM Teemu Likonen wrote: > * 2020-10-26 20:04:55+03, Reco wrote: > > On Mon, Oct 26, 2020 at 06:35:45PM +0200, Teemu Likonen wrote: > >> - Do you configure some rotating system, perhaps with logrotate(8)? > >> > >> (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//.xsession-errors Back in some day, the .xsession-errors was growing by, iirc, multiple messages every second. (This might have been in Debian Wheezy, or a Debian before Wheezy, or even in a version of Mandrake / Mandriva.)
Re: The .xsession-errors problem
* 2020-10-26 20:04:55+03, Reco wrote:
> On Mon, Oct 26, 2020 at 06:35:45PM +0200, Teemu Likonen wrote:
>> - Do you configure some rotating system, perhaps with logrotate(8)?
>> (Why doesn't Debian have this automatically?)
>
> For Debian, it may work. For RHEL, for 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 for the file. So far the
simplest seems to be adding /etc/logrotate.d/my-xession-errors with
contents like below. Logrotate uses the same owner and permissions as
the original file. Nothing else is needed.
/home/*/.xsession-errors {
rotate 3
monthly
compress
notifempty
}
Logrotate could be used as normal user. For my personal system it's
probably too complicated for such a small thing but there could be
configuration file like this:
# Xsession-logrotate.conf
~/.xsession-errors {
rotate 3
monthly
compress
notifempty
}
Xsession script could run a command like this:
/usr/sbin/logrotate \
--state "$HOME/.local/var/lib/logrotate/status" \
/etc/X11/Xsession-logrotate.conf
On the other hand all this is probably too complicated because the
.xsession-errors file is not that interesting. People have small
additions in their /etc/X11/Xsession script: delete the file every time
or move the old file to ".old". That would be good enough, I think.
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450
signature.asc
Description: PGP signature
Re: The .xsession-errors problem
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 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 anything here. The file is created fresh at each boot and is > > 30 lines long [...] > > Something that you're doing, or something that was done for you, is > clearing that file. Your case is not the default. By default, that > file is never cleared, and just keeps growing. Most people prune it > manually whenever they notice it getting bigger than they like, which > is usually somewhere between "once a year" and "never". On my system the file is rotated (renamed to .xsession-errors.old), on every login as far as I can tell. Didn't find (yet) what is doing this (using lightdm, LXDE and minimal Xorg). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: The .xsession-errors problem
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 talked about it. What do you do to maintain this file? > > Don't do anything here. The file is created fresh at each boot and is > 30 lines long [...] Something that you're doing, or something that was done for you, is clearing that file. Your case is not the default. By default, that file is never cleared, and just keeps growing. Most people prune it manually whenever they notice it getting bigger than they like, which is usually somewhere between "once a year" and "never".
Re: The .xsession-errors problem
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: > """ > Line 2: > [ $? -ne 0 ] && echo hi > ^-- SC2181: Check exit code directly with e.g. 'if mycmd;', not > indirectly with $?. > """ In other words, instead of writing: fuser -v thing [ $? != 0 ] && other thing && third thing You can write it this way: if ! fuser -v thing; then other thing && third thing fi The $? form isn't technically *wrong*, but it's awkward, and doesn't let you have an "else" action.
Re: The .xsession-errors problem
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 ] && echo hi """ https://www.shellcheck.net says: """ Line 2: [ $? -ne 0 ] && echo hi ^-- SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?. """ https://github.com/koalaman/shellcheck/wiki/SC2181 says: """ Running a command and then checking its exit status $? against 0 is redundant. Instead of just checking the exit code of a command, it checks the exit code of a command (e.g. [) that checks the exit code of a command. """
Re: The .xsession-errors problem
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? > > - Do you just delete it when you happen to notice it's too big? > > - Do you configure some rotating system, perhaps with logrotate(8)? > (Why doesn't Debian have this automatically?) > > - Do you add it to your backup system's ignore list so that a > potentially big file doesn't fill your backups? > > - What do Debian documentation and faq lists teach about maintaining > this potentially huge file? > > - Why is it normal that in Debian (and GNU/Linux) you need to manually > delete a hidden file to keep it from filling your hard disks? > > Note that I'm not necessarily looking for help but different views are > welcome. I'm mostly interested in the phenomenon that there still is > this well-known indefinitely growing file and seemingly no automatic > rotation. > > 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. I have a collection of dotfiles that I cope with in different ways. I've always started X from a bash function, and that used to truncate .xsession-errors with >| unless there was an argument, when it would cat a zzzyyyxxx $HOSTNAME $(date +%Y-%m-%d-%H%M%S) marker with >>. Nowadays, however, some of my machines are capable of running more than one instance of X, and I sometimes look back at an earlier log, so I've put the following into .xsession: Displaynumber="$(sed -e 's/://g;' <<<"$DISPLAY")" [ … there's a short sleep in here for an unrelated purpose … ] for j in $HOME/.xsession-errors-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]-[0-9]; do fuser -v "$j" [ $? -ne 0 ] && gzip "$j" && mv -i "$j.gz" "$HOME/.monitors/xsession/" done Xsessionlogname="$HOME/.xsession-errors-$(date +%s)-$Displaynumber" Xsessionloglink="$HOME/.xsession-log-$Displaynumber" mv -i "$HOME/.xsession-errors" "$Xsessionlogname" rm -f "$Xsessionloglink" ln -s "$Xsessionlogname" "$Xsessionloglink" In the six months since I acquired this AiO as my main machine, $ ls -1 .monitors/xsession/.xsession-errors-* | wc -l 205 $ zcat .monitors/xsession/.xsession-errors-* | wc -c 3734959 $ Because of past troubles, I also log CPU temperature and battery charge where available, and ping the router. The first two rotate themselves at midnight as the filenames include the date; the ping output just overwrites its output file. Finally, I log the fvwm output, but only with one level of backup~. I don't let the system have anything to do with my own logs etc partly because the real /home doesn't get mounted until I get around to unlocking it. (Script improvements always appreciated.) Cheers, David.
Re: The .xsession-errors problem
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
Re: The .xsession-errors problem
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 anything here. The file is created fresh at each boot and is 30 lines long with the final line: ** Message: 19:36:19.712: main.vala:134: log path: /home/tixy/.cache/lxsession/LXDE/run.log Looking at the file mentioned there it seems to have the normal assortment or error messages and warnings, with the first entry being from my latest boot/session login. It's 23k bytes in size. I guess as I never hibernate my laptop and turn it off every day, it never gets to an annoying size. -- Tixy
Re: The .xsession-errors problem
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 here, too: ~$ du -sh .xsession-errors 16M .xsession-errors - Do you just delete it when you happen to notice it's too big? I think that would be my approach, given that it seems to grow slowly here. First entry is from 30 Sep 2018 :) - Do you configure some rotating system, perhaps with logrotate(8)? (Why doesn't Debian have this automatically?) I think the policy against having an automatism is to avoid changing the home directory contents by anything else than explicitly user-invoked applications. - Do you add it to your backup system's ignore list so that a potentially big file doesn't fill your backups? I do not include /home in my backups at all (except for some specific subtrees) because there are a lot of applications writing unneeded files there. Consider the various recently-used-lists, cache files, thumbnails, GUI settings, trash folders whatever. Nothing to backup for me there. I opt to keep my data on an entirely different directory structure as to avoid applications dumping their files next to my personal data. [...] - Why is it normal that in Debian (and GNU/Linux) you need to manually delete a hidden file to keep it from filling your hard disks? There seem to be other areas that are constantly growing, too. APT downloaded package files come to mind. For /home-structures it is usually up to the user to fix it whereas the system-wide "growths" are better handled by the admin... [...] Just my thoughts, YMMV Linux-Fan öö pgpLpRPvm4i5V.pgp Description: PGP signature
Re: The .xsession-errors problem
* 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. There are ideas about /etc/X11/Xsession script too. Debian developers certainly can fix this if they want. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 signature.asc Description: PGP signature
Re: The .xsession-errors problem
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 delete it when you happen to notice it's too big? > > - Do you configure some rotating system, perhaps with logrotate(8)? > (Why doesn't Debian have this automatically?) > > - Do you add it to your backup system's ignore list so that a > potentially big file doesn't fill your backups? I simply truncate it in my ~/.xsession file, since I don't care what's in it once my session has ended. Maybe this has some side effects when starting multiple sessions, but I rarely do that and so far did not have any problems. > - What do Debian documentation and faq lists teach about maintaining > this potentially huge file? > > - Why is it normal that in Debian (and GNU/Linux) you need to manually > delete a hidden file to keep it from filling your hard disks? > > Note that I'm not necessarily looking for help but different views are > welcome. I'm mostly interested in the phenomenon that there still is > this well-known indefinitely growing file and seemingly no automatic > rotation. If you have a good idea how to fix that, please send it to bug #287876[1] or one of its siblings. Cheers, Sven 1. https://bugs.debian.org/287876
Re: The .xsession-errors problem
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 this file? > > - Do you just delete it when you happen to notice it's too big? I used custom logrotate config, and then it dawned on me (see below). > - Do you configure some rotating system, perhaps with logrotate(8)? > (Why doesn't Debian have this automatically?) For Debian, it may work. For RHEL, for 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. > - Do you add it to your backup system's ignore list so that a > potentially big file doesn't fill your backups? Nope, there's no need to. > - What do Debian documentation and faq lists teach about maintaining > this potentially huge file? Prevent such writes in the first place. Hack /etc/X11/Xsession, replace logging to a file to logging to syslog. A simple one-liner will do: exec 1> >(/usr/bin/logger -e -t xsession-$USER -p user.notice) 2>&1 If you don't need all these extra messages in /var/log/messages - just write a simple rsyslogd filter. > - Why is it normal that in Debian (and GNU/Linux) you need to manually > delete a hidden file to keep it from filling your hard disks? I fail to see the difference between .xsession-errors and some user-run (cr)application logfile. Both can fill all the filesystem that you're throwing at it. Reco
The .xsession-errors problem
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 some rotating system, perhaps with logrotate(8)? (Why doesn't Debian have this automatically?) - Do you add it to your backup system's ignore list so that a potentially big file doesn't fill your backups? - What do Debian documentation and faq lists teach about maintaining this potentially huge file? - Why is it normal that in Debian (and GNU/Linux) you need to manually delete a hidden file to keep it from filling your hard disks? Note that I'm not necessarily looking for help but different views are welcome. I'm mostly interested in the phenomenon that there still is this well-known indefinitely growing file and seemingly no automatic rotation. 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. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 signature.asc Description: PGP signature
.xsession-errors
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? Missing packages? Thanks in advance for any help Greg
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
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 same with your exec command -- there's no difference in >> working. > > Opening one end of a FIFO blocks until the OTHER end is also opened. > This is why the first process to open the FIFO should be launched in > the background (it is going to block), if both ends are coming from the > same parent script. > I just realized that. I have some other FIFO devices that rsyslog uses, and based on that I thought rsyslog just sends messages to the FIFO devices because it was working just fine (without any additional steps, except creating the FIFO device), but it turns out that rsyslog has its own queues that buffer the messages, and when I "cat" the FIFO devices later on, rsyslog sends what's in the queues and I get the output in the desktop terminal. The same with systemd FIFO sockets -- they also have queues to buffer messages, and they pass them when I "cat" the FIFO device. So that's basically the difference between rsyslog/systemd sockets and manually created FIFO devices, and now I get why this didn't work OOTB, and why it won't work without some additional steps. :) > I'm assuming that when you speak of "cat" you mean a process that opens > the FIFO for reading. > Yes. signature.asc Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
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 difference in > working. Opening one end of a FIFO blocks until the OTHER end is also opened. This is why the first process to open the FIFO should be launched in the background (it is going to block), if both ends are coming from the same parent script. I'm assuming that when you speak of "cat" you mean a process that opens the FIFO for reading.
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
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). > > You need to run something in the background which opens the FIFO for > reading before you run foreground commands that try to open the FIFO > for writing. > > Typically you would create the FIFO, then launch the reader (logger) > in the background, then carry on with opening FIFO writers. > So basically, the systemd's solution (in the first message) is the only one that will work OOTB without any other additional steps, right? signature.asc Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
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 after a
>> few hours it's around 20-30 MiB, and the content of the file isn't removed
>> with
>> each X session restart.
>
> I personally do this:
>
> DATE=$(date "+%Y%m%d_%H%M%S")
> # track xsession errors
> mv ~/.xsession-errors ~/.xsession-errors_${DATE};
> ln -sf ~/.xsession-errors_${DATE} ~/.xsession-errors-current;
> # delete old xsession error files
> find ~/ -maxdepth 1 -mindepth 1 -type f \
> -iname '.xsession-errors_*' -ctime +30 -delete;
>
> in my .xsession.[1]
>
>> Is it even possible to redirect the content of the file to the FIFO device in
>> this way?
>
> The general way to do this is to do re-exec the shell with different
> output options, something like this:
>
> exec > /dev/log-xsession-errors 2>&1;
>
> in your .xsession [or whatever you're using to start things] after
> testing that the FIFO works.
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 difference in
working.
>
> 1: https://git.donarmstrong.com/x_base.git/b/.xsession
>
signature.asc
Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
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 the file isn't removed
> with
> each X session restart.
I personally do this:
DATE=$(date "+%Y%m%d_%H%M%S")
# track xsession errors
mv ~/.xsession-errors ~/.xsession-errors_${DATE};
ln -sf ~/.xsession-errors_${DATE} ~/.xsession-errors-current;
# delete old xsession error files
find ~/ -maxdepth 1 -mindepth 1 -type f \
-iname '.xsession-errors_*' -ctime +30 -delete;
in my .xsession.[1]
> Is it even possible to redirect the content of the file to the FIFO device in
> this way?
The general way to do this is to do re-exec the shell with different
output options, something like this:
exec > /dev/log-xsession-errors 2>&1;
in your .xsession [or whatever you're using to start things] after
testing that the FIFO works.
1: https://git.donarmstrong.com/x_base.git/b/.xsession
--
Don Armstrong https://www.donarmstrong.com
I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
-- Douglas Adams _The Long Dark Tea-Time of the Soul_
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
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 the FIFO for reading before you run foreground commands that try to open the FIFO for writing. Typically you would create the FIFO, then launch the reader (logger) in the background, then carry on with opening FIFO writers.
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
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 started inside of the X session. I'm just >> wondering whether similar solution can be achieved without systemd. > > You might consider adding one file in /etc/X11/Xsession.d which does your > trick. Those files are sourced *after* the exec >> "$ERRFILE"... Could you tell me what in your opinion I should do because I'm a little bit confused. 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). If I put "exec ..." in some file under the /etc/X11/Xsession.d/ dir (commenting it out from the main Xsession script), the X session won't start either because processing of the Xsession script will stall at the one of the sourced files where "exec ..." is found. So how do you want to do it? > > If you want to pass on whatever went to ERRFILE so-far, you might want to > "cat" it... > > Cheers > -- t > signature.asc Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
-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 X session. I'm just > wondering whether similar solution can be achieved without systemd. You might consider adding one file in /etc/X11/Xsession.d which does your trick. Those files are sourced *after* the exec >> "$ERRFILE"... If you want to pass on whatever went to ERRFILE so-far, you might want to "cat" it... Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlrHeo8ACgkQBcgs9XrR2kYN6ACbB0UFWHJgqez7STDs3yHANzUk umkAnReZT+TrILnl6jINpjjwEOkd5WnH =120Y -END PGP SIGNATURE-
How to redirect messages in ~/.xsession-errors to a FIFO device?
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 of it, I installed the SDDM login manager. I haven't really finished the migration process yet, but since SDDM looks better than LightDM, I wanted to replace it. Unfortunately, the ~/.xsession-errors file grows in size, and after a few hours it's around 20-30 MiB, and the content of the file isn't removed with each X session restart. In the /etc/X11/Xsession file, there's something like this: --- ERRFILE=$HOME/.xsession-errors ... exec >>"$ERRFILE" 2>&1 --- Since I'm using FIFO devices for some rsyslog logs, I thought I also could use one of such devices for the ~/.xsession-errors file content, but changing the ERRFILE variable to some /dev/log-fifo device causes the start of the X session to stall -- it hangs since the FIFO device needs (probably) some process to read the content of the device, for instance, "cat /dev/log-fifo", but unfortunately I can't add anything in the script after the above command so it could "cat" the device (it works when I do it via TTY). Is it even possible to redirect the content of the file to the FIFO device in this way? I'm asking because I temporary created the following systemd .socket file: ----- # cat /etc/systemd/system/log-xsession-errors.socket [Unit] Description=log-xsession-errors socket DefaultDependencies=no Before=sockets.target PartOf=log-xsession-errors.service [Socket] ListenFIFO=/dev/log-xsession-errors SocketMode=0600 SocketUser=morfik SocketGroup=morfik RemoveOnStop=true PipeSize=1M [Install] WantedBy=sockets.target - And some service for it: - # cat /etc/systemd/system/log-xsession-errors.service [Unit] Description=log-xsession-errors service DefaultDependencies=no [Service] ExecStart=/bin/true RemainAfterExit=yes [Install] Also=log-xsession-errors.socket - And in this solution, systemd creates the device and starts some process to listen on it, and there's no problem with starting the X session because as soon as some X messages show up, they're sent to the FIFO device, and that device has 1 MiB buffer set, and probably that's why it can hold the messages for some time till a terminal with "cat" is started inside of the X session. I'm just wondering whether similar solution can be achieved without systemd. -- Morfik signature.asc Description: OpenPGP digital signature
Re: Query about .xsession-errors file
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. > >> > >> entries from before the current boot session) entries, so as to > >> reduce the file size to content that is necessary to retain for > >> debugging? > >> > > > > If debugging is not required, redirect xsession error to /dev/null > > is another option. > > > > in /etc/X11/Xsession, find the line: > > > > exec >>"$ERRFILE" 2>&1 > > > > change it to: > > > > exec >>/dev/null 2>&1 > > > > -- > > Chen Wei > > > > > > Hello. > > At this time, after doing what I had done, that I had previously > stated, the file is still at zero bytes, so I think that it is > probably better, to leave the error handling as it is, and, monitor it > daily, to detect any change, and then, act on any changes to the file. > > However, thank you for the suggestion, which I shall retain for future > consideration. > > If you do not want it to disappear altogether, you can just prune it. I have this in my ¨/home//.bash_profile¨ file: # prune the ~/.xsession-errors file if it grows beyond 1Mb if [ $(du -b ~/.xsession-errors | cut -f1) -gt 1048576 ]; then KEEP_LINES="$(tail -n 100 ~/.xsession-errors)" echo "$KEEP_LINES" > ~/.xsession-errors fi Keeps it under control but still usable. cheers, greywolf -- It is about the Dragons - it was always about the Dragons! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916123918.17f58b2c@babylon
Re: Query about .xsession-errors file
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 reduce >> the file size to content that is necessary to retain for debugging? >> > > If debugging is not required, redirect xsession error to /dev/null is > another option. > > in /etc/X11/Xsession, find the line: > > exec >>"$ERRFILE" 2>&1 > > change it to: > > exec >>/dev/null 2>&1 > > -- > Chen Wei > > Hello. At this time, after doing what I had done, that I had previously stated, the file is still at zero bytes, so I think that it is probably better, to leave the error handling as it is, and, monitor it daily, to detect any change, and then, act on any changes to the file. However, thank you for the suggestion, which I shall retain for future consideration. -- Bret Busby Armadale West Australia .. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACX6j8OHzm+2cgRzd0s4VocQCtOWjmeTbLJ=+nzqxcw0eqk...@mail.gmail.com
Re: Query about .xsession-errors file
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 for debugging? > If debugging is not required, redirect xsession error to /dev/null is another option. in /etc/X11/Xsession, find the line: exec >>"$ERRFILE" 2>&1 change it to: exec >>/dev/null 2>&1 -- Chen Wei -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915003617.GA6856@localhost
Re: Query about .xsession-errors file
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 > earlier, could perhaps have been accomplished by the command "> > xsystem-errors", which, I assume, would have had the same effect. Hm, I would assume that this might be a (temporary) workaround and not a fix for the problem --- the problem being that a rather large error log is being created by some process(es). Next time you start the process(es), they'll probably re-create the log file, or another one. I'd recommend that you keep your eyes on it and try to actually fix the problem. Fixing it might involve filing a bug report along the lines of some process(es) writing to a log file in such a way that it grows indefinitely. In case you discover an endlessly growing log file again, you could change ownership to root and make it writable for root only in order to see whether some process complains or crashes. Generally, when you run out of disk space, you should get error messages like "no space left on device", and the process that tries to create a file would terminate eventually. However, I've seen running USB disks out of disk space which in turn became un-un-mountable, and the system (Ubuntu LTS) would even hang on reboot and had to be switched off (which IMO is a bug somewhere). -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mwf2i8z@yun.yagibdah.de
Re: Query about .xsession-errors file
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 instead of nautilus. PS: You could try seamonkey instead of opera. It behaves remarkably well. -- Knowledge is volatile and fluid. Software is power. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878ulr2j0u@yun.yagibdah.de
Re: Query about .xsession-errors file
On Wed, 10 Sep 2014, Bret Busby wrote: On 10/09/2014, david...@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 2366bret 54u REG8,8 01169162 /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 2366bret 54u REG8,8 01169162 /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 2366bret 54u REG8,8 01169162 /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 2366bret 54u REG8,8 01169162 /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 2366bret 54u REG8,8 01169162 /home/bret/.lo
Re: Query about .xsession-errors file
On 10/09/2014, david...@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 2366bret 54u REG8,8
01169162
/home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
"
Running ls -l, gives
"
:~$ ls -l .xsession-errors
-rw--- 1 bret bret 0 Sep 10 00:23 .xsession-errors
"
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.
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.
"
:~$ lsof |grep '\.xsession-errors'
nautilus 2366bret 54u REG8,8
01169162
/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
bret@bret-dd-workstation:~$ lsof |grep '\.xsession-errors'
nautilus 2366bret 54u REG8,8
01169162
/home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
bret@bret-dd-workstation:~$ lsof |grep '\.xsession-errors'
nautilus 2366bret 54u REG8,8
01169162
/home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
bret@bret-dd-workstation:~$ >
.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
bret@bret-dd-workstation:~$ lsof |grep '\.xsession-errors'
nautilus 2366bret 54u REG8,8
01169162
/home/bret/.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX
(deleted)
bret@bret-dd-workstation:~$ >
.local/share/Trash/info/.xsession-errors.trashinfo.H87KLX (deleted)
bash: syntax error near unexpected token `('
"
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
"
so, I do not know what that number 1169162, shown in the lsof output,
represents.
But, apart from what that number represents, as I have said, the
problem appears to have been disappeared.
--
Bret Busby
Armadale
West Australia
..
"So once you d
Re: Query about .xsession-errors file
On 10/09/2014, Chris Bannister wrote: > On Wed, Sep 10, 2014 at 12:36:42AM +0800, Bret Busby wrote: >> Before seeing the above message, after someone previously saying that >> deleting the file would not cause any (extra) problems, but would not >> free up disc space, I deleted the file, then ran "Empty Trash Can", >> but, no disc space was freed, then, subsequently, I observed that a >> new file had been created; >> .xsession-errors.old >> with a size of about 33kB, and so I overwrote that, as described >> above, and that reduced its size to zero, but, I now do not have the >> original file with which to do that, and, I have about 750MB of >> missing 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 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 believe, render the df -h output that would be produced now, inapplicable to the problem as it was. One of those things, is that, in further investigating the problem of having run out of disc space, and the progressive consumption of the disc space, in examining the files in my home directory, in order of "Date modified, including hidden files, I found that .opera/logs contained 47647 files, and thence, took up about 5.5GB of disc space, and, the directory seemed to contain only files of the name crash<0..9>.txt, which appeared to be redundant (some being from 2012), so I removed all of the files in that directory, then, emptied the trash, and, that all took a while (an hour or so, I think), and it freed up 5.5GB of space in my /home partition. Another thing that happened, is in relation to the xsyetm-errors file, itself. I think that I had mentioned, previously, that, upon my deleting that file, whilst the space was not freed, a new file appeared; xsystem-errors.old, which got up to about 33kB, and then it went back down to zero. That file was described, in the Type column of File Browser, as a backup file. So, I thought, in the context of what had been said, about open applications that had been using the xsystem-errors file, not releasing it, after it had been deleted, so it still existed, but was invisible to the user, I simply renamed the xsystem-errors.old file, to xsystem-errors (deleted the file extension .old), to find whether that would fix the problem. After a few hours sleep, when I checked the system, during daylight hours, the free space now shows as 6.1GB. 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 earlier, could perhaps have been accomplished by the command "> xsystem-errors", which, I assume, would have had the same effect. One of the things that could have helped, and, I have raised the suggestion on the LTS list (I have no idea, whether so doing, was appropriate), regarding the .opera/logs directory, is for the File Browser, in the Size column, to include the space used by each of the directories listed, rather than just the number of items contained, in each of the directories listed, in the Size column. I raised the suggestion on that list, as the File Browser is part (I believe) of GNOME2 (which has been abandoned by the GNOME people) running on Debian 6. I have no idea whether anyone on that list, is maintaining GNOME2, or, especially, the File Browser of GNOME2, and thence, whether it could be implemented for this operating system, but, I believe that it is something that could help with system administration, expecially, when disc space is found to progressively be consumed without knowing why it is progressively being consumed. -- Bret Busby Armadale West Australia .. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACX6j8OTqUsT5UHE4zafk7jfKNnZrcstv5=annywpvnfuj4...@mail.gmail.com
Re: Query about .xsession-errors file
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 but, when I did briefly examine the contents, hundreds of lines referring to QPaint problems, were shown. Historically in my experience lots of Qt and KDE programs were extremely verbose on stderr, often because they were built with some debug flag enabled. Depending on the nature of the QPaint messages, this might be the case. Either way, it's probably a severity: minor bug worth reporting if it hasn't already (this bug looks relevant: https://bugs.debian.org/598975 - I guess the thing to do is figure out which program is generating the messages.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1409091939250.30...@brutus.ling.ohio-state.edu
Re: Query about .xsession-errors file
On Wed, Sep 10, 2014 at 12:36:42AM +0800, Bret Busby wrote: > Before seeing the above message, after someone previously saying that > deleting the file would not cause any (extra) problems, but would not > free up disc space, I deleted the file, then ran "Empty Trash Can", > but, no disc space was freed, then, subsequently, I observed that a > new file had been created; > .xsession-errors.old > with a size of about 33kB, and so I overwrote that, as described > above, and that reduced its size to zero, but, I now do not have the > original file with which to do that, and, I have about 750MB of > missing 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 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 the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909222339.GA19835@tal
Re: Query about .xsession-errors file
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) > but, when I did briefly examine the contents, hundreds of lines referring to > QPaint problems, were shown. Historically in my experience lots of Qt and KDE programs were extremely verbose on stderr, often because they were built with some debug flag enabled. Depending on the nature of the QPaint messages, this might be the case. Either way, it's probably a severity: minor bug worth reporting if it hasn't already (this bug looks relevant: https://bugs.debian.org/598975 - I guess the thing to do is figure out which program is generating the messages.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909190858.ga25...@bryant.redmars.org
Re: Query about .xsession-errors file
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, before I deleted it, reference to 21 August, >> so, the file apparently, grows quite fast. > > This machine has been up for about the same length of time. > > brian@desktop:~$ ls -l .xsession-errors > -rw--- 1 brian brian 165780 Aug 24 08:39 .xsession-errors > > Has it dawned on you that an investigation of the file's contents > might be indicated? > > 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), but, when I did briefly examine the contents, hundreds of lines referring to QPaint problems, were shown. -- Bret Busby Armadale West Australia .. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cacx6j8pbpc_ssc5uy1whuyrgnaws+kpqy8noc0xpvotqbin...@mail.gmail.com
Re: Query about .xsession-errors file
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 quite fast. This machine has been up for about the same length of time. brian@desktop:~$ ls -l .xsession-errors -rw--- 1 brian brian 165780 Aug 24 08:39 .xsession-errors Has it dawned on you that an investigation of the file's contents might be indicated? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/09092014183657.c13f8c6fa...@desktop.copernicus.demon.co.uk
Re: Query about .xsession-errors file
On 10/09/2014, Bret Busby wrote: > On 09/09/2014, Chris Bannister wrote: >> On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote: >>> Hello. >>> >>> I am concerned that, should I simply delete the file, the system will >>> crash or otherwise damage 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--- 1 chrisb chrisb 0 Sep 9 21:25 .xsession-errors >> > > Well, that kind of works. > > Before seeing the above message, after someone previously saying that > deleting the file would not cause any (extra) problems, but would not > free up disc space, I deleted the file, then ran "Empty Trash Can", > but, no disc space was freed, then, subsequently, I observed that a > new file had been created; > .xsession-errors.old > with a size of about 33kB, and so I overwrote that, as described > above, and that reduced its size to zero, but, I now do not have the > original file with which to do that, and, I have about 750MB of > missing 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? > > Maybe this is why, as I posted some time ago, resources repeatedly got > progressively consumed, until no free resources were available, so the > system required rebooting every couple of weeks or so (a bit like > Win95, I think it was, but, I believe that Win95 generally lasted for > about four weeks, before needing rebooting), or, it simply crashed. > > 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 quite fast. -- Bret Busby Armadale West Australia .. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cacx6j8p54xsm1ef__uqsidymiu-go_l6m2neaqimjpjphhf...@mail.gmail.com
Re: Query about .xsession-errors file
On 09/09/2014, Chris Bannister wrote: > On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote: >> Hello. >> >> I am concerned that, should I simply delete the file, the system will >> crash or otherwise damage 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--- 1 chrisb chrisb 0 Sep 9 21:25 .xsession-errors > Well, that kind of works. Before seeing the above message, after someone previously saying that deleting the file would not cause any (extra) problems, but would not free up disc space, I deleted the file, then ran "Empty Trash Can", but, no disc space was freed, then, subsequently, I observed that a new file had been created; .xsession-errors.old with a size of about 33kB, and so I overwrote that, as described above, and that reduced its size to zero, but, I now do not have the original file with which to do that, and, I have about 750MB of missing 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? Maybe this is why, as I posted some time ago, resources repeatedly got progressively consumed, until no free resources were available, so the system required rebooting every couple of weeks or so (a bit like Win95, I think it was, but, I believe that Win95 generally lasted for about four weeks, before needing rebooting), or, it simply crashed. -- Bret Busby Armadale West Australia .. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACX6j8OeQTge42z9ah2sDQ08mR=ki5rm4fvzzo2epiwwen8...@mail.gmail.com
Re: Query about .xsession-errors file
On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote: > Hello. > > I am concerned that, should I simply delete the file, the system will > crash or otherwise damage 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--- 1 chrisb chrisb 0 Sep 9 21:25 .xsession-errors -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909092653.GA2878@tal
Re: Query about .xsession-errors file
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 sitting at about 740MB, and has > been growing in the last hour. > > Does some uttility or command (with switches) exist, that can purge > the file of redundant (for example, entries over a week old, or, > entries from before the current boot session) entries, so as to reduce > the file size to content that is necessary to retain for debugging? > > I am concerned that, should I simply delete the file, the system will > crash or otherwise damage to the boot session, would occur. > > Thank you in anticipation. A cron job should fit your needs, though I would investigate to prevent such errors... /r -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140909074000.ga10...@gmail.com
Re: Query about .xsession-errors file
Hi.
On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote:
> Does some uttility or command (with switches) exist, that can purge
> the file of redundant (for example, entries over a week old, or,
> entries from before the current boot session) entries, so as to reduce
> the 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 logrotate:
$ cat /etc/logrotate.d/xsession-errors
/home/reco/.xsession-errors {
size 1k
rotate 1
copytruncate
missingok
compress
}
> I am concerned that, should I simply delete the file, the system will
> crash or otherwise damage to the boot session, would occur.
While deleting it won't harm anything, it also does not release disk
space, as this file is open with all X clients.
Reco
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140909073922.ga12...@d1696.int.rdtex.ru
Query about .xsession-errors file
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 the last hour. Does some uttility or command (with switches) exist, that can purge the file of redundant (for example, entries over a week old, or, entries from before the current boot session) entries, so as to reduce the file size to content that is necessary to retain for debugging? I am concerned that, should I simply delete the file, the system will crash or otherwise damage to the boot session, would occur. Thank you in anticipation. -- Bret Busby Armadale West Australia .. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cacx6j8m+8jf3waexetuc5mye_x30jc+u5-fie7yheddxuzx...@mail.gmail.com
Re: .xsession-errors
> > 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
Re: .xsession-errors
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-bin/bugreport.cgi?bug=732136 -- 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/1392753607.2586.39.camel@archlinux
Re: .xsession-errors
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 this about ? It's glibtop complaining about the Debian kernel version which contains only two parts rather than three in Jessie (i.e. it's 3.12 rather than 3.12.0). Should I be concerned? No, but please file a bug against libgtop2-7 or the source package libgtop2. For the reference, the message is in sysdeps/linux/open.c in the libgtop2 source code: , | if (sscanf(uts.release, "%u.%u.%u", &x, &y, &z) < 3) | glibtop_warn_r(server, | "Non-standard uts for running kernel:\n" | "release %s=%u.%u.%u gives version code %d\n", | uts.release, x, y, z, LINUX_VERSION_CODE(x,y,z)); ` Cheers, Sven Apparently already done by Paul Cartwright - I did add my comment re my system being 32 bit. Thanks -- 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/5303ba80.8000...@videotron.ca
Re: .xsession-errors
On 18/02/14 02:52 PM, Frank McCormick wrote: On 18/02/14 02:39 PM, Paul Cartwright wrote: On 02/18/2014 02:02 PM, Sven Joachim wrote: No, but please file a bug against libgtop2-7 or the source package libgtop2. For the reference, the message is in sysdeps/linux/open.c in the libgtop2 source 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 199680 I have a comment to the bug...re my system being 32-bit. Thanks to all Err...that should be " I added a comment". Need more coffee...or something. -- 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/5303ba51.1000...@videotron.ca
Re: .xsession-errors
On 18/02/14 02:39 PM, Paul Cartwright wrote: On 02/18/2014 02:02 PM, Sven Joachim wrote: No, but please file a bug against libgtop2-7 or the source package libgtop2. For the reference, the message is in sysdeps/linux/open.c in the libgtop2 source 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 199680 I have a comment to the bug...re my system being 32-bit. Thanks to all -- 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/5303b9f2.4010...@videotron.ca
Re: .xsession-errors
On 02/18/2014 02:02 PM, Sven Joachim wrote: > No, but please file a bug against libgtop2-7 or the source package > libgtop2. For the reference, the message is in sysdeps/linux/open.c in > the libgtop2 source 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 199680 -- Paul Cartwright Registered Linux User #367800 and new counter #561587 -- 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/5303b6d8.4070...@gmail.com
Re: .xsession-errors
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 the Debian kernel version which contains only two parts rather than three in Jessie (i.e. it's 3.12 rather than 3.12.0). > Should I be concerned? No, but please file a bug against libgtop2-7 or the source package libgtop2. For the reference, the message is in sysdeps/linux/open.c in the libgtop2 source code: , | if (sscanf(uts.release, "%u.%u.%u", &x, &y, &z) < 3) | glibtop_warn_r(server, | "Non-standard uts for running kernel:\n" | "release %s=%u.%u.%u gives version code %d\n", | uts.release, x, y, z, LINUX_VERSION_CODE(x,y,z)); ` Cheers, Sven -- 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/87sirgckh7@turtle.gmx.de
Re: .xsession-errors
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 be concerned? > > Thanks This is probably not the best advice but: If nothing slows down/crashes/screws up data, then you can probably ignore it. Conrad -- 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/1670744.o8VPmNICbx@twilight
.xsession-errors
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...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53039474.4030...@videotron.ca
Re: Error messages on ".xsession-errors"
On Sun, 08 Jul 2012 03:14:34 -0300, Davi Garcia wrote: > Hey guys, Hello. Please, avoid using html posts, they are badly read from some clients. > After many years, I finally returned to Debian. Now I'm using Debian > Wheeze on my Thinkpad W510 for around 1 week now. The system 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 ".xsession-errors" > file I found the following messages: (...) Using Wheeze here and yes, my "~/.xsession-errors" file is plenty of warning messages but unless I experience a specific problem within the desktop or applications themselves, I do not tend to report this because warnings and errors always have been there (different messages, of course) since GNOME 2, so I see them as a "feature" (useful for debugging purposes) :-) Greetings, -- Camaleón -- 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/jtbrqu$s8h$5...@dough.gmane.org
Error messages on ".xsession-errors"
Hey guys, After many years, I finally returned to Debian. Now I'm using Debian Wheeze on my Thinkpad W510 for around 1 week now. The system 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 ".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: Got a request to focus 0x1a4 (Desktop) with a timestamp of 0. This shouldn't happen!* Searching around Google, I found a similar issues caused by a bug. Do we have already a bug filled for this? Please let me know if more details are needed. *(tracker-miner-fs:3990): Tracker-WARNING **: Couldn't properly parse desktop file 'file:///usr/share/applications/brasero-nautilus.desktop': 'Desktop file doesn't contain type'* I think this is just a simple mistake in the ".desktop" descriptor. I'll try to change it and verify if the error persist. *(gnome-shell:3975): folks-WARNING **: Error preparing persona store 'eds:1341666308.4795.1@davigar-lnx': Couldn't open address book ‘1341666308.4795.1@davigar-lnx’: Cannot open book: Address book does not exist ** Message: applet now embedded in the notification area (gnome-shell:3975): folks-WARNING **: Failed to find primary PersonaStore with type ID 'eds' and ID '1341666308.4795.1@davigar-lnx'. Individuals will not be linked properly and creating new links between Personas will not work. The configured primary PersonaStore's backend may not be installed. If you are unsure, check with your distribution. *This messages are always shown in the log. It looks like we have a bad default config. applied. Does anyone know where this configuration is stored? *(gnome-settings-daemon:3928): PackageKit-WARNING **: couldn't parse execption 'GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code4: GetDistroUpgrades not supported by backend', please report (gnome-settings-daemon:3928): updates-plugin-WARNING **: failed to get upgrades: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_5ftransaction_5ferror.Code4: GetDistroUpgrades not supported by backend', please report *Unfortunately I have no idea about these ones. I just doing what they tell me to do... reporting... =P* *Thanks in advance!* * []s, Davi Vercillo C. Garcia Phone: +55 (21) 8193-0132v Skype: davivcgarcia Web: http://davigarcia.me
Re: .xsession-errors massive
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 3 will cure the problem. It > may be a while before the problematic programs are built against the new > version, however. we shall see, I appreciate your info, thanks! -- Paul Cartwright -- 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/4d639363.5020...@pcartwright.com
Re: .xsession-errors massive
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 | wc 137884 965188 9100344 I was googling& it looks like a gtk version error, but that was a different distro I think. 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... 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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550352#35 The bug seems to be related to Adobe Flash Player, though a few people have reported the bug being triggered by other apps. A patch was posted which does not fix the underlying problem but provides some relief from the symptoms. I also posted a modified version of that patch, which simply spams .xsession-errors much less frequently. I'm hoping that the upcoming libgtk version 3 will cure the problem. It may be a while before the problematic programs are built against the new version, however. Dave W. -- 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/4d631c6e.6080...@sbcglobal.net
Re: .xsession-errors massive
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 the other .xsession logs.. logrotate created some massive files... -- Paul Cartwright -- 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/4d62eec3.80...@pcartwright.com
Re: .xsession-errors massive
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 & it looks like a gtk version error, but that was a > different distro I think. 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... Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsystems@tdnet France EURL itsystems@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix <http://www.itsystems.tamay-dogan.net/> <http://www.flexray4linux.org/> <http://www.debian.tamay-dogan.net/> <http://www.can4linux.org/> Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
Re: .xsession-errors massive
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 > 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. thanks! -- Paul Cartwright -- 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/4d62d2c6.1040...@pcartwright.com
Re: .xsession-errors massive
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 ahead (firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead (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 275772 1930404 18116684 -- "The normal condition of mankind is tyranny and misery." Milton Friedman -- 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/4d62cf70.7090...@cox.net
.xsession-errors massive
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 collision, trouble ahead (firefox-bin:15563): Gdk-WARNING **: XID collision, trouble ahead is it my configuration, or a major gtk issue? -- Paul Cartwright -- 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/4d62ca5f.5050...@pcartwright.com
Re: ~/.xsession-errors file grows way too big
On Thursday 20 May 2010 23:38:42 T o n g wrote: > 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. > > > > 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 agree with it? The URL? I don't see anything special about it. The contents of the document available at that location? I tend to agree with the DD that already replied. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: ~/.xsession-errors file grows way too big
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. > > 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 agree with it? -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- 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/ht52oh$48...@dough.gmane.org
Re: ~/.xsession-errors file grows way too big
On 2010-05-19 19:19 +0200, d.sastre.med...@gmail.com wrote: > FWIW, I don't have that problem, although /etc/X11/Xsession says: > > exec >>"$ERRFILE" 2>&1 (despite the solution proposed in¹) > echo "$PROGNAME: X session started for $LOGNAME 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 you, maybe the display manager. FWIW, stock XDM would do that if it were not disabled by a Debian patch that has been around for ages and probably comes from the same developer who refused to truncate ~/.xsession-errors in /etc/X11/xsession. Sven -- 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/87tyq33gvg@turtle.gmx.de
Re: ~/.xsession-errors file grows way too big
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/bugreport.cgi?bug=287876) whereas currently, my ~/.xsession-errors kept logs back to stone age. However, such reasonable request has been tabled for 6 years now. The DD gave loads of irrelevant reasons as excuse of not fixing it. Ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276545 Any comment? My .xsession-errors is now: h...@debian:~$ ls -l .xsession-errors -rw-r--r-- 1 hugo hugo 200043 2010-05-19 12:34 .xsession-errors and it is filled with: ... error 173 request 152 minor 8 serial 1023 error 173 request 152 minor 8 serial 1176 error 173 request 152 minor 8 serial 1271 error 173 request 152 minor 8 serial 1323 ... I asked about that several times who knows where and when and nobody answered, as will be the case here. It gets that way after I do (in Fvwm) Key F9 A M Exec /usr/local/bin/xcompmgr -c -f so that I can make my onscreen monitors grow translucent to see what is behind them: Mouse 4 W S Exec /usr/bin/transset-df --min 0.1 --id=$[w.id] --dec 0.2 Mouse 5 W S Exec /usr/bin/transset-df -p --inc 0.1 --id=$[w.id] But .xsession-errors gets initialized at the beginning of each session, who knows why... Hugo -- 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/ht185u$77...@dough.gmane.org
Re: ~/.xsession-errors file grows way too big
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 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. > > > > However, such reasonable request has been tabled for 6 years now. The DD > > gave loads of irrelevant reasons as excuse of not fixing it. Ref: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276545 > > > > Any comment? > > You may want to follow up on these bugs, since the _current_ X > developers in Debian never spoke up. And I think that there is so much > crapware that puts out useless junk on stderr or stdout (the worst > offender is KDE4 software, until you find out that is possible to put an > end to this by running kdebugdialog) that the battle to make > ~/.xsession-errors useful has long been lost. FWIW, I don't have that problem, although /etc/X11/Xsession says: exec >>"$ERRFILE" 2>&1 (despite the solution proposed in¹) echo "$PROGNAME: X session started for $LOGNAME 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 This is a Lenny box, BTW. What are the perms for that file? maybe (wild guess) it lacks w? Regards. ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287876 -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB pgphbf2xiJimZ.pgp Description: PGP signature
Re: ~/.xsession-errors file grows 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 > 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. > > However, such reasonable request has been tabled for 6 years now. The DD > gave loads of irrelevant reasons as excuse of not fixing it. Ref: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276545 > > Any comment? You may want to follow up on these bugs, since the _current_ X developers in Debian never spoke up. And I think that there is so much crapware that puts out useless junk on stderr or stdout (the worst offender is KDE4 software, until you find out that is possible to put an end to this by running kdebugdialog) that the battle to make ~/.xsession-errors useful has long been lost. Sven -- % grep errors ~/.xsession > ~/.xsession-errors -- 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/87zkzv3kof@turtle.gmx.de
Re: ~/.xsession-errors file grows way too big
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 > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287876) > whereas currently, my ~/.xsession-errors kept logs back to stone age. > > However, such reasonable request has been tabled for 6 years now. The DD > gave loads of irrelevant reasons as excuse of not fixing it. Ref: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276545 > > Any comment? 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. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
~/.xsession-errors file grows way too big
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=287876) whereas currently, my ~/.xsession-errors kept logs back to stone age. However, such reasonable request has been tabled for 6 years now. The DD gave loads of irrelevant reasons as excuse of not fixing it. Ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276545 Any comment? -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- 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/ht131h$el...@dough.gmane.org
Thoughts about /etc/X11/Xsession and .xsession-errors
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. If thats in /home is just a symlink and the real file is in /tmp on a tmpfs, you avoid unnecessary accesses to hard-disk (could sometimes prevent a spin-up) or ssd. The second benefit is that the old xsession-errors are discarded on reboot (even on non tmpfs), so it doesn't grow to infinity. Is this something worth writing a bug report about, or do i just get something wrong? Below is the relevant part of my working personal version of Xsession: SYSSESSIONDIR=/etc/X11/Xsession.d USERXSESSION=$HOME/.xsession USERXSESSIONRC=$HOME/.xsessionrc ALTUSERXSESSION=$HOME/.Xsession ERRFILE=$HOME/.xsession-errors TMPDIR=/tmp # attempt to create an error file; abort if we cannot if (umask 077 && touch "$TMPDIR/xsession-$USER") 2> /dev/null && [ -w "$TMPDIR/xsession-$USER" ] && [ ! -L "$TMPDIR/xsession-$USER" ]; then chmod 600 "$TMPDIR/xsession-$USER" if ! ln -sf "$TMPDIR/xsession-$USER" "$ERRFILE"; then message "warning: unable to symlink \"$TMPDIR/xsession-$USER\" to" \ "\"$ERRFILE\"; look for session log/errors in" \ "\"$TMPDIR/xsession-$USER\"." fi else errormsg "unable to create X session log/error file; aborting." fi exec >>"$TMPDIR/xsession-$USER" 2>&1 echo "$PROGNAME: X session started for $LOGNAME at $(date)" -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xsession errors
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 must change your logging for X. This is controlled by the file /etc/X11/Xsession you will see the variable ERRFILE=$HOME/.xsession-errors and you should see the line exec >>"$ERRFILE" 2>&1 now this says it keeps adding to the file exec >>"$ERRFILE" 2>&1 if you change it to exec >"$ERRFILE" 2>&1 then when you restart X it is wiped out. or else you can just do ERRFILE=/dev/null and never collect errors at all ... But that is not wise... Mitchell -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xsession errors
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 135M in size! It > grows by the minute. It is mainly full of "GDK-Warnings". > > Did anyone else have this problem, either now or in the past? If > in the past, what did you do to solve it? I had noticed this in the past but now I see only one session in ~/.xsession-errors. It is only 11K. All the xorg packages I see installed are Lenny versions. I don't recall doing anything myself to fix the problem. signature.asc Description: Digital signature
xsession errors
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 "GDK-Warnings". Did anyone else have this problem, either now or in the past? If in the past, what did you do to solve it? Regards, Jan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: .xsession-errors messages
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.org/cgi-bin/bugreport.cgi?bug=505050 Hugo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .xsession-errors messages
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 subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
.xsession-errors messages
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]
.xsession-errors clamav old
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/faq *** LibClamAV Warning: *** QFile::open: No file name specified I read the faq, added that source, ran the update/install and still got: c# apt-get install clamav Reading package lists... Done Building dependency tree Reading state information... Done clamav is already the newest version. clamav set to manually installed. I also had lots of those QFile:: no file specified lines.. -- Paul Cartwright Registered Linux user # 367800 Registered Ubuntu User #12459 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Firefox 2.0.0.14 crashing (was Re: .xsession-errors)
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 track down the iceweasel crashes is to disable all the add-ons and start > iceweasel in a safe mode using "iceweasel -safe-mode". Another thing to > look for are the flash packages installed on the system. FWIW, I am running > Debian Etch, iceweasel 2.0.0.14 and it does not crash at all! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .xsession-errors
Hi Raju, On 6/13/08, Kamaraju S Kusumanchi <[EMAIL PROTECTED]> wrote: > > So I removed '/usr/share/fonts/X11/Type1' and the errors where gone. > > Which errors? Did it get rid of the opcode errors or did it get rid of "bad > font path element" errors? 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, almost empty, apart from the line telling me when my xsession started). So I thought the problem was solved. Today I noticed that the .xsession-errors file was like the one I started this thread with. So I deleted '/usr/share/fonts/X11/Type1-old', deleted '~/.xsession-errors', logged out and back in to KDE and got a fresh .xsession-errors file, same as where I started with. In the end the errors are still there, only I've lost '/usr/share/fonts/X11/Type1'. Greetings, Manon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .xsession-errors
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: >> > > > Directory does not exist or has wrong permissions >> > > > Directory missing fonts.dir >> > > > Incorrect font server address or syntax >> >> >> > Font Path: >> > /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi:unscaled,/usr/ >> share/fonts/X11/75dpi:unscaled,/usr/share/fonts/X11/Type1,/var/lib/defo >> ma/x-ttcidfont-conf.d/dirs/TrueType,/usr/local/share/fonts >> >>^^^ >> Maybe you should remove this directory since I can not imagine you have >> it. I have several installations from Woody, Sarge, Etch, Lenny and Sid >> and there is not a singel installation, where this directory exist. >> >> So removing this directory from the FontPath will eliminate the above >> four Error lines. > > > So I removed '/usr/share/fonts/X11/Type1' and the errors where gone. > Which errors? Did it get rid of the opcode errors or did it get rid of "bad font path element" errors? -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .xsession-errors
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 or has wrong permissions > > > > Directory missing fonts.dir > > > > Incorrect font server address or syntax > > > > Font Path: > > /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi:unscaled,/usr/ > share/fonts/X11/75dpi:unscaled,/usr/share/fonts/X11/Type1,/var/lib/defo > ma/x-ttcidfont-conf.d/dirs/TrueType,/usr/local/share/fonts > >^^^ > Maybe you should remove this directory since I can not imagine you have > it. I have several installations from Woody, Sarge, Etch, Lenny and Sid > and there is not a singel installation, where this directory exist. > > So removing this directory from the FontPath will eliminate the above > four Error lines. I checked all these dirs: drwxr-xr-x 2 root root /usr/share/fonts/X11/misc drwxr-xr-x 2 root root /usr/share/fonts/X11/100dpi drwxr-xr-x 2 root root /usr/share/fonts/X11/75dpi drwxr-xr-x 2 root root /usr/share/fonts/X11/Type1 drwxr-xr-x 2 root root /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType drwxrwsr-x 2 root staff /usr/local/share/fonts All but /usr/share/fonts/X11/Type1 have a 'fonts.dir' file in it. /usr/share/fonts/X11/misc /usr/share/fonts/X11/100dpi /usr/share/fonts/X11/75dpi contain lots of *.pcf.gz files /usr/share/fonts/X11/Type1 contains '*.pfb' softlinks to '../../type1/gsfonts/' which does not exist /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType contains softlinks to '/usr/share/fonts/truetype' /usr/local/share/fonts contains a softlink to '/usr/share/fonts/X11/encodings/encodings.dir' and a custom installed font So I removed '/usr/share/fonts/X11/Type1' and the errors where gone. Thank you very much for the help. Greetings, Manon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .xsession-errors
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 font server address or syntax > Font Path: > /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi:unscaled,/usr/ share/fonts/X11/75dpi:unscaled,/usr/share/fonts/X11/Type1,/var/lib/defo ma/x-ttcidfont-conf.d/dirs/TrueType,/usr/local/share/fonts ^^^ Maybe you should remove this directory since I can not imagine you have it. I have several installations from Woody, Sarge, Etch, Lenny and Sid and there is not a singel installation, where this directory exist. So removing this directory from the FontPath will eliminate the above four Error lines. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: .xsession-errors
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 --recursive 'setPointSize' /etc/* > X Error: BadAccess (attempt to access private resource denied) 10 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x1ec > X Error: BadAccess (attempt to access private resource denied) 10 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x1ec > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 19 > Minor opcode: 0 > Resource id: 0x1e006de > > Can anyone please tell me how I can eliminate or correct these errors? Maybe we get the program which try to set the wrong FontSize. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: .xsession-errors
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 track down the iceweasel crashes is to disable all the add-ons and start > iceweasel in a safe mode using "iceweasel -safe-mode". Another thing to > look for are the flash packages installed on the system. FWIW, I am running > Debian Etch, iceweasel 2.0.0.14 and it does not crash at all! Thanks for the tip. I was using Firefox (not Iceweasel) with flashplayer r115. I installed the newest version (r124) to see if that was the problem. If not, I'll disabling add-ons and try safe-mode. Greetings, Manon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .xsession-errors
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 a safe mode using "iceweasel -safe-mode". Another thing to look for are the flash packages installed on the system. FWIW, I am running Debian Etch, iceweasel 2.0.0.14 and it does not crash at all! hth raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .xsession-errors
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 the output of > > xset q Here's the output: Keyboard Control: auto repeat: onkey click percent: 0LED mask: 0002 auto repeat delay: 250repeat rate: 25 auto repeating keys: 00ffdbbf fadfffdfffdfe5ef bell percent: 50bell pitch: 400bell duration: 100 Pointer Control: acceleration: 20/10threshold: 4 Screen Saver: prefer blanking: noallow exposures: yes timeout: 310cycle: 600 Colors: default colormap: 0x20BlackPixel: 0WhitePixel: 16777215 Font Path: /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi:unscaled,/usr/share/fonts/X11/75dpi:unscaled,/usr/share/fonts/X11/Type1,/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,/usr/local/share/fonts Bug Mode: compatibility mode is disabled DPMS (Energy Star): Standby: 600Suspend: 1200Off: 3600 DPMS is Enabled Monitor is On Thanks in advance, Manon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
