Re: The .xsession-errors problem
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.
Reply to: