2

I have created /etc/X11/xorg.conf.

Section "ServerFlags"
    Option "NoTrapSignals" "true"
EndSection

It successfully affects my GNOME session if I start a GNOME session which uses X and not Wayland. I have checked this by killing the X server with SIGABRT, and verifying that it does not try to print it's own backtrace by catching the signal.

However the config file doesn't have the effect I really wanted, which is to achieve the same behaviour for the Xwayland instance, which GNOME starts when I start a normal GNOME session with Wayland.

I can't even find the log messages from Xwayland, to see if it mentions anything about where it reads configuration from!

I notice Xorg has a man page, but Xwayland does not. None of the options Xwayland is running with (-rootless -terminate -core -listen 4 -listen 5 -displayfd 6) are documented in man Xorg, though to be fair GNOME also passes -displayfd to Xorg when running a native X session.

Does anyone know how to do this?

Environment

  • Fedora 27
  • GNOME
  • gnome-session-3.26.1-1.fc27.x86_64
  • xorg-x11-server-Xwayland-1.19.6-5.fc27.x86_64

Context

I have an annoying XWayland crash. I'm having difficulty understanding it from the core dump my system saves. I desperately want to disable the built-in X backtrace generator. It's just getting in the way, the backtrace generator itself is vulnerable to crashes, and most importantly by catching the error signal, I believe it stops Linux from logging the exact cause of the SIGBUS error in the kernel log.

I say this is the correct value for NoTrapSignals, because it's an inherently fragile feature, and AFAICT it's pointless in an unprivileged Xwayland server. It's not like the bad old days of user mode setting, where the kernel couldn't reset the display to text mode, so you desperately hoped the X server would still be able to do so if it crashed.

1 Answer 1

0

I say this is the correct value for NoTrapSignals, because it's an inherently fragile feature, and AFAICT it's pointless in an unprivileged Xwayland server. It's not like the bad old days of user mode setting, where the kernel couldn't reset the display to text mode, so you desperately hoped the X server would still be able to do so if it crashed.

If that's right, the answer is that this is a bug in Xwayland, and Xwayland should be fixed to behave correctly without needing some config file.


Comparing attempts to run Xorg and Xwayland under strace, suggests that Xwayland does not look for any configuration file, only XKB data files.

Both /usr/libexec/Xorg and /usr/bin/Xwayland will print usage advice, if you pass --help as an option. Xorg includes a section "Device Dependent Usage" with options to set the logfile or config file. Xwayland mentions none of these. So Xwayland does not appear to be configurable like Xorg is.

Technically Xwayland seems to get run with -core "generate core dump on fatal error". Xorg does not, though it claims to support the same option. From the evidence so far it feels like this is irrelevant though, particularly since NoTrapSignals does not affect whether or not a core dump is generated.

Option "NoTrapSignals" "boolean"

This prevents the Xorg server from trapping a range of unexpected fatal signals and exiting cleanly. Instead, the Xorg server will die and drop core where the fault occurred. The default behaviour is for the Xorg server to exit cleanly, but still drop a core file. In general you never want to use this option unless you are debugging an Xorg server problem and know how to deal with the consequences.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .