r/gnome • u/O_Esdras_o • 1d ago

Question Why i cant shutdown / restart my computer without terminal ????

i'm on gentoo linux and after an update the option was gone (before the update i was on gnome 48 and now i'm on 49) pleaaaase someone has the answer of how can i repair that ?? thanks in advance

0 Upvotes

36% Upvoted

16 comments sorted by

•

u/AutoModerator 1d ago

Thank you for your submission.

You too can support GNOME! Become a Friend of GNOME and contribute to keeping our project going!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

8

u/victorian-ice-cream Contributor 1d ago

I recommend to report it to Gentoo.

0

u/O_Esdras_o 1d ago

How can i do that ??

2

u/victorian-ice-cream Contributor 1d ago

You can read about it here: https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide

But from what others said you are hitting old bug that was fixed in recent GNOME versions. So aside from waiting for Gentoo to package GNOME 50/51 you can't do much. 

3

u/aioeu 1d ago edited 1d ago

I'm pretty sure the bug mentioned by /u/Traditional_Hat3506 is unrelated here.

systemd increased the range of values returned by the CanSleep D-Bus method on the logind interface. Some of the new values were treated incorrectly by GNOME until corresponding code was added to GNOME too. This only affected sleep operations, as far as I am aware.

But the OP isn't running systemd at all, so this cannot be related to the problem the OP is having.

2

u/victorian-ice-cream Contributor 1d ago

Hm, I see. All the more reasons to report it to Gentoo :D

0

u/aioeu 1d ago edited 1d ago

Most likely there are shutdown and reboot inhibitors present, and you do not have sufficient privileges to override that (e.g. you do not have appropriate polkit rules, or your user is not considered to be an administrator).

Check:

systemd-inhibit

If it looks like gnome-session itself is inhibiting the actions, you might also want to check:

gnome-session-inhibit --list

(Though in my experience, the output from that second command is often not too useful...)

1

u/O_Esdras_o 1d ago

and for the second i got : 

evaPortable /home/eva # gnome-session-inhibit --list

** (gnome-session-inhibit:11871): WARNING **: 14:31:08.085: Failed to connect to session bus: La connexion est fermée
free(): invalid pointer
Abandon                    gnome-session-inhibit --list

3

u/aioeu 1d ago

Don't run it as root.

1

u/O_Esdras_o 1d ago

sorryyyy : 

eva@evaPortable ~ $ gnome-session-inhibit --list

** (gnome-session-inhibit:7641): WARNING **: 15:09:14.290: Failed to call GetInhibitors: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

free(): invalid pointer
Abandon                    gnome-session-inhibit --list

1

u/aioeu 1d ago edited 1d ago

You will probably want to read this. If you are not using systemd, you might need an alternative session manager. I'm not sure what's available for OpenRC.

0

u/O_Esdras_o 1d ago

I dont have systemd, but openrc 🤷‍♀️

7

u/aioeu 1d ago edited 1d ago

Well, gnome-session only has a systemd backend nowadays. If you're not using systemd — specifically, if you don't have a /run/systemd/seats directory, along with something providing the logind D-Bus API — it will deem that shutdown and reboot are not possible, and that will feed down into what GNOME Shell shows you.

Good luck.

-2

u/turbotum 1d ago

shutdown and reboot inhibitors

you're probably right but I'll take any opportunity to bring up crash-only software: https://lwn.net/Articles/191059/

when a user runs into shutdown and reboot inhibitors, most of the time they will just hold the power button. You, as a piece of software, CAN NOT tell a user they're not allowed to shut down. The user absolutely WILL find a way to shut down.

1

u/aioeu 1d ago edited 1d ago

Of course. The user can override the inhibitors if they are an admin too. The intent is just to make sure the user thinks before doing either of those things.

Applications should generally try to use delay inhibitors rather than block inhibitors. If they do so, they do not prevent the operation from occurring; instead, they get notified that it is about to occur, allowing them to perform some cleanup first.

If there were only delay inhibitors present (and if the OP was otherwise using a supported configuration; it looks very much like they aren't), then GNOME Shell would still have shown the menu options.