On Thu, 29 Oct 2020 at 05:33, Celejar <[email protected]> wrote: > On Wed, 28 Oct 2020 15:28:37 +1100 David <[email protected]> wrote: > > On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU <[email protected]> > > 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.
