Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228253 > unrolled thread

The .xsession-errors problem

Back to article view | Back to linux.debian.user

Contents

  The .xsession-errors problem Teemu Likonen <tlikonen@iki.fi> - 2020-10-26 17:50 +0100
    Re: The .xsession-errors problem Reco <recoverym4n@enotuniq.net> - 2020-10-26 18:10 +0100
      Re: The .xsession-errors problem Teemu Likonen <tlikonen@iki.fi> - 2020-10-27 16:10 +0100
        Re: The .xsession-errors problem rhkramer@gmail.com - 2020-10-27 20:20 +0100
    Re: The .xsession-errors problem Sven Joachim <svenjoac@gmx.de> - 2020-10-26 18:20 +0100
      Re: The .xsession-errors problem Teemu Likonen <tlikonen@iki.fi> - 2020-10-26 19:10 +0100
    Re: The .xsession-errors problem Linux-Fan <Ma_Sys.ma@web.de> - 2020-10-26 19:30 +0100
    Re: The .xsession-errors problem Tixy <tixy@yxit.co.uk> - 2020-10-27 00:10 +0100
      Re: The .xsession-errors problem John Hasler <jhasler@newsguy.com> - 2020-10-27 00:30 +0100
      Re: The .xsession-errors problem Greg Wooledge <wooledg@eeg.ccf.org> - 2020-10-27 13:00 +0100
        Re: The .xsession-errors problem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-27 14:50 +0100
          Re: The .xsession-errors problem David <bouncingcats@gmail.com> - 2020-10-28 05:30 +0100
            Re: The .xsession-errors problem Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-28 12:50 +0100
            Re: The .xsession-errors problem Celejar <celejar@gmail.com> - 2020-10-28 19:40 +0100
              Re: The .xsession-errors problem David <bouncingcats@gmail.com> - 2020-10-29 00:10 +0100
                Re: The .xsession-errors problem Curt <curty@free.fr> - 2020-10-29 19:30 +0100
                  Re: The .xsession-errors problem David <bouncingcats@gmail.com> - 2020-10-30 01:00 +0100
    Re: The .xsession-errors problem David Wright <deblis@lionunicorn.co.uk> - 2020-10-27 01:00 +0100
      Re: The .xsession-errors problem David <bouncingcats@gmail.com> - 2020-10-27 01:30 +0100
        Re: The .xsession-errors problem Greg Wooledge <wooledg@eeg.ccf.org> - 2020-10-27 13:00 +0100
          Re: The .xsession-errors problem David Wright <deblis@lionunicorn.co.uk> - 2020-10-29 18:40 +0100
    Re: The .xsession-errors problem Anders Andersson <pipatron@gmail.com> - 2020-11-01 11:20 +0100
      Re: The .xsession-errors problem Teemu Likonen <tlikonen@iki.fi> - 2020-11-01 17:50 +0100
        Re: The .xsession-errors problem Kenneth Parker <sea7kenp@gmail.com> - 2020-11-01 18:40 +0100

Page 1 of 2  [1] 2  Next page →

#228253 — The .xsession-errors problem

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#228254

	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

[toc] | [prev] | [next] | [standalone]

#228304

[Multipart message — attachments visible in raw view] — view raw

* 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

[toc] | [prev] | [next] | [standalone]

#228322

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/<username>/.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.)

[toc] | [prev] | [next] | [standalone]

#228256

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

[toc] | [prev] | [next] | [standalone]

#228258

[Multipart message — attachments visible in raw view] — view raw

* 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

[toc] | [prev] | [next] | [standalone]

#228259

[Multipart message — attachments visible in raw view] — view raw

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

öö

[toc] | [prev] | [next] | [standalone]

#228272

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

[toc] | [prev] | [next] | [standalone]

#228273

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 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#228287

On Mon, Oct 26, 2020 at 11:07:37PM +0000, 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".

[toc] | [prev] | [next] | [standalone]

#228293

[Multipart message — attachments visible in raw view] — view raw

On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> On Mon, Oct 26, 2020 at 11:07:37PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#228339

On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> > On Mon, Oct 26, 2020 at 11:07:37PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#228349

[Multipart message — attachments visible in raw view] — view raw

On Mi, 28 oct 20, 15:28:37, David wrote:
> On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU <andreimpopescu@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#228366

On Wed, 28 Oct 2020 15:28:37 +1100
David <bouncingcats@gmail.com> wrote:

> On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> > > On Mon, Oct 26, 2020 at 11:07:37PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#228371

On Thu, 29 Oct 2020 at 05:33, Celejar <celejar@gmail.com> wrote:
> On Wed, 28 Oct 2020 15:28:37 +1100 David <bouncingcats@gmail.com> wrote:
> > On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > > On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> > > > On Mon, Oct 26, 2020 at 11:07:37PM +0000, 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=c000003e 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=0000000000000000
cap_fi=0000000000000000 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=0000000000000000
cap_fi=0000000000000000 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=0000000000000000
cap_fi=0000000000000000 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=0000000000000000
cap_fi=0000000000000000 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=0000000000000000
cap_fi=0000000000000000 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.

[toc] | [prev] | [next] | [standalone]

#228388

On 2020-10-28, David <bouncingcats@gmail.com> 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);

[toc] | [prev] | [next] | [standalone]

#228394

On Fri, 30 Oct 2020 at 05:27, Curt <curty@free.fr> wrote:
> On 2020-10-28, David <bouncingcats@gmail.com> 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!

[toc] | [prev] | [next] | [standalone]

#228274

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.

[toc] | [prev] | [next] | [standalone]

#228275

On Tue, 27 Oct 2020 at 10:56, David Wright <deblis@lionunicorn.co.uk> 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.
"""

[toc] | [prev] | [next] | [standalone]

#228286

On Tue, Oct 27, 2020 at 11:28:12AM +1100, David wrote:
> On Tue, 27 Oct 2020 at 10:56, David Wright <deblis@lionunicorn.co.uk> 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web