Similar, maybe related: "too quickly" switching of VTs also freezes system.
Manually starting all vts (systemctl start getty@tty2.service) overcomes this.

Managed to reproduce without opening X on VT - still with sound working for the running X session.

Also, this is the log entry for a functioning logging out of a VT:

Jan 14 03:46:54 arch_amos login[389]: pam_unix(login:session): session closed for user amos
Jan 14 03:46:54 arch_amos systemd[1]: getty@tty1.service has no holdoff time, scheduling restart.

Whereas when a logout freezes system, we get only the first line:

Jan 14 03:47:07 arch_amos login[4323]: pam_unix(login:session): session closed for user amos

and then the log ends.

Both point that the problem might be getty related.

what is "frozen" supposed to mean? Does the system react to any kinds of keypresses?

If even sshd hangs, what makes you think this is systemd's fault? Isn't this more likely kernel/driver issue?

System does not seem to react to keypresses, at least not as far as display is concerned; I will check more thoroughly whether keypresses still go through to the X session, and only display is cut off; however, I think this is not the case.

As far as I understand, systemd is, at least in part, responsible for managing session switches, incl. VT switches. Therefore, since the system still runs (audio output from online streaming continues normally), I assume that systemd somehow denies the X session of access to the display and keyboard, but still intercepts keypresses so a switch to another VT is also impossible.

As I have mentioned, sshd does not completely hang; it does respond to a connection, but fails to open a new session (at least as far as can be inferred from the output on the remote host). As journald logs stop after the fatal logout, I can't tell for sure what happens.

Lastly, this might be related to some issue with getty. However, even in the case where getty hangs, I'd expect systemd to eventually "forcefully" rescind access to display and keyboard and transfer it to the requested VT (that of the X session).

(In reply to amosonn from comment #3)
> System does not seem to react to keypresses, at least not as far as display
> is concerned; I will check more thoroughly whether keypresses still go
> through to the X session, and only display is cut off; however, I think this
> is not the case.
> 
> As far as I understand, systemd is, at least in part, responsible for
> managing session switches, incl. VT switches. Therefore, since the system
> still runs (audio output from online streaming continues normally), I assume
> that systemd somehow denies the X session of access to the display and
> keyboard, but still intercepts keypresses so a switch to another VT is also
> impossible.

logind subscribes to VT chnages, and can issue them. But VT change keypress are handled by your display server or by the kernel, logind is not involved.

> As I have mentioned, sshd does not completely hang; it does respond to a
> connection, but fails to open a new session (at least as far as can be
> inferred from the output on the remote host). As journald logs stop after
> the fatal logout, I can't tell for sure what happens.

This feels like a kernel hang of some kind, as userspace appears to be stuck entirely.

Note that pam_systemd on most distros is included in the PAM stack as non-fatal. Thus, whatever happens, if logind is stuck, you can still log in. Given that you cannot login this is likely caused by something else, not logind.
 
> Lastly, this might be related to some issue with getty. However, even in the
> case where getty hangs, I'd expect systemd to eventually "forcefully"
> rescind access to display and keyboard and transfer it to the requested VT
> (that of the X session).

Well, if the entire userspace is dead (which appears to be the case), then logind is dead too.

I checked, and pam_systemd.so is indeed optional for system-login. I will try reporting this to kernel.

Thanks for your attention!

This does not seem to be a systemd bug, closing.