What are possible causes of appmenu-gtk failing to connect to D-Bus?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







0















The warning is




** (/usr/lib/firefox/firefox:1671): WARNING **: 22:14:54.614: Unable to connect to dbus: Could not connect: Permission denied




I tried using strace but can't find any related file errors there. I guess it could be AppArmor. Any suggestion on how to find the cause?



I started to search because no matter Visual bell setting is set to (gsettings set org.gnome.desktop.wm.preferences visual-bell false) Firefox flashes whole window to inverse colors when search on page did not return any results and it's annoying. This was fixed by changing KDE settings.




  • libappmenu-gtk*-parser0 0.7.1-1

  • Firefox 65.0 (both installed through apt and downloaded)

  • D-Bus 1.12.12-1ubuntu1

  • Ubuntu 19.04


I had ~/.dbus/ owned by root somehow, but tried changing owner to my user recursively and deleting the folder. Both times nothing changed even after a complete reboot.



I would've reported it as bug but want to make sure it really is one.



Update



It's not Firefox, it's appmenu-gtk*:



$ grep "Unable to connect to dbus" -rF /usr
Binary file /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so matches
Binary file /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so matches


And after removing the warning changed to




Gtk-Message: 16:30:03.964: Failed to load module "appmenu-gtk-module".











share|improve this question

























  • Try running it via strace -f -o firefox.trace firefox https://askubuntu.com and maybe provide the output here or on paste.ubuntu.com It should reveal exact errors. ~/.dbus could be one possible issue, as EACCESS error results from any component of pathname having restricted permissions, but since you've tried dealing with the directory something else is the culprit

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:34











  • Thanks! The only filename appearing with EACCES is /usr/lib/firefox/fonts/.uuid.TMP-PtRd2i and it looks unrelated. I'll combine stderr with strace output, will it provide a better picture? Tried it but didn't find anything.

    – int_ua
    Feb 16 at 20:49











  • You don't have to combine anything. strace writes everything to stderr or file specified by -o flag so everything will be there once you run the command.

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:50











  • I meant strace -f firefox 2>&1 | tee firefox.trace to include the error in question in the file, here is the result: paste.ubuntu.com/p/NxgMmvmRxz

    – int_ua
    Feb 16 at 20:57






  • 1





    Alright. I'm gonna have to come back, since I'm low on battery in my laptop. I'll dig through the paste and let you know if I figure out anything

    – Sergiy Kolodyazhnyy
    Feb 16 at 21:04


















0















The warning is




** (/usr/lib/firefox/firefox:1671): WARNING **: 22:14:54.614: Unable to connect to dbus: Could not connect: Permission denied




I tried using strace but can't find any related file errors there. I guess it could be AppArmor. Any suggestion on how to find the cause?



I started to search because no matter Visual bell setting is set to (gsettings set org.gnome.desktop.wm.preferences visual-bell false) Firefox flashes whole window to inverse colors when search on page did not return any results and it's annoying. This was fixed by changing KDE settings.




  • libappmenu-gtk*-parser0 0.7.1-1

  • Firefox 65.0 (both installed through apt and downloaded)

  • D-Bus 1.12.12-1ubuntu1

  • Ubuntu 19.04


I had ~/.dbus/ owned by root somehow, but tried changing owner to my user recursively and deleting the folder. Both times nothing changed even after a complete reboot.



I would've reported it as bug but want to make sure it really is one.



Update



It's not Firefox, it's appmenu-gtk*:



$ grep "Unable to connect to dbus" -rF /usr
Binary file /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so matches
Binary file /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so matches


And after removing the warning changed to




Gtk-Message: 16:30:03.964: Failed to load module "appmenu-gtk-module".











share|improve this question

























  • Try running it via strace -f -o firefox.trace firefox https://askubuntu.com and maybe provide the output here or on paste.ubuntu.com It should reveal exact errors. ~/.dbus could be one possible issue, as EACCESS error results from any component of pathname having restricted permissions, but since you've tried dealing with the directory something else is the culprit

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:34











  • Thanks! The only filename appearing with EACCES is /usr/lib/firefox/fonts/.uuid.TMP-PtRd2i and it looks unrelated. I'll combine stderr with strace output, will it provide a better picture? Tried it but didn't find anything.

    – int_ua
    Feb 16 at 20:49











  • You don't have to combine anything. strace writes everything to stderr or file specified by -o flag so everything will be there once you run the command.

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:50











  • I meant strace -f firefox 2>&1 | tee firefox.trace to include the error in question in the file, here is the result: paste.ubuntu.com/p/NxgMmvmRxz

    – int_ua
    Feb 16 at 20:57






  • 1





    Alright. I'm gonna have to come back, since I'm low on battery in my laptop. I'll dig through the paste and let you know if I figure out anything

    – Sergiy Kolodyazhnyy
    Feb 16 at 21:04














0












0








0


1






The warning is




** (/usr/lib/firefox/firefox:1671): WARNING **: 22:14:54.614: Unable to connect to dbus: Could not connect: Permission denied




I tried using strace but can't find any related file errors there. I guess it could be AppArmor. Any suggestion on how to find the cause?



I started to search because no matter Visual bell setting is set to (gsettings set org.gnome.desktop.wm.preferences visual-bell false) Firefox flashes whole window to inverse colors when search on page did not return any results and it's annoying. This was fixed by changing KDE settings.




  • libappmenu-gtk*-parser0 0.7.1-1

  • Firefox 65.0 (both installed through apt and downloaded)

  • D-Bus 1.12.12-1ubuntu1

  • Ubuntu 19.04


I had ~/.dbus/ owned by root somehow, but tried changing owner to my user recursively and deleting the folder. Both times nothing changed even after a complete reboot.



I would've reported it as bug but want to make sure it really is one.



Update



It's not Firefox, it's appmenu-gtk*:



$ grep "Unable to connect to dbus" -rF /usr
Binary file /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so matches
Binary file /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so matches


And after removing the warning changed to




Gtk-Message: 16:30:03.964: Failed to load module "appmenu-gtk-module".











share|improve this question
















The warning is




** (/usr/lib/firefox/firefox:1671): WARNING **: 22:14:54.614: Unable to connect to dbus: Could not connect: Permission denied




I tried using strace but can't find any related file errors there. I guess it could be AppArmor. Any suggestion on how to find the cause?



I started to search because no matter Visual bell setting is set to (gsettings set org.gnome.desktop.wm.preferences visual-bell false) Firefox flashes whole window to inverse colors when search on page did not return any results and it's annoying. This was fixed by changing KDE settings.




  • libappmenu-gtk*-parser0 0.7.1-1

  • Firefox 65.0 (both installed through apt and downloaded)

  • D-Bus 1.12.12-1ubuntu1

  • Ubuntu 19.04


I had ~/.dbus/ owned by root somehow, but tried changing owner to my user recursively and deleting the folder. Both times nothing changed even after a complete reboot.



I would've reported it as bug but want to make sure it really is one.



Update



It's not Firefox, it's appmenu-gtk*:



$ grep "Unable to connect to dbus" -rF /usr
Binary file /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so matches
Binary file /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libappmenu-gtk-module.so matches


And after removing the warning changed to




Gtk-Message: 16:30:03.964: Failed to load module "appmenu-gtk-module".








permissions firefox dbus apparmor






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 17 at 14:59







int_ua

















asked Feb 16 at 20:31









int_uaint_ua

4,368853111




4,368853111













  • Try running it via strace -f -o firefox.trace firefox https://askubuntu.com and maybe provide the output here or on paste.ubuntu.com It should reveal exact errors. ~/.dbus could be one possible issue, as EACCESS error results from any component of pathname having restricted permissions, but since you've tried dealing with the directory something else is the culprit

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:34











  • Thanks! The only filename appearing with EACCES is /usr/lib/firefox/fonts/.uuid.TMP-PtRd2i and it looks unrelated. I'll combine stderr with strace output, will it provide a better picture? Tried it but didn't find anything.

    – int_ua
    Feb 16 at 20:49











  • You don't have to combine anything. strace writes everything to stderr or file specified by -o flag so everything will be there once you run the command.

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:50











  • I meant strace -f firefox 2>&1 | tee firefox.trace to include the error in question in the file, here is the result: paste.ubuntu.com/p/NxgMmvmRxz

    – int_ua
    Feb 16 at 20:57






  • 1





    Alright. I'm gonna have to come back, since I'm low on battery in my laptop. I'll dig through the paste and let you know if I figure out anything

    – Sergiy Kolodyazhnyy
    Feb 16 at 21:04



















  • Try running it via strace -f -o firefox.trace firefox https://askubuntu.com and maybe provide the output here or on paste.ubuntu.com It should reveal exact errors. ~/.dbus could be one possible issue, as EACCESS error results from any component of pathname having restricted permissions, but since you've tried dealing with the directory something else is the culprit

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:34











  • Thanks! The only filename appearing with EACCES is /usr/lib/firefox/fonts/.uuid.TMP-PtRd2i and it looks unrelated. I'll combine stderr with strace output, will it provide a better picture? Tried it but didn't find anything.

    – int_ua
    Feb 16 at 20:49











  • You don't have to combine anything. strace writes everything to stderr or file specified by -o flag so everything will be there once you run the command.

    – Sergiy Kolodyazhnyy
    Feb 16 at 20:50











  • I meant strace -f firefox 2>&1 | tee firefox.trace to include the error in question in the file, here is the result: paste.ubuntu.com/p/NxgMmvmRxz

    – int_ua
    Feb 16 at 20:57






  • 1





    Alright. I'm gonna have to come back, since I'm low on battery in my laptop. I'll dig through the paste and let you know if I figure out anything

    – Sergiy Kolodyazhnyy
    Feb 16 at 21:04

















Try running it via strace -f -o firefox.trace firefox https://askubuntu.com and maybe provide the output here or on paste.ubuntu.com It should reveal exact errors. ~/.dbus could be one possible issue, as EACCESS error results from any component of pathname having restricted permissions, but since you've tried dealing with the directory something else is the culprit

– Sergiy Kolodyazhnyy
Feb 16 at 20:34





Try running it via strace -f -o firefox.trace firefox https://askubuntu.com and maybe provide the output here or on paste.ubuntu.com It should reveal exact errors. ~/.dbus could be one possible issue, as EACCESS error results from any component of pathname having restricted permissions, but since you've tried dealing with the directory something else is the culprit

– Sergiy Kolodyazhnyy
Feb 16 at 20:34













Thanks! The only filename appearing with EACCES is /usr/lib/firefox/fonts/.uuid.TMP-PtRd2i and it looks unrelated. I'll combine stderr with strace output, will it provide a better picture? Tried it but didn't find anything.

– int_ua
Feb 16 at 20:49





Thanks! The only filename appearing with EACCES is /usr/lib/firefox/fonts/.uuid.TMP-PtRd2i and it looks unrelated. I'll combine stderr with strace output, will it provide a better picture? Tried it but didn't find anything.

– int_ua
Feb 16 at 20:49













You don't have to combine anything. strace writes everything to stderr or file specified by -o flag so everything will be there once you run the command.

– Sergiy Kolodyazhnyy
Feb 16 at 20:50





You don't have to combine anything. strace writes everything to stderr or file specified by -o flag so everything will be there once you run the command.

– Sergiy Kolodyazhnyy
Feb 16 at 20:50













I meant strace -f firefox 2>&1 | tee firefox.trace to include the error in question in the file, here is the result: paste.ubuntu.com/p/NxgMmvmRxz

– int_ua
Feb 16 at 20:57





I meant strace -f firefox 2>&1 | tee firefox.trace to include the error in question in the file, here is the result: paste.ubuntu.com/p/NxgMmvmRxz

– int_ua
Feb 16 at 20:57




1




1





Alright. I'm gonna have to come back, since I'm low on battery in my laptop. I'll dig through the paste and let you know if I figure out anything

– Sergiy Kolodyazhnyy
Feb 16 at 21:04





Alright. I'm gonna have to come back, since I'm low on battery in my laptop. I'll dig through the paste and let you know if I figure out anything

– Sergiy Kolodyazhnyy
Feb 16 at 21:04










1 Answer
1






active

oldest

votes


















1














From reading the output of strace linked in the comments , here's what I found:



[pid  4245] sendto(35, "AUTHrn", 6, MSG_NOSIGNAL, NULL, 0) = 6
[pid 4245] recvfrom(35, "REJECTED EXTERNALrn", 4096, 0, NULL, NULL) = 19
[pid 4245] sendto(35, "AUTH EXTERNAL 31303031rn", 24, MSG_NOSIGNAL, NULL, 0) = 24
[pid 4245] recvfrom(35, "OK f9c00ca7570590f878c4db8c5c686"..., 4096, 0, NULL, NULL) = 37


What this means is that firefox ( client ) is connected to D-Bus (server) socket which is referenced by file descriptor number 35, which you can see earlier in the strace output:



[pid  4245] connect(35, {sa_family=AF_UNIX, sun_path="/run/user/1001/bus"}, 110) = 0


and initiates negotiation via standard commands described in D-Bus documentation. According to the documentation:




If an AUTH command has no arguments, it is a request to list available mechanisms. The server must respond with a REJECTED command listing the mechanisms it understands, or with an error.




REJECTED EXTERNAL response indicates response that the bus accepts EXTERNAL method of authentication. So the warning message likely came from the initial exchange. However, it later succeeds with the AUTH EXTERNAL method.



Thus, the conclusion I draw from this is that




  1. this is not a firefox bug, though might be a false positive

  2. the fact that it is just a warning makes it somewhat insignificant issue, considering that you still can use firefox.


Additionally, /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so is a shared object which is meant to be used by multiple applications and it is not specific to firefox. Removing it may hide the warning, but it's probably not the best idea since this is a shared object and other applications may rely on it for proper working.



You can still submit a bug report with link to this answer to firefox developers as warning appears after initial negotiation method, whereas firefox probably could try other methods first before issuing the warning, however I wouldn't count on this being high-priority issue for the developers and likely it will be left with WONTFIX status.






share|improve this answer


























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    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',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1118828%2fwhat-are-possible-causes-of-appmenu-gtk-failing-to-connect-to-d-bus%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    From reading the output of strace linked in the comments , here's what I found:



    [pid  4245] sendto(35, "AUTHrn", 6, MSG_NOSIGNAL, NULL, 0) = 6
    [pid 4245] recvfrom(35, "REJECTED EXTERNALrn", 4096, 0, NULL, NULL) = 19
    [pid 4245] sendto(35, "AUTH EXTERNAL 31303031rn", 24, MSG_NOSIGNAL, NULL, 0) = 24
    [pid 4245] recvfrom(35, "OK f9c00ca7570590f878c4db8c5c686"..., 4096, 0, NULL, NULL) = 37


    What this means is that firefox ( client ) is connected to D-Bus (server) socket which is referenced by file descriptor number 35, which you can see earlier in the strace output:



    [pid  4245] connect(35, {sa_family=AF_UNIX, sun_path="/run/user/1001/bus"}, 110) = 0


    and initiates negotiation via standard commands described in D-Bus documentation. According to the documentation:




    If an AUTH command has no arguments, it is a request to list available mechanisms. The server must respond with a REJECTED command listing the mechanisms it understands, or with an error.




    REJECTED EXTERNAL response indicates response that the bus accepts EXTERNAL method of authentication. So the warning message likely came from the initial exchange. However, it later succeeds with the AUTH EXTERNAL method.



    Thus, the conclusion I draw from this is that




    1. this is not a firefox bug, though might be a false positive

    2. the fact that it is just a warning makes it somewhat insignificant issue, considering that you still can use firefox.


    Additionally, /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so is a shared object which is meant to be used by multiple applications and it is not specific to firefox. Removing it may hide the warning, but it's probably not the best idea since this is a shared object and other applications may rely on it for proper working.



    You can still submit a bug report with link to this answer to firefox developers as warning appears after initial negotiation method, whereas firefox probably could try other methods first before issuing the warning, however I wouldn't count on this being high-priority issue for the developers and likely it will be left with WONTFIX status.






    share|improve this answer






























      1














      From reading the output of strace linked in the comments , here's what I found:



      [pid  4245] sendto(35, "AUTHrn", 6, MSG_NOSIGNAL, NULL, 0) = 6
      [pid 4245] recvfrom(35, "REJECTED EXTERNALrn", 4096, 0, NULL, NULL) = 19
      [pid 4245] sendto(35, "AUTH EXTERNAL 31303031rn", 24, MSG_NOSIGNAL, NULL, 0) = 24
      [pid 4245] recvfrom(35, "OK f9c00ca7570590f878c4db8c5c686"..., 4096, 0, NULL, NULL) = 37


      What this means is that firefox ( client ) is connected to D-Bus (server) socket which is referenced by file descriptor number 35, which you can see earlier in the strace output:



      [pid  4245] connect(35, {sa_family=AF_UNIX, sun_path="/run/user/1001/bus"}, 110) = 0


      and initiates negotiation via standard commands described in D-Bus documentation. According to the documentation:




      If an AUTH command has no arguments, it is a request to list available mechanisms. The server must respond with a REJECTED command listing the mechanisms it understands, or with an error.




      REJECTED EXTERNAL response indicates response that the bus accepts EXTERNAL method of authentication. So the warning message likely came from the initial exchange. However, it later succeeds with the AUTH EXTERNAL method.



      Thus, the conclusion I draw from this is that




      1. this is not a firefox bug, though might be a false positive

      2. the fact that it is just a warning makes it somewhat insignificant issue, considering that you still can use firefox.


      Additionally, /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so is a shared object which is meant to be used by multiple applications and it is not specific to firefox. Removing it may hide the warning, but it's probably not the best idea since this is a shared object and other applications may rely on it for proper working.



      You can still submit a bug report with link to this answer to firefox developers as warning appears after initial negotiation method, whereas firefox probably could try other methods first before issuing the warning, however I wouldn't count on this being high-priority issue for the developers and likely it will be left with WONTFIX status.






      share|improve this answer




























        1












        1








        1







        From reading the output of strace linked in the comments , here's what I found:



        [pid  4245] sendto(35, "AUTHrn", 6, MSG_NOSIGNAL, NULL, 0) = 6
        [pid 4245] recvfrom(35, "REJECTED EXTERNALrn", 4096, 0, NULL, NULL) = 19
        [pid 4245] sendto(35, "AUTH EXTERNAL 31303031rn", 24, MSG_NOSIGNAL, NULL, 0) = 24
        [pid 4245] recvfrom(35, "OK f9c00ca7570590f878c4db8c5c686"..., 4096, 0, NULL, NULL) = 37


        What this means is that firefox ( client ) is connected to D-Bus (server) socket which is referenced by file descriptor number 35, which you can see earlier in the strace output:



        [pid  4245] connect(35, {sa_family=AF_UNIX, sun_path="/run/user/1001/bus"}, 110) = 0


        and initiates negotiation via standard commands described in D-Bus documentation. According to the documentation:




        If an AUTH command has no arguments, it is a request to list available mechanisms. The server must respond with a REJECTED command listing the mechanisms it understands, or with an error.




        REJECTED EXTERNAL response indicates response that the bus accepts EXTERNAL method of authentication. So the warning message likely came from the initial exchange. However, it later succeeds with the AUTH EXTERNAL method.



        Thus, the conclusion I draw from this is that




        1. this is not a firefox bug, though might be a false positive

        2. the fact that it is just a warning makes it somewhat insignificant issue, considering that you still can use firefox.


        Additionally, /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so is a shared object which is meant to be used by multiple applications and it is not specific to firefox. Removing it may hide the warning, but it's probably not the best idea since this is a shared object and other applications may rely on it for proper working.



        You can still submit a bug report with link to this answer to firefox developers as warning appears after initial negotiation method, whereas firefox probably could try other methods first before issuing the warning, however I wouldn't count on this being high-priority issue for the developers and likely it will be left with WONTFIX status.






        share|improve this answer















        From reading the output of strace linked in the comments , here's what I found:



        [pid  4245] sendto(35, "AUTHrn", 6, MSG_NOSIGNAL, NULL, 0) = 6
        [pid 4245] recvfrom(35, "REJECTED EXTERNALrn", 4096, 0, NULL, NULL) = 19
        [pid 4245] sendto(35, "AUTH EXTERNAL 31303031rn", 24, MSG_NOSIGNAL, NULL, 0) = 24
        [pid 4245] recvfrom(35, "OK f9c00ca7570590f878c4db8c5c686"..., 4096, 0, NULL, NULL) = 37


        What this means is that firefox ( client ) is connected to D-Bus (server) socket which is referenced by file descriptor number 35, which you can see earlier in the strace output:



        [pid  4245] connect(35, {sa_family=AF_UNIX, sun_path="/run/user/1001/bus"}, 110) = 0


        and initiates negotiation via standard commands described in D-Bus documentation. According to the documentation:




        If an AUTH command has no arguments, it is a request to list available mechanisms. The server must respond with a REJECTED command listing the mechanisms it understands, or with an error.




        REJECTED EXTERNAL response indicates response that the bus accepts EXTERNAL method of authentication. So the warning message likely came from the initial exchange. However, it later succeeds with the AUTH EXTERNAL method.



        Thus, the conclusion I draw from this is that




        1. this is not a firefox bug, though might be a false positive

        2. the fact that it is just a warning makes it somewhat insignificant issue, considering that you still can use firefox.


        Additionally, /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libappmenu-gtk-module.so is a shared object which is meant to be used by multiple applications and it is not specific to firefox. Removing it may hide the warning, but it's probably not the best idea since this is a shared object and other applications may rely on it for proper working.



        You can still submit a bug report with link to this answer to firefox developers as warning appears after initial negotiation method, whereas firefox probably could try other methods first before issuing the warning, however I wouldn't count on this being high-priority issue for the developers and likely it will be left with WONTFIX status.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 18 at 10:01

























        answered Feb 18 at 9:52









        Sergiy KolodyazhnyySergiy Kolodyazhnyy

        75.5k9155329




        75.5k9155329






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1118828%2fwhat-are-possible-causes-of-appmenu-gtk-failing-to-connect-to-d-bus%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

            ComboBox Display Member on multiple fields

            Is it possible to collect Nectar points via Trainline?