How can I configure Xwayland (to set NoTrapSignals to the correct value)
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
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.
xorg gnome configuration wayland
add a comment |Â
up vote
0
down vote
favorite
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.
xorg gnome configuration wayland
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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.
xorg gnome configuration wayland
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.
xorg gnome configuration wayland
edited Mar 24 at 0:29
asked Mar 24 at 0:15
sourcejedi
18.6k32477
18.6k32477
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
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.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
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.
add a comment |Â
up vote
0
down vote
accepted
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.
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
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.
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.
answered Mar 24 at 1:06
sourcejedi
18.6k32477
18.6k32477
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f433184%2fhow-can-i-configure-xwayland-to-set-notrapsignals-to-the-correct-value%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password