How can I configure Xwayland (to set NoTrapSignals to the correct value)

The name of the pictureThe name of the pictureThe name of the pictureClash 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.







share|improve this question


























    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.







    share|improve this question
























      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.







      share|improve this question














      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.









      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 24 at 0:29

























      asked Mar 24 at 0:15









      sourcejedi

      18.6k32477




      18.6k32477




















          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.







          share|improve this answer




















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );








             

            draft saved


            draft discarded


















            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






























            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.







            share|improve this answer
























              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.







              share|improve this answer






















                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.







                share|improve this answer













                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.








                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Mar 24 at 1:06









                sourcejedi

                18.6k32477




                18.6k32477






















                     

                    draft saved


                    draft discarded


























                     


                    draft saved


                    draft discarded














                    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













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?