Catching messages after X has terminated

Are messages output after X has terminated saved in a log file somewhere?

I see a number of errors shown after I have logged out of X (LXDE in my case) and I'd like to be able to examine them but I don't know if they are written anywhere.
 
There are a number of different message "classes" you are probably asking about. As some have noted, /var/log/messages and /var/log/Xorg.0.log are the places to look for system level and Xorg server messages. Your LXDE messages may be written somewhere else. For example, I use XDM. XDM writes its messages and all application messages to ~/.xsession-errors. It does this by redirecting stdout and stderr to .xsession-errors. LXDE's display manager(lxdm) might or might not use the same file. Or it might use a different file.

Or, are you using sddm as a display manager? It might write its messages somewhere else. The is no way to know without enough knowedge about the display manage you're using. To find out which file it might be, log into LXDE. Then, immediately log out. Now switch to a text console on your computer and log in. After logging in type in,

sh:
ls -alrt | tail

One of the most recently written files might contain the messages you're interested in. Look in the file to see if it is what you might be looking for. If it is, remember that filename. Now when you log in just open a terminal session or a text viewer and simply look at the file.
 
Another thing you can do is start the Xorg process manually using 'startx' from the login console instead of from sddm, and capture it's output into a file, that you can examine when the X server exits. For example you can say something like :-
startx 2>&1 | tee x.out
- to capture both stdout and stderr. You might have to experiment a bit to get it to work :)
 
Interesting. I prefer booting to just a CLI interface, logging in and then running startx. Has saved me some pain from misconfigured things.

And bygone does not equate to useless.
Yup. Same here. Also prefer logging into cli, and then, if i need desktop, i just startx. Also, i have several entries in my .xinitrc file for when i test various desktops. I just uncoment the line i need, and viola.
 
Starting from the console using startx is very useful if you have any kind of X configuration problem that you are debugging. Then once you get it working, switch to a graphical login manager like sddm. I use the two interchangably.
 
Ahh, so I'm not the only one.
Nope.

And here is the interesting situation i had recently. My buddy wanted to try Artix Linux because he didnt like FreeBSD for some wired reason. So i installed latest Plasma 6.5.1, and i was unable to start Plasma wayland session from sddm. I just get black screen. Stopping sddm service and issuing

Code:
/usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

starts Plasma wayland session just fine. Go figure...
 
Interesting. I prefer booting to just a CLI interface, logging in and then running startx. Has saved me some pain from misconfigured things.

And bygone does not equate to useless.
Actually this is what I do normally, but I'm trying to insert a timer so that startx will start will start up automatically after a given time unless some key is pressed but haven't figured out how to do that yet.
 
What do you use then now? A display manager? Or autostart(?)?
XDM. My .xsession file contains this prompt to allow me to start a number of other windowing environments when I'm away from home/office in order to show people that FreeBSD has many faces. It doesn't have to look like CDE.

Code:
XDMWM=`/usr/bin/cut -c -88 - < /etc/motd | /usr/local/bin/xmessage -buttons cde,mwm,xsm,emwm,xmsm,fvwm2,twm,ctwm,mate,openbox,icewm,afterstep,xterm,logout -file - -print -timeout 60 -default cde -center`

I don't use dtlogin, the CDE display manager, because it doesn't support NIS nor LDAP logins. Though it would be easy to add PAM support to CDE, I don't have the time and XDM does the job with the added benefit of allowing me to show off to non-FreeBSD users any number of windowing environments.
 
Back
Top