Once your session is active, greetd only waits for it to end and does not interact with anything. If you see gtkgreet again, while it could mean that greetd got restarted, it is more likely to mean that your display server crashed and greetd just did its job by letting you log back in.

journalctl should have some info about what happened and what, if anything, crashed.

it is more likely to mean that your display server crashed and greetd just did its job by letting you log back in

That does make more sense.

journalctl should have some info about what happened and what, if anything, crashed.

Digging through journalctl below are the logs from the GPU error up until the close of the user session. I don't see anything about sway (which is what I'm using) crashing or anything. Just the GPU itself resetting. I don't know a lot about low level stuff, but you are right, looks like this is not a greetd issue, so I guess you can close the issue. Maybe this is just a bad bug in Dota2 or maybe in mesa. Thanks for your assistance and for the free software that you provide. I appreciate it. :)

Jan 23 21:28:00 rooiratel-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] ERROR ring gfx timeout, signaled seq=1365332, emitted seq=1365334 Jan 23 21:28:00 rooiratel-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] ERROR Process information: process dota2 pid 17636 thread VKRenderThread pid 17890 Jan 23 21:28:00 rooiratel-pc kernel: amdgpu 0000:01:00.0: amdgpu: GPU reset begin! Jan 23 21:28:00 rooiratel-pc kernel: amdgpu: cp is busy, skip halt cp Jan 23 21:28:00 rooiratel-pc kernel: amdgpu: rlc is busy, skip halt rlc Jan 23 21:28:00 rooiratel-pc kernel: amdgpu 0000:01:00.0: amdgpu: BACO reset Jan 23 21:28:01 rooiratel-pc kernel: amdgpu 0000:01:00.0: amdgpu: GPU reset succeeded, trying to resume Jan 23 21:28:01 rooiratel-pc kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400500000). Jan 23 21:28:01 rooiratel-pc kernel: [drm] VRAM is lost due to GPU reset! Jan 23 21:28:01 rooiratel-pc kernel: [drm] UVD and UVD ENC initialized successfully. Jan 23 21:28:01 rooiratel-pc kernel: [drm] VCE initialized successfully. Jan 23 21:28:01 rooiratel-pc kernel: amdgpu 0000:01:00.0: amdgpu: recover vram bo from shadow start Jan 23 21:28:01 rooiratel-pc kernel: amdgpu 0000:01:00.0: amdgpu: recover vram bo from shadow done Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: amdgpu 0000:01:00.0: amdgpu: GPU reset(2) succeeded! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc kernel: [drm] Skip scheduling IBs! Jan 23 21:28:01 rooiratel-pc greetd[551]: pam_unix(greetd:session): session closed for user rooiratel

sway is most likely dying from the GPU reset. Make sure you're running sway 1.8, or try master of sway and wlroots.

If you want to collect sway's output, start sway as systemd-cat --identifier sway -- sway. This is best done by starting a wrapper script instead of starting sway directly - e.g., make /usr/local/bin/sway-run, make it executable and put this in it:

#!/bin/sh
# any environment variables you'd like
exec systemd-cat --identifier=sway -- sway $@

Then you will be able to read the output with journalctl -t sway.

Thanks, I'll give that a try sometime later in the week. Hopefully I can find something that I can submit as a bug request to sway.

I have set up my sway startup like you mentioned above, and can successfully read the output of  journalctl -t sway.

But now of course dota hasn't crashed since. I haven't updated any of my system packages yet, and I don't think there has been a dota update. But at least I am ready now in case it does happen again.

Okay it finally happened again. On the 25th of February.

I have attached a file with all the output of |journalctl -t sway since I made the changes you suggested.

Doesn't seem like it gives any more info than before.

And looking at line 87 of sway's common/ipc-client.c doesn't give me any more info that I can do something about.

struct ipc_response *ipc_recv_response(int socketfd) {
     char data[IPC_HEADER_SIZE];

     size_t total = 0;
     while (total < IPC_HEADER_SIZE) {
         ssize_t received = recv(socketfd, data + total, IPC_HEADER_SIZE 
- total, 0);
         if (received <= 0) {
             sway_abort("Unable to receive IPC response");  // line 87
         }
         total += received;
     }

|||

There is no attachment, so cannot see what you refer to.

And looking at line 87 of sway's common/ipc-client.c

IPC errors are uninteresting, as they are just clients that fail because sway died. Note that the output from sway will also contain the output of any application it started.

I just double checked my sent folder, and the last email I sent in this thread definitely had a .txt file attached. I guess sr.ht can't handle attachments in emails. I would have thought that it would either automatically copy it to something like paste.sr.ht, or at least be there in a normal email client.

Anyway here is a link to the contents of the file: https://pastebin.com/Vqp3FL4u

That's everything in the logs since I made the changes to my sway startup, until the 25th Feb.

It's just the boring IPC errors like you mentioned. So now I'm not sure where to look.

Adding -d would make sway enable debug output, which should make logs a bit more interesting.

Assuming there is no report of a greetd crash (see journalctl -u greetd - it would mention a panic in that case), then this is a sway or amdgpu issue and I'd recommend asking in #sway on IRC.

Okay I added -d and the debug logs are working.

The crash happened again today. I have put the debug logs for today on a pastebin site since last time the bug tracker deleted my email attachments.

Logs: https://pastebin.com/EukN02kp