Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
May be a valid solution for huge .xsession-error files
Tags xsession-errors
Having something like ~/.cache as a tmpfs, and setting up xsession-errors to be there.
Of course, everything will be lost in the next reboot, and, depending on for how long the session goes, it may be too big for the set-up tmpfs space as well, for the people who use their PCs on a never-really-turn-off/reboot kind of regimen.
If one needs eventually something saved from session to session, maybe one can have a daemon that will tail/pipe the xsession-errors to some permanent file, maybe even grepping/filtering for the most relevant stuff (with the risk of potentially losing something of interest).
Making use of search engines of the world wide information superhighway, one may end up thinking the xsession-errors cnofiguration would be set up on the display manager configs (such as sddm, its xsession-log settings). But apparently it can be a mistake, and the real deal is /etc/X11/Xsession. At least for us old-timer folks who still use the good ol' Xorg, like the flying spaghetti monster intended to be. Likely kids these days with their "yaylands" don't even have a xsession-errors per se, to begin with.
In any case, the relevant line is
Which is already edited for the set-up of .cache as tmpfs. No much sense in having it as a hidden file there.
GNOME3 and/or maybe GNOME2's display/log-in manager seems to have some sort of redundant config in this regard, that I'd guess could also override the xsession ones, which may lead some stumbling on this info to think that it would be dealt in a similar fashion by SDDM, but in my experience, it doesn't seem to be the case. SDDM's log with a similar name is something else, that's apparently left pretty much untouched. ALTHOUGH I noticed that it will run openbox through the "openbox-session" command/script, whose manual page defines as something along the lines of "openbox session without any display manager," so it could perhaps be the case that it's openbox that's overriding the SDDM override, back to defaults.
Maybe the real proper way would be to have a specific separate config file with that line somewhere in /etc/X11/Xsession.d, but I'm afraid it would require some knowledge of potential race conditions and whatnot, so I'll leave it in the main file, even if at the risk of it being reverted to defaults from time to time, with upgrades, although I think that would not only be rare, but the dpkg thing would show up a dialog showing the differences and I would then be sort of warned to re-make the edit.
The tmpfs ~/.cache is set-up in fstab:
which is an okay solution for a pretty-much single-user situation, to whom 400mb of cache would suffice (I thought it was more). I have some daemons cleaning some of it from time to time as well. There are probably better ways of setting it up so to not require the explicit username on fstab, which can't use variables like "${USER}" since it's processed before anyone logs in. But I'm fine with rudimentary set ups that do what I need currently, although sometimes I'd spend/waste some time looking for more universal and "permanent" alternatives.
Of course, everything will be lost in the next reboot, and, depending on for how long the session goes, it may be too big for the set-up tmpfs space as well, for the people who use their PCs on a never-really-turn-off/reboot kind of regimen.
If one needs eventually something saved from session to session, maybe one can have a daemon that will tail/pipe the xsession-errors to some permanent file, maybe even grepping/filtering for the most relevant stuff (with the risk of potentially losing something of interest).
Making use of search engines of the world wide information superhighway, one may end up thinking the xsession-errors cnofiguration would be set up on the display manager configs (such as sddm, its xsession-log settings). But apparently it can be a mistake, and the real deal is /etc/X11/Xsession. At least for us old-timer folks who still use the good ol' Xorg, like the flying spaghetti monster intended to be. Likely kids these days with their "yaylands" don't even have a xsession-errors per se, to begin with.
In any case, the relevant line is
Code:
ERRFILE=$HOME/.cache/xsession-errors
GNOME3 and/or maybe GNOME2's display/log-in manager seems to have some sort of redundant config in this regard, that I'd guess could also override the xsession ones, which may lead some stumbling on this info to think that it would be dealt in a similar fashion by SDDM, but in my experience, it doesn't seem to be the case. SDDM's log with a similar name is something else, that's apparently left pretty much untouched. ALTHOUGH I noticed that it will run openbox through the "openbox-session" command/script, whose manual page defines as something along the lines of "openbox session without any display manager," so it could perhaps be the case that it's openbox that's overriding the SDDM override, back to defaults.
Maybe the real proper way would be to have a specific separate config file with that line somewhere in /etc/X11/Xsession.d, but I'm afraid it would require some knowledge of potential race conditions and whatnot, so I'll leave it in the main file, even if at the risk of it being reverted to defaults from time to time, with upgrades, although I think that would not only be rare, but the dpkg thing would show up a dialog showing the differences and I would then be sort of warned to re-make the edit.
The tmpfs ~/.cache is set-up in fstab:
Code:
tmpfs /home/my-username/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0
Total Comments 0
