Hmm ...
Please check the thread, specifically my second post:

chris2be8's suggestion to chmod 755 /var/log/lost+found could not be easier to implement as it stops the error messages generated by conky by allowing it to access the file.
These error messages were the sole cause of the huge .xsession.errors bloat, so it seems to me that it is the simplest solution. (as always, YMMV)

The crontab solution you suggest controls the size of the .xsession.errors file but generates another set of logfile entries (three lines in auth.log instead of the single line in .xsession.errors we had before) every time conky tries to read the file (every 2 sec.), so it actually makes things worse.

The alternative to stop logging sudo access to auth.log (would not know how to do it) does not seem healthy.

In any case, I set it up because it is a good idea to keep the .xsession.errors file at bay, in my case at 30 minute intervals, a max of 2Gb and min of 1000 lines which would seem to be more than adequate.

Thanks for your input.

Cheers,

A.

Ahh ...
Interesting.

I thought it was a system file and as such belonged to root and root only.
Good to know.

Doing chmod 755 /var/log/lost+found would allow conky to read it without needing admin credentials ie: being included in a sudoers file.
And as such, it won't get logged in auth.log.
Neat.

Nothing there that I should worry about.

I think it may also be worthwhile for the system to generate a separate /var/log/sudo.log file (editing /etc/sudoers).

Thanks you both (chris2be8 + fsmithred) for your input - learned new things today.

Best,

A.

Chris

I see ...

OK

Fortunately I recently learned (here) how to properly generate a sudoers file.
Done.

Just to check:

groucho@devuan:~$ conky
conky: desktop window (1800003) is subwindow of root window (728)
conky: drawing to desktop window
conky: No compatible double buffer extension found
conky: drawing to single buffer

Now my .xsession-errors file will not get filled up with 18Gb of '/var/log/lost+found': Permission denied errors.

Edit:
This solution, neat and efficient, has nevertheless spawned another log overpopulation problem:

Every time

exec sudo du -sch /var/log

is run (every 2s), three lines get written to auth.log.   
This makes absolutely perfect sense as it's exactly what auth.log is for but it also means that auth.log will grow three times fraster than .xsession-errors grew. (!)

Oct 13 12:17:49 devuan sudo:  groucho : TTY=unknown ; PWD=/home/groucho ; USER=root ; COMMAND=/usr/bin/du -sch /var/log
Oct 13 12:17:49 devuan sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 13 12:17:49 devuan sudo: pam_unix(sudo:session): session closed for user root
--- snip ---

I think I may have seen a fix for this but I'll have to look and get back.

In the meanwhile, do you have any ideas as to how to cope with this?
I will temporarily go back to where I was before the fix to conky to keep log growth at bay.

Thanks in advance.

Best,

A.

exec sudo du -sch /var/log

Make a file in /etc/sudoers.d/ with the following.

groucho ALL= NOPASSWD: /usr/bin/du

Indeed.  =-)

Don't know how to do that, it is a problem when I wanted to open some (not all) log files with mousepad.
But I can read them with the Log Viewer.

I have had problems opening up huge files (very slow) even though my rig holds 8Gb. RAM.

WRT the .xsession-errors file, I found a solution to keep it in check here:

http://www.daniloaz.com/en/how-to-preve … huge-size/

It sets up a line in crontab to check every 15 minutes if the file size is greater than 5 GB and if so either empty it or keep the last 10,000 lines.
I set it for every 30 minutes and 1000 lines.

Once I emptied the .xsession-errors file, I found that it was getting a Gtx error every so often about not being able to load the ATK bridge, which I fixed by installing libatk-adaptor.
Found that solution here: https://dev1galaxy.org/viewtopic.php?id=1815 -->  =-)

But what really eats up room in the .xsession-errors file is this line, constantly written up:

du: cannot read directory '/var/log/lost+found': Permission denied
du: cannot read directory '/var/log/lost+found': Permission denied
du: cannot read directory '/var/log/lost+found': Permission denied
--- snip ---

But I know where it comes from:

groucho@devuan:~$ conky
conky: desktop window (1600003) is subwindow of root window (728)
conky: drawing to desktop window
conky: No compatible double buffer extension found
conky: drawing to single buffer
du: cannot read directory '/var/log/lost+found': Permission denied
du: cannot read directory '/var/log/lost+found': Permission denied
du: cannot read directory '/var/log/lost+found': Permission denied
du: cannot read directory '/var/log/lost+found': Permission denied
du: cannot read directory '/var/log/lost+found': Permission denied
du: cannot read directory '/var/log/lost+found': Permission denied
--- snip ---

My conky.conf file is set up so I can see the evolution of my disk usage (/, /home and /var/log), and /var/log usage is checked with this line ...

/var/log ${exec du -sch /var/log | head -n1 | awk '{print $1}'}
${fs_bar /var/log}

... so every time that conky takes a reading, it generates an error message that gets logged in the .xsession-errors file.
No wonder it was huge, conky reads every 2s.   

So the question would be:

How can I get conky to be able to read lost+found?
This would need admin credentials for conky, which does not sound healthy.
And conky is not really a user, so I don't think it could be added to sudoers.

Maybe get the Xserver to not log this specific error?

Any ideas?

Thanks in advance.

A.

Some time ago I took notice that my /home folder usage had grown to over 75%.
It seemed too much but then I realised that I had not done any cleaning in my /home/Downloads folder, so I did a thorough cleaning and sent what I (suppose) will/may need to another drive.

My cleaning got me to around 53% but it still seemed too much as the whole /home partition is 45Gb.

I went looking for a disk usage app and remembered Baobab from my days playing with Mint but saw that the beast wants to drag in all its relatives and friends into my rig so I skipped that one.

Then I remembered du, which I ran as root so it would look everywhere:

[root@devuan groucho]# du -a /home | sort -n -r | head -n 100
24834420	/home
24834400	/home/groucho
16401024	/home/groucho/.xsession-errors
6549156	/home/groucho/VirtualBox VMs
6549152	/home/groucho/VirtualBox VMs/groucho xp
6548676	/home/groucho/VirtualBox VMs/groucho xp/groucho xp-disk1.vmdk
842040	/home/groucho/vmshared
482676	/home/groucho/.wine
480524	/home/groucho/.wine/drive_c
439036	/home/groucho/.wine/drive_c/PMAIL
[root@devuan groucho]# 

And this is when I came upon the 16.4Gb .xsession-errors file.

So I got emptied it completely, no way I could open it with Log Viewer to see what was up.

groucho@devuan:~$ >~/.xsession-errors
groucho@devuan:~$ 

Now my /home folder just takes up 18%.

But I wonder: shouldn't this be getting rotated, zipped and eventually deleted past a certain time?

Thanks in advance.

A.