cd /home/$(whoami)
tail -10000 .xsession-errors > .xsession-errors.new
cat .xsession-errors.new >.xsession-errors
rm .xsession-errors.new

I can confirm, this works and added to crontab! (fine tuned to my taste)

* */5 * * * [ $(du -k /home/$(whoami)/.xsession-errors | awk '{ print $1 }') -gt 50000 ] && /home/$(whoami)/bin/xsessionclean.sh

Thanks, this is interesting, but at the moment I don't want to use uniq to see real error rate (trying to catch that Thunar error)
Maybe it will be useful to someone else

But again I've not tested that.

What it is useful for is to see just how much unfixed/crap code is routinely swept under the rug.
You know, all that [won't fix] stuff because [whatever].

The thing is that the main issue for most any Linux user is that the bloody file runs wild.
And if not checked, can grow to ridiculous sizes and cause problems.

Bingo!!

Mostly it seems to choke on file-manager errors, but sometimes other programs, sometimes it's the CSS in a given theme. Tons of glib-gio stuff in some DE's. Last year Caja had a real nasty, when you hovered over the .xsession-errors file it would start to spontaneously grow to huge size, many mb in just a minute or less.

It's time-consuming and difficult to weed all the errors out but it can be done, at least in Openbox (daedalus). PcmanFM is still gtk2 in daedalus, that avoids a whole lotta issues.

*sigh* speaking of .xsession-errors...

Bleachbit also cleans up this file, but it's a risky tool to use - all too easy to damage your system (by purging locales, for instance).

It's 1.1MM rows and is 53MB. And I see 62,976 of these messages from libxfce4kbd-private-WARNING : "Failed to grab keycode 111".
It goes back to October, so I'll be cleaning that up now. And hopefully pay a little more attention to it going forward.

Assuming you want to keep just the last 10000 lines of .xsession-errors

Yes, that's exactly what I want. Thank you for the script, i'll try it.

Yes, I took that command
tail -10000 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors
from that blog (– Example #2), and it supposed to keep the last 10,000 lines, but instead it gave me empty file...
Btw, now I'm experimenting with .xsession-errors that is ~1,9 Mib ~22000 lines, so I still can't understand why the above command didn't work...
But nevermind, I'll try chris2be8's script.

Thank you for detailed instructions, I've had experience with crontab, just wanted to test the command to be sure, before putting it there.

Anyway, thank you for being such a helpful community and sorry for my bad english

This solution came from Daniel López Azaña's blog. 
I just relayed the message, so to speak.

There is also a page called [crontab.guru] where you can check your [crontab] syntax, among other things.
Go have a read, it is very comprehensive and useful to have in the browser bookmarks.

Here is how I do it, works a charm:
See man [crontab] on how to edit it.

# Entries added to keep log files from growing too large
# http://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size
#
# Set logfiles to 2Mb and 200 lines max. checking for size every 23 hours
# see https://crontab.guru/#0_*/23_*_*_*
#
# File size examples:
#
# 150Mb -> 150000
# 100Mb -> 100000
# 15Mb  ->  15000
# 10Mb  ->  10000
#  5Mb  ->   5000
#  2Mb  ->   2000
#
# to test cronjob run at 2 min intervals
# example -> */2 * * * *  echo "No systemd here"
#
# For /home/user/.xsession-errors
#
# ---
0 */23 * * * [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 2000 ] && tail -200 /home/$(whoami)/.xsession-errors > $
# ---

The above entry will keep the file under 2mb and when it grows over that limit it will clean up, keeping the last 200 lines.
2Mb of [.xsession-errors] is a lot of text.

eg:
Just now I see that my system's [.xsession-errors] file has 7249 lines and weighs in at a bare 784KiB.

Note:
I have looked at the glibberish that makes up the [.xsession-errors] file once or twice.
I could not make any sense from it and the system apparently worked properly.
And if it did not, I was never the wiser for it. 8^°

What it is useful for is to see just how much unfixed/crap code is routinely swept under the rug.
You know, all that [won't fix] stuff because [whatever].

The thing is that the main issue for most any Linux user is that the bloody file runs wild.
And if not checked, can grow to ridiculous sizes and cause problems.

Best,

A.

cd /home/$(whoami)
tail -10000 .xsession-errors > .xsession-errors.new
cat .xsession-errors.new >.xsession-errors
rm .xsession-errors.new

That *should* work even assuming .xsession-errors is open and being written to (so you can't just rename it without losing all further output). But I *havn't* tested it so use at your own risk.

tail -10000 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors
somehow zeroes the file... well, anyway it's another topic

Of course it does a single > redirect tells the system to overwrite the file creating new version I would think the -10000 tells tail to go back so far it has nothing to put into the file it creates so it is empty. If you wanted the file contents to remain then the >> append to the file should be used then its contents will remain and whatever the command is doing will be added to the file.

Strange, but when testing in terminal without cron this command tail -10000 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors somehow zeroes the file... well, anyway it's another topic... and it's time to sleep.

See these two posts (as well as the other ones in the thread)*:

https://dev1galaxy.org/viewtopic.php?pid=12265#p12265
https://dev1galaxy.org/viewtopic.php?pid=45348#p45348

TL;DR:

* the Search function we have here at [dev1] can be, more often than not, quite useful.

Best,

A.

I have after much work, made Vuu-do's file almost pristine perfect in Openbox/PcmanFM, yet if I switch to Mate, with all else being exactly the same, i'll get some glib-gio critical error nonsense fairly regularly. At one point it went ballistic but upstream fixed that pretty quick.

Something about DE's man...they all come with issues that it's hard for a user to fix locally.

https://developer.xfce.org/exo/ExoIconView.html#exo-icon-view-get-selected-items

not a solution but better than not knowing.

(Thunar:2167): exo-CRITICAL **: 02:18:49.254: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

(Thunar:2167): exo-CRITICAL **: 02:18:49.255: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

(Thunar:2167): exo-CRITICAL **: 02:18:49.954: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

(Thunar:2167): exo-CRITICAL **: 02:18:49.955: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

(Thunar:2167): exo-CRITICAL **: 02:18:50.055: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

(Thunar:2167): exo-CRITICAL **: 02:18:50.055: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

(Thunar:2167): exo-CRITICAL **: 02:18:50.755: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

(Thunar:2167): exo-CRITICAL **: 02:18:50.756: IA__exo_icon_view_get_selected_items: assertion 'EXO_IS_ICON_VIEW (icon_view)' failed

Quick search didn't find anything useful...
Is it only my setup screwed?

UPD: restarting Thunar helps but I've seen this several times already...
What can I do to to fix it?