Bug #12034
When running Nautilus from a Root Terminal, start it silently and immediately give the prompt back
100%
Description
starting nautilus from a root terminal is resulting in that error message :
(nautilus:7225): Gtk-WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
nautilus-wipe-Message: Initializing
** (nautilus:7225): CRITICAL **: Another desktop manager in use; desktop window won't be created
** (nautilus:7225): CRITICAL **: nautilus_menu_provider_get_background_items: assertion 'NAUTILUS_IS_MENU_PROVIDER (provider)' failed
** (nautilus:7225): CRITICAL **: nautilus_menu_provider_get_background_items: assertion 'NAUTILUS_IS_MENU_PROVIDER (provider)' failed
then nautilus is started. when closing the window, the terminal doesn’t give the prompt back.
when I tested it, I get this issue using the root terminal and a normal terminal (with ‘sudo nautilus’). but a few minutes later, I couldn’t reproduce the error anymore.
Subtasks
Related issues
Related to Tails - |
Rejected | 2015-10-19 | |
Blocks Tails - |
Resolved | 2017-06-29 | |
Blocked by Tails - |
Resolved | 2017-08-14 |
History
#1 Updated by goupille 2016-12-14 20:22:36
- related to
Bug #10391: Useless step in https://tails.boum.org/doc/first_steps/persistence/copy/ added
#2 Updated by intrigeri 2016-12-20 12:22:59
- Assignee changed from alant to goupille
- QA Check set to Info Needed
These warnings + behaviour are expected, and I doubt there’s anything we can do on our side to fix that. Can you please clarify why it’s a problem in practice, apart of confusing some users? Does it break anything?
#3 Updated by goupille 2016-12-20 12:45:32
well, it breaks our documentation (see Bug #10391).
either we ask people to close a perfectly working root terminal just to open a new one when the warning don’t show up (I think that’s a bit confusing), or we ignore it and people get a scary warning message that yell three times “CRITICAL” and they can’t follow the steps because the terminal is frozen.
there already have been some back and forth on this part of the documentation, so I thought that if there was a way to avoid this warning it would be easier, that’s why I opened a thicket.
#4 Updated by intrigeri 2017-03-20 13:24:37
So, if I got it right this ticket is really about the fact one doesn’t get the prompt back (which breaks the doc), rather than about noisy error messages (which is confusing but doesn’t break anything). If I understood this correctly, then:
- I’ll focus on fixing the 1st problem here, and will ignore the other one, that we can’t do much about, for now;
- please adjust the title and description of this ticket so it reflects its real purpose (currently it seems to be about a mistaken guess wrt. the root cause of the problem).
I confirm that on 2.11, one doesn’t get the prompt back after having closed the Nautilus window. On 3.0~beta2 I got the prompt back after waiting a few (5? 15?) seconds.
We could easily add a root-specific wrapper in /usr/local/sbin/nautilus
with the following content:
#!/bin/sh
exec /usr/bin/nautilus "$@" 2>/dev/null &
… and then typing “nautilus” in a root terminal will silently start Nautilus in the background, and immediately give the prompt back. Is this what you need to address Bug #10391?
Note the sbin
component of the path, that prevents this wrapper from affecting non-root users (as this would hide potentially useful error messages from the Journal).
#5 Updated by Anonymous 2017-06-27 11:17:31
- Subject changed from gtk-warning when trying to launch nautilus from a root terminal to When running Nautilus from the terminal, start it silently and immediately give the prompt back
- Status changed from New to Confirmed
- Assignee changed from goupille to intrigeri
- Target version set to Tails_3.2
- QA Check deleted (
Info Needed) - Type of work changed from Research to Code
Also confirming this behavior on 3.0.
Assigning to intrigeri to implement the proposed fix. Please adjust target version as needed.
#6 Updated by intrigeri 2017-06-29 10:23:18
- blocks
Feature #13234: Core work 2017Q3: Foundations Team added
#7 Updated by intrigeri 2017-07-24 06:50:54
- Subject changed from When running Nautilus from the terminal, start it silently and immediately give the prompt back to When running Nautilus from a Root Terminal, start it silently and immediately give the prompt back
#8 Updated by intrigeri 2017-07-24 07:18:55
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 10
- Feature Branch set to feature/12034-improve-ux-of-nautilus-in-root-terminal
#9 Updated by intrigeri 2017-07-24 19:40:52
- Assignee changed from intrigeri to anonym
- % Done changed from 10 to 50
- QA Check set to Ready for QA
#10 Updated by anonym 2017-08-14 16:17:51
- blocked by
Bug #13625: Root Terminal cannot start graphical applications added
#11 Updated by anonym 2017-08-14 16:18:14
Due to Bug #13625 the best testing of this I can do is in a non-“Root Terminal” where I ran sudo -i
. Technically that should be equivalent, but let’s truly make sure that exactly what we document works.
#12 Updated by anonym 2017-09-15 15:22:08
So apparently the new (Bug #12738) Root Terminal doesn’t have /usr/local/sbin:/usr/local/bin
in its $PATH
. I’m trying to figure out how to get them set…
#13 Updated by anonym 2017-09-15 16:06:52
anonym wrote:
> So apparently the new (Bug #12738) Root Terminal doesn’t have /usr/local/sbin:/usr/local/bin
in its $PATH
. I’m trying to figure out how to get them set…
Fixed!
#14 Updated by anonym 2017-09-15 17:23:41
- Status changed from In Progress to Fix committed
- Assignee deleted (
anonym) - % Done changed from 50 to 100
- QA Check changed from Ready for QA to Pass
#15 Updated by anonym 2017-09-15 20:50:11
- Status changed from Fix committed to In Progress
Applied in changeset commit:ce2a222041d84b0d6314d090a7b35a203bfeae82.
#16 Updated by anonym 2017-09-15 20:50:11
- Status changed from In Progress to Fix committed
Applied in changeset commit:0bc50bf5c43c518d1f538a540638e016a960c158.
#17 Updated by anonym 2017-09-28 18:53:42
- Status changed from Fix committed to Resolved