Page 1 of 1
Where is GUI crashed program output logged?
Posted: 27 Aug 2023, 11:40
by Rava
I start X manually, e.g. i set up Port in
init 3 (Slackware standard) and lo into the virtual console as guest ad then manually start X via
Now, I could use a trick to log all that is to be seen on that virtual console into file but usually I don't bother.
Now, i wish I had since once again one nemo instance was no longer reacting and closing that one killed also all other nemos.
While I have 25 lines à 80 characters of the recent output of programs running in X - as well as X itself - to be seen on that virtual console but he most recent message was from the USB subsystem and also from Palemoon, not nemo:
Code: Select all
isWindowPrivate@resource://gre/modules/PrivateBrowsingUtils.jsm:25:14
@about:priv
atebrowsing:71:35
WARNING: content window passed to PrivateBrowsingUtils.isWindow
Private. Use isContentWindowPrivate instead (but only for frame scripts).
pbu_isW
indowPrivate@resource://gre/modules/PrivateBrowsingUtils.jsm:25:14
@about:private
browsing:43:33
WARNING: content window passed to PrivateBrowsingUtils.isWindowPri
vate. Use isContentWindowPrivate instead (but only for frame scripts).
pbu_isWind
owPrivate@resource://gre/modules/PrivateBrowsingUtils.jsm:25:14
@about:privatebro
wsing:71:35
(pale moon:20152): Gtk-WARNING **: 13:13:25.919: Error loading theme
icon 'view-sort-descending' for stock: Icon 'view-sort-descending' not present i
n theme elementary-xfce-dark
thunar-volman: Unsupported input device type "/dev/i
nput/event8".
thunar-volman: Unsupported USB device type "usbhid".
thunar-volman:
Unsupported USB device type "usb".
I did search like so:
Code: Select all
root@porteus:/var/log# grep PrivateBrowsingUtils * 2>/dev/null
root@porteus:/var/log#
but it gives no result. (I put the error messages into the bin since they have been about directories that cannot be searched like so)
Are the error messages of programs stored somewhere else than in /var/log/* ?
Where is GUI crashed program output logged?
Posted: 28 Aug 2023, 12:56
by ncmprhnsbl
pretty much if you don't
Code: Select all
startx > ~/.xsession-errors (or where-ever-you-like)
there'll be no log.. occasionally something might pop up on dmseg, but generally not..
Where is GUI crashed program output logged?
Posted: 28 Aug 2023, 16:10
by Rava
^
Isn't startx a script?
Then it could be tweaked to write it to somewhere, even using a global parameter so that it would be written onto the harddisk.
Code: Select all
/usr/bin/startx: POSIX shell script, ASCII text executable
Code: Select all
xinit "$client" $clientargs -- "$server" $display $serverargs
I presume this is the line that must be changed so that startx logs its output.
Would you agree, ncmprhnsbl ?
Where is GUI crashed program output logged?
Posted: 28 Aug 2023, 18:05
by Ed_P
^
Tough to do for people booting ISO and DVD systems.
Where is GUI crashed program output logged?
Posted: 29 Aug 2023, 08:14
by Rava
Ed_P wrote: ↑28 Aug 2023, 18:05
^
Tough to do for people booting ISO and DVD systems.
When you do not have a local drive to write to, you can only put it onto your ram disk. What else would you expect? Magic?
And all that is a manual change of a system critical script. Every nob should be aware that you never change any existing scripts
without knowing exactly what you do and what that entails.
Even when you create scripts in your
~/ folder or in the
designated $PATH for local scripts or programs -
/usr/local/bin - you can still break your system or damage files on one or more of your drives.
Where is GUI crashed program output logged?
Posted: 29 Aug 2023, 15:07
by Ed_P
Rava wrote: ↑29 Aug 2023, 08:14
you can only put it onto your ram disk.
Before startx is run how does one access the ram disk? /home/guest? /root/?
Rava wrote: ↑29 Aug 2023, 08:14
Every nob should be aware that you never change any existing scripts without knowing exactly what you do and what that entails.
And have a backup.
Where is GUI crashed program output logged?
Posted: 29 Aug 2023, 15:49
by Rava
Ed_P wrote: ↑29 Aug 2023, 15:07
Before startx is run how does one access the ram disk? /home/guest? /root/?
Usually any live systems that are able to run from an ISO use a ramdisk, since running programs need to store data, and an ISO cannot do such. So, when startx starts X after everything else booted successfully you already have a ramdisk running.
In porteus case it's the aufs as mounted on / :
Code: Select all
root@porteus:/# df -Tm /
Filesystem Type 1M-blocks Used Available Use% Mounted on
aufs aufs 388 160 229 42% /
Ed_P wrote: ↑29 Aug 2023, 15:07
Rava wrote: ↑29 Aug 2023, 08:14
Every nob should be aware that you never change any existing scripts without knowing exactly what you do and what that entails.
And have a backup.
Not just when you tweak scripts, any drive can fail, so having backups once in a while might be a chore but having non at all when a crucial drive fails could put you into serious issues.
Where is GUI crashed program output logged?
Posted: 29 Aug 2023, 17:28
by Ed_P
Rava wrote: ↑29 Aug 2023, 15:49
So, when startx starts X after everything else booted
And if startx fails to run what drives are available?
Rava wrote: ↑29 Aug 2023, 15:49
so having backups once in a while might be a chore but having non at all when a crucial drive fails could put you into serious issues.
Yup and being one who has encountered serious issues I try to do backups before making any serious changes. It's also good to periodically test the backup system to ensure it still works as expected/planned/hoped for.
Where is GUI crashed program output logged?
Posted: 29 Aug 2023, 20:23
by Rava
Ed_P wrote: ↑29 Aug 2023, 17:28
And if startx fails to run what drives are available?
Depends on your system.
You can tweak startx to include a
Code: Select all
df -Tm >/tmp/df-Tm-prior.startx.log
-
prior startx staring X of course.
And then when startx was successful do a manual df -Tm - then you see a difference.
But Cave! The 1st df takes a while, so your bootup time till starting your DE will take much longer than without that startx/df tweak
Ed_P wrote: ↑29 Aug 2023, 17:28
Yup and being one who has encountered serious issues I try to do backups before making any serious changes. It's also good to periodically test the backup system to ensure it still works as expected/planned/hoped for.
even when up to now a user never experienced an severe data loss, it is a very risky way of never doing any backup.
It if more about "when" a drive fails, less of "if" a drive fails at all.
Where is GUI crashed program output logged?
Posted: 30 Aug 2023, 05:48
by Ed_P
Good to see you active again
Rava.
A df -Tm of my ISO booted system shows several tmpfs drives, can I assume one of them would be available should startx fails to start?
Code: Select all
Filesystem Type 1M-blocks Used Available Use% Mounted on
tmpfs tmpfs 3855 3 3852 1% /mnt/live
devtmpfs devtmpfs 3853 0 3853 0% /dev
tmpfs tmpfs 4626 142 4485 4% /mnt/live/memory/changes
tmpfs tmpfs 3855 0 3855 0% /dev/shm
tmpfs tmpfs 4 0 4 0% /sys/fs/cgroup
tmpfs tmpfs 771 1 771 1% /run/user/1000
Where is GUI crashed program output logged?
Posted: 30 Aug 2023, 06:11
by Rava
Ed_P wrote: ↑30 Aug 2023, 05:48
can I assume one of them would be available should startx fails to start?
I much presume so.
You can test that: tweak startx so that it fails. Put in a
df -Tm prior that tweaked line, and then do a manual
df -Tm after that.
Of course you should name the broken ISO like Porteus-MY-DE-5.0_x86-64-
BROKEN.iso or such so that to not confuse it later and trying to use it as a valid working ISO.