Power options do not work after logout about tuigreet

[apognu]

As for the inhibited behavior (1 and 2), greetd or tuigreet do not use your user account, so I don't think they're the one holding the inhibitor. Could you run w (and/or systemd-inhibit) on another console to try and see the process using tty1?

[Nuc1eoN]

Hm strangely there is nothing really?

20:59:03 up  1:02,  1 user,  load average: 0,95, 1,18, 1,01
USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
nuc      tty2      20:58    6.00 s  0.01 s  0.01 s -/home/nuc/.cache/zsh4humans/v5/tmux/bin/tmux -u -S /tmp/z4h-tmux-1000-linux-1642994650 -f /home/nuc/.cache/zsh4humans/v5/zsh4humans/.tmux.conf -- set -g default-terminal screen ; new

Only my zsh session on tty2 from where I run the command.

And here's systemd-inhibit:

WHO            UID  USER PID   COMM           WHAT  WHY                                       MODE 
NetworkManager 0    root 572   NetworkManager sleep NetworkManager needs to turn off networks delay
UPower         0    root 1226  upowerd        sleep Pause device polling                      delay
swayidle       1000 nuc  55754 swayidle       sleep Swayidle is preventing sleep              delay

3 inhibitors listed.

[Nuc1eoN]

I have found out what is causing the issue: tmux
Since I am using zsh4hum for zsh I was (frankly unknowingly) using tmux.

I have temporalily switched to my bash setup where I do not have tmux running and it works flawlessly.

I am not sure why tmux is still running after log out. Maybe tuigreet itself runs inside tmux?
I do not really know anything about tmux however, as I said I didn't even know I was using it.

So either:

1. There's a configuration error on my part?
2. Tuigreet/Greetd needs handle tmux better
3. Tuigreet/Greetd is not fully compatible with tmux. Albeit this is not documented anywhere.
4. It's a tmux bug?

[apognu]

tuigreet (and as far as I know, greetd) does not have anything to do with tmux or any other shell, they are run directly.

I don't have your specific configuration, but maybe your session command actually starts a tmux daemon that could hold that inhibitor?

Does the same issue occur when you use a "dummy" command such as ls /tmp?

[Nuc1eoN]

I will need to revisit this and isolate the issues I think.

So it definitely has something to do with my zsh setup (powerlevel10 + zsh4humans, which in turn uses tmux).
The only thing I know really is that when I switch to bash the problem is gone. The tmux thing is my main suspicion though, not zsh itself.

[Nuc1eoN]

I am getting further. So it has nothing to do with zsh, but everything to do with tmux.

I have found the following steps to be reproducible:

1. Log into Wayland session using tuigreet.
2. Open Terminal emulator and simply execute tmux
3. You can log out now
4. Tuigreet is now unable to shutdown the system (only with Ctrl+Alt+Del)

Optional further steps:

1. Open TTY2
2. Execute htop and locate tmux
3. Kill tmux (F9+Enter)
4. Exit htop and exit TTY2
5. Switch to TTY1. Tuigreet is now able to shudown the system.

So apparently tmux survives the logout operation.

@apognu Do you find this to be reproducible on your part?

[apognu]

I use zsh and tmux myself and never had that issue. Regardless, I can reproduce your issue if, in order to "log out", I simply kill sway. When you do that, the tmux session persists (after all, this is one of the use cases for screen and tmux), you can verify that by running tmux list-sessions in your tty2, you could reattach and find the state of your session before your logged out.

On my side, I log out by using loginctl terminate-user to log out (a bit overkill overall, but fits my use case), which terminates all processes from that user, including my tmux sessions.

What do you use to log out of your session?

[apognu]

Well, at least this ticket has shown an issue with my handling of the power commands, I was supposed to suppress the outputs, but did not in the default case.

I will push a fix to correctly suppress the output and start thinking about a way to display any error shown on stderr.

[Nuc1eoN]

you can verify that by running tmux list-sessions in your tty2, you could reattach and find the state of your session before your logged out.

Yeah you are absolutely right about that I can confirm that is the case.

What do you use to log out of your session?

I am using wayfire, which in turn uses wlogout which in turn uses waylang-logout to log out of it's wayland session graphically.

Hm so where exactly needs the process to be improved? Was this also a problem on X? (I was never a tmux user so I dont know^^)
It just seems to me like this is a UI issue then, but I do not know how this is usually handled.

EDIT:
I have just tested that using wlogout's poweroff/restart works as expected, even with a tmux session running.
Isn't this the experience that the end user would expect from within his login manger, too?

[apognu]

I just tried wlogout, and trying to reboot when an inhibitor is present (by logging into tty2 or manually setting one) does prevent me from rebooting too, which makes sense, since wlogout seems to be running systemctl reboot (which, on systemd systems, shutdown is an alias to). That, I believe, is the expected behavior, power commands should be inhibited when instructed to.

What is weird is that my tmux does not set an inhibitor and, for that matter, my tmux does not survive logging out (including wlogout logout option, which actually does loginctl terminate-user That does not seem like something it would do by default.

Short of figuring out why your tmux acts that way, I could suggest, as a workaround, changing the power options used by tuigreet to use the "ignore inhibitors" option of systemctl power options, so something like --power-shutdown "systemctl reboot -i".

I cannot do that by default for two reasons:

• I need to support systemd without systemd.
• I do not believe ignoring inhibitors is such a good idea, and should not be a decision made by the greeter (especially on multi-user systems).

EDIT: Apparently, systemd's power commands require an interactive shell when doing this, so this doesn't even work through tuigreet on my systems.

[Nuc1eoN]

I just tried wlogout, and trying to reboot when an inhibitor is present (by logging into tty2 or manually setting one) does prevent me from rebooting too, which makes sense, since wlogout seems to be running systemctl reboot (which, on systemd systems, shutdown is an alias to). That, I believe, is the expected behavior, power commands should be inhibited when instructed to.

Weird, this is not the case for me. I tested loging into tty2, then going back to tty1 and run systemctl reboot works without hickups.

EDIT:
Also I need to take back something that I said before, the wayfire logout menu doesn't use wlogout, but actually uses wayland-logout. Although I could theoretically modify the logout command in my wayfire.ini to a different command, too. But that is the default.

What is weird is that my tmux does not set an inhibitor and, for that matter, my tmux does not survive logging out (including wlogout logout option, which actually does loginctl terminate-user That does not seem like something it would do by default.

Thus yes! I can attest that. Using loginctl terminate-user 1000 (I am not sure what the 1000 does, but that is what my termional recommended on pressing TAB) my tmux session gets killed, altogether with a potenially logged in user on tty2. Same obviously for wlogout which uses loginctl terminate-user. And tmux sessions also gone!

---

Now good, I understand that wayland-logout would not log me out if I am logged in on a different tty1.
ButI would expect it log log me out of my current tty ?? Like why am I still logged in to tty1 after running wayland-logout. I am trying to understand which part of the chain is making it such a bad user experience. I do not remember having such issues on X iirc.

Also as mentioned in my first paragraph, systemctl reboot works fine even if Im logged in on tty2, and I wonder why my systems behaviour (archlinux) deviates from yours.

[apognu]

Firstly, the 1000 in systemctl terminate-user 1000 probably is your user's UID, so you are instructing to end all active sessions for that user.

For inhibitors, current user is important, a user would be able to reboot the system if they are logged in in another tty, so apognu on tty1 would be able to reboot the system if apognu is also logged in on tty2 (this does not apply to other inhibitors like the ones set with systemd-inhibit). On the other hand, apognu on tty1 woud not be able to reboot the system if nuc is logged in on tty2.

This second scenario is what is happening here, in my opinion. nuc has an active tmux session, so greetd's user cannot reboot the system (remember that greetd, and therefore tuigreet, do not run either as your user, or as root).

I reproduced your scenario:

• Opened my sway session.
• Opened a terminal running tmux (so, creating a tmux session).
• Killing sway (through pkill sway). Here, my tmux sessions have survived and still attahed to my tty2 (the virtual console where sway was running).
• Logged into a second user in tty3 (akin to what greetd is doing).
• Tried to reboot through systemctl reboot.

The reboot operation is "properly" being inhibited by systemd since another user has an active session on `. As soon as I kill those tmux sessions, reboot can go through.

After having a peek at wayland-logout's code, it seems it only sends a kill signal to the compositor, which does not consider systemd's logind sessions, and therefore leaves your tmux sessions around, causing the issue your mentioned.

[apognu]

I'll close this since it does not seem to be within tuigreet's scope. Feel free to comment again, I'll open it up again if it turns out it is.