My screen goes black -- How can I find out what's happening using journalctl?

Beaverfriend · 02-11-2021, 03:12 PM

Since I updated to Ubuntu 9.3.0-17ubuntu1~20.04 I have a strange issue:

My screen turns black and the keyboard is unresponsive. This happens about once a day if I work a few hours on my computer, and I can't connect it to some particular thing I'm doing.

I've been starting to investigate using journalctl like so:

Code:

journalctl --boot -1

But I can't seem to find anything suspicious when I look at the last lines before I had to make a hardware shutdown

Would be great to get some tips on how to continue!

frankbell · 02-11-2021, 07:08 PM

This is an excellent tutorial on journalctl: https://www.digitalocean.com/communi...e-systemd-logs

scasey · 02-11-2021, 07:19 PM

This is a complete WAG:
Perhaps the box is going into suspension/sleep/hibernation. Does it happen after a period of inactivity?
I’m not sure where that setting is for you, but I’d guess in power...

syg00 · 02-11-2021, 08:35 PM

In a similar vein, maybe it's just the screen timing out. Check the simple things first.
If the system really is dieing and not leaving any kernel logs, you will be in a world of hurt trying to figure that out.

Beaverfriend · 02-13-2021, 04:47 AM

Thanks for the input, and sorry for being unclear: It does happen while working, could be just a few secs after writing something, so I don't think it's screensaver related. I've now also completely disabled display power management to see if that could happen to solve the problem.

What I was thinking about regarding journalctl was mainly if I'm looking in the wrong way? Which switches should I use too see everything that could be relevant?

Since this often happen when I'm by the screen I have a quite narrow time frame to search.

ondoho · 02-13-2021, 05:27 AM

Quote:

Originally Posted by Beaverfriend

Code:

journalctl --boot -1

But I can't seem to find anything suspicious when I look at the last lines before I had to make a hardware shutdown

You need to look at the time stamps; when does the unresponsiveness occur?
That's what you need to find in the journal.
It won't necessarily be in "the last lines".

Beaverfriend · 02-13-2021, 09:50 AM

Quote:

Originally Posted by ondoho

You need to look at the time stamps; when does the unresponsiveness occur?
That's what you need to find in the journal.
It won't necessarily be in "the last lines".

Thanks for writing! Yes, I use

Code:

journalctl --boot -1 -S 16:12

to get to the place where I know it happened.

It turns out the computer is not unresponsive, it's just the screen going out and not being able to come back up (I have a laptop). If I have a second screen connected, that screen will stay on as usual. I can also change the brightness of the laptop screen while it's out, and can see those brightness changes in the journal after I restarted.

I was more thinking about if there are some events that are filtered out in the journal when I look at it the way I do. Is there a way too see more events that has taken place, or do I already see all events as standard?

dugan · 02-13-2021, 10:03 AM

Try to ssh in next time it happens.

lvm_ · 02-13-2021, 10:28 AM

Can you access console via ctrl-alt-Fn when it happens? Does network access work? Alt-SysReq?

Beaverfriend · 02-13-2021, 03:39 PM

Quote:

Originally Posted by dugan

Try to ssh in next time it happens.

Good idea, but I don't know if it would help me solve **what** has gone wrong if I still can't find anything in the logs.

Quote:

Originally Posted by lvm_

Can you access console via ctrl-alt-Fn when it happens? Does network access work? Alt-SysReq?

No, ctrl-alt-Fn doesn't work, but as I wrote in another post I've found out that an external screen connected does, so the computer is not unresponsive. I can open a terminal in that other screen etc. Could be something with the display drivers. I'll look into that a bit and post again if I can get more info on what's wrong.

syg00 · 02-13-2021, 05:41 PM

Everything that is logged is in the journal - if it ain't logged ... well, you get the idea.
Typically you want to reduce the amount of logs you see - i.e. only the important ones. See priority in the link frankbell gave. But if the screen is simply going away as in a (incorrect) timeout, it isn't likely to log the event.

lvm_ · 02-14-2021, 12:31 AM

Quote:

Originally Posted by Beaverfriend

as I wrote in another post I've found out that an external screen connected does

Sorry, missed that. Did you check .xsession-errors? Contrary to what is said above, journal does not contain everything.

syg00 · 02-14-2021, 12:57 AM

Indeed - things I don't care about, I don't care about. I shall attempt to be more inclusive in future.

Beaverfriend · 02-14-2021, 04:15 AM

Quote:

Originally Posted by lvm_

Sorry, missed that. Did you check .xsession-errors? Contrary to what is said above, journal does not contain everything.

That's also something to check. Good idea!

Thanks all for your suggestions and thoughts so far. I will delve deeper into the logs, but as for now it seems probably it's something with the display drivers.

Will post more info as soon as I have it.

Wish you all a beautiful day!

ondoho · 02-14-2021, 10:21 AM

Quote:

Originally Posted by Beaverfriend

Code:

journalctl --boot -1 -S 16:12

(...)
I was more thinking about if there are some events that are filtered out in the journal when I look at it the way I do. Is there a way too see more events that has taken place, or do I already see all events as standard?

"--boot -1" shows entries from the last uptime, i.e. before you rebooted.
Combining that with --since only makes sense if the start time was during or before that last uptime.

I believe the journal will include entries for the event of the problematic behaviour. Better to go a few seconds back in time though.