Unexpected Shutdowns

All Gurus once were Newbies
Forum rules
There are no such things as "stupid" questions. However if you think your question is a bit stupid, then this is the right place for you to post it. Please stick to easy to-the-point questions that you feel people can answer fast. For long and complicated questions prefer the other forums within the support section.
Before you post please read how to get help
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

Sorry for my late response, and thank you all for your inputs!
senjoz wrote:
Fri Sep 18, 2020 8:02 am

Observe outputs of sensors and CPU frequency and listen to the cooling fans. If the temperature would become extremely high and the CPU frequency would drop very low, cooling is not optimal for CPU capabilities.

Application stress can also stress memory, I/O and disk. Another similar application, stress-ng, has many additional features.

Regards, Jože
Thanks Jože for the hints. I had four terminals open and observed the following:
  • CPU was always around 2400 MHz
  • Until the fans kicked in, CPU temperature rose to almost 100°C
  • After the fans started working, CPU was stable between 75 and 80°C
1000 wrote:
Fri Sep 18, 2020 12:06 pm
Recently you showed a log above, but it's not complete, it was only from one day.
I rechecked with the journalctl since and until options, no segfaults on the days there was a shutdown.
1000 wrote:
Fri Sep 18, 2020 12:06 pm
And if you remember "Unexpected Shutdowns" at this time. This could be place where is the cause.
The error should be visible above " -- Reboot -- ".

Code: Select all

sudo journalctl -S "2020-09-17 12:00:00" -U "2020-09-17 14:00:00" | grep Reboot -B 100
Sep 17 12:00:01 gam0r-PC CRON[5044]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 17 12:00:01 gam0r-PC CRON[5045]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:00:01 gam0r-PC CRON[5047]: (root) CMD (timeshift --check --scripted)
Sep 17 12:00:01 gam0r-PC CRON[5046]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:00:01 gam0r-PC CRON[5048]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:00:01 gam0r-PC CRON[5049]: (grubi) CMD (scp pi@192.168.178.11:~/PWM/data/.pwds.crypt /home/grubi/Documents/Python/PWM/data)
Sep 17 12:00:01 gam0r-PC CRON[5045]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:00:01 gam0r-PC crontab[5090]: (root) LIST (root)
Sep 17 12:00:01 gam0r-PC crontab[5091]: (root) LIST (root)
Sep 17 12:00:01 gam0r-PC CRON[5044]: pam_unix(cron:session): session closed for user root
Sep 17 12:00:01 gam0r-PC CRON[5046]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:01:01 gam0r-PC CRON[5105]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:01:01 gam0r-PC CRON[5106]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:01:01 gam0r-PC CRON[5105]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:02:01 gam0r-PC CRON[5118]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:02:01 gam0r-PC CRON[5119]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:02:01 gam0r-PC CRON[5118]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:03:01 gam0r-PC CRON[5138]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:03:01 gam0r-PC CRON[5139]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:03:02 gam0r-PC CRON[5138]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:04:01 gam0r-PC CRON[5152]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:04:01 gam0r-PC CRON[5153]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:04:01 gam0r-PC CRON[5152]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:05:01 gam0r-PC CRON[5165]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:05:01 gam0r-PC CRON[5166]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:05:01 gam0r-PC CRON[5165]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:05:36 gam0r-PC wpa_supplicant[850]: wlp2s0: WPA: Group rekeying completed with 7c:ff:4d:3d:ee:0f [GTK=CCMP]
Sep 17 12:06:01 gam0r-PC CRON[5181]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:06:01 gam0r-PC CRON[5182]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:06:01 gam0r-PC CRON[5181]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:07:01 gam0r-PC CRON[5192]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:07:01 gam0r-PC CRON[5193]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:07:01 gam0r-PC CRON[5192]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:08:01 gam0r-PC CRON[5211]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:08:01 gam0r-PC CRON[5212]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:08:01 gam0r-PC CRON[5211]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:09:01 gam0r-PC CRON[5223]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:09:01 gam0r-PC CRON[5224]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:09:01 gam0r-PC CRON[5223]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:10:01 gam0r-PC CRON[5236]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:10:01 gam0r-PC CRON[5237]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:10:01 gam0r-PC CRON[5236]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:11:01 gam0r-PC CRON[5250]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:11:01 gam0r-PC CRON[5251]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:11:01 gam0r-PC CRON[5250]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:12:01 gam0r-PC CRON[5263]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:12:01 gam0r-PC CRON[5264]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:12:01 gam0r-PC CRON[5263]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:13:01 gam0r-PC CRON[5284]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:13:01 gam0r-PC CRON[5285]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:13:01 gam0r-PC CRON[5284]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:14:01 gam0r-PC CRON[5300]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:14:01 gam0r-PC CRON[5301]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:14:01 gam0r-PC CRON[5300]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:15:01 gam0r-PC CRON[5319]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:15:01 gam0r-PC CRON[5320]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:15:01 gam0r-PC CRON[5319]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:15:36 gam0r-PC wpa_supplicant[850]: wlp2s0: WPA: Group rekeying completed with 7c:ff:4d:3d:ee:0f [GTK=CCMP]
Sep 17 12:16:01 gam0r-PC CRON[5342]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:16:01 gam0r-PC CRON[5343]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:16:01 gam0r-PC CRON[5342]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:17:01 gam0r-PC CRON[5361]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep 17 12:17:01 gam0r-PC CRON[5364]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Sep 17 12:17:01 gam0r-PC CRON[5362]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:17:01 gam0r-PC CRON[5365]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:17:01 gam0r-PC CRON[5361]: pam_unix(cron:session): session closed for user root
Sep 17 12:17:01 gam0r-PC CRON[5362]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:17:40 gam0r-PC rtkit-daemon[1059]: Supervising 5 threads of 3 processes of 1 users.
Sep 17 12:17:40 gam0r-PC rtkit-daemon[1059]: Successfully made thread 5384 of process 1237 owned by '1000' RT at priority 5.
Sep 17 12:17:40 gam0r-PC rtkit-daemon[1059]: Supervising 6 threads of 3 processes of 1 users.
Sep 17 12:17:40 gam0r-PC rtkit-daemon[1059]: Supervising 5 threads of 3 processes of 1 users.
Sep 17 12:17:40 gam0r-PC rtkit-daemon[1059]: Successfully made thread 5385 of process 1237 owned by '1000' RT at priority 5.
Sep 17 12:17:40 gam0r-PC rtkit-daemon[1059]: Supervising 6 threads of 3 processes of 1 users.
Sep 17 12:18:01 gam0r-PC CRON[5388]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:18:01 gam0r-PC CRON[5389]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:18:01 gam0r-PC CRON[5388]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:19:01 gam0r-PC CRON[5407]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:19:01 gam0r-PC CRON[5408]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:19:01 gam0r-PC CRON[5407]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:20:01 gam0r-PC CRON[5425]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:20:01 gam0r-PC CRON[5426]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:20:01 gam0r-PC CRON[5425]: pam_unix(cron:session): session closed for user grubi
Sep 17 12:21:01 gam0r-PC CRON[5446]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 17 12:21:01 gam0r-PC CRON[5447]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 17 12:21:01 gam0r-PC CRON[5446]: pam_unix(cron:session): session closed for user grubi
-- Reboot --
 
What I read here (https://serverfault.com/questions/10023 ... omain-user) indicates that the opening/closing sessions is somewhat normal...

The other shutdown shows:

Code: Select all

sudo journalctl -S "2020-09-16 12:00:00" -U "2020-09-16 15:00:00" | grep Reboot -B 100

<a lot of the pcieport errors>
Sep 16 13:30:42 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
Sep 16 13:30:42 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Sep 16 13:30:42 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:   device [8086:9d14] error status/mask=00000001/00002000
Sep 16 13:30:42 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:    [ 0] RxErr                 
Sep 16 13:30:42 gam0r-PC rtkit-daemon[1083]: Supervising 6 threads of 4 processes of 1 users.
Sep 16 13:30:42 gam0r-PC rtkit-daemon[1083]: Successfully made thread 21420 of process 1242 owned by '1000' RT at priority 5.
Sep 16 13:30:42 gam0r-PC rtkit-daemon[1083]: Supervising 7 threads of 4 processes of 1 users.
Sep 16 13:30:42 gam0r-PC rtkit-daemon[1083]: Supervising 6 threads of 4 processes of 1 users.
Sep 16 13:30:42 gam0r-PC rtkit-daemon[1083]: Successfully made thread 21421 of process 1242 owned by '1000' RT at priority 5.
Sep 16 13:30:42 gam0r-PC rtkit-daemon[1083]: Supervising 7 threads of 4 processes of 1 users.
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:   device [8086:9d14] error status/mask=00000001/00002000
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:    [ 0] RxErr                 
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:   device [8086:9d14] error status/mask=00000001/00002000
Sep 16 13:30:47 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:    [ 0] RxErr                 
Sep 16 13:30:48 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
Sep 16 13:30:48 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Sep 16 13:30:48 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:   device [8086:9d14] error status/mask=00000001/00002000
Sep 16 13:30:48 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:    [ 0] RxErr                 
Sep 16 13:30:50 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
Sep 16 13:30:50 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Sep 16 13:30:50 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:   device [8086:9d14] error status/mask=00000001/00002000
Sep 16 13:30:50 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:    [ 0] RxErr                 
-- Reboot --
and

Code: Select all

sudo journalctl -S "2020-09-05 09:00:00" -U "2020-09-05 11:00:00" | grep Reboot -B 100

<a lot of the pcieport errors>
Sep 05 09:40:01 gam0r-PC CRON[5310]: pam_unix(cron:session): session opened for user grubi by (uid=0)
Sep 05 09:40:01 gam0r-PC CRON[5311]: (grubi) CMD (date >> /home/grubi/Documents/Shutdown_investigation/sensors.log && sensors >> /home/grubi/Documents/Shutdown_investigation/sensors.log)
Sep 05 09:40:01 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
Sep 05 09:40:01 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Sep 05 09:40:01 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:   device [8086:9d14] error status/mask=00000001/00002000
Sep 05 09:40:01 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:    [ 0] RxErr                 
Sep 05 09:40:01 gam0r-PC CRON[5310]: pam_unix(cron:session): session closed for user grubi
Sep 05 09:40:02 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4
Sep 05 09:40:02 gam0r-PC kernel: pcieport 0000:00:1c.4: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Sep 05 09:40:02 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:   device [8086:9d14] error status/mask=00000001/00002000
Sep 05 09:40:02 gam0r-PC kernel: pcieport 0000:00:1c.4: AER:    [ 0] RxErr                 
-- Reboot --
1000 wrote:
Sat Sep 19, 2020 1:56 am
So it can be used for temperature monitoring.
Cool, thanks for the hint. Added it, let's see if it shows something.
Larry78723 wrote:
Sat Sep 19, 2020 11:06 am
journalctl -b | grep -i "error\|warn\|fail" | tee >(gzip --stdout > journalctl_$USER.gz)
I attached the logs for the three shutdown dates (util the time of the shutdown) as error-logs.tar.gz.

Is this something interesting to look at?

Code: Select all

Sep 17 11:35:48 gam0r-PC thermald[845]: [WARN]sensor id 10 : No temp sysfs for reading raw temp
Sep 17 11:35:48 gam0r-PC thermald[845]: I/O warning : failed to load external entity "/etc/thermald/thermal-conf.xml"
antikythera wrote:
Sat Sep 19, 2020 11:21 am
run the following:

Code: Select all

sudo sensors-detect

Press ENTER all the way to the last decision to accept defaults. It will however prompt you to modify a file at the end. Check the contents first (open it in xed read-only, check for the suggested additions and close it straight after) and if the lines it wants to add are missing, allow the sensors-detect script to add them.
Can you give a hint what it does? I don't really get the man entry... Is there some interesting output you might want to look at after doing that?

I hope I added all requested logs and am so thanks for all of your efforts you put into this! Thank you! :D
Attachments
error-logs.tar.gz
(87.72 KiB) Downloaded 12 times
User avatar
antikythera
Level 8
Level 8
Posts: 2201
Joined: Thu Jul 02, 2020 12:52 pm

Re: Unexpected Shutdowns

Post by antikythera »

Running sensors-detect sometimes allows for better temperature readings from your laptop by correctly identifying the type of onboard sensors rather than using generic defaults. It could be that your temperature readings are currently out from the proper values.
Don't take life so seriously, nobody gets out alive anyway!
AMSTRAD CPC6128 - 128KB RAM, 3" Hitachi Floppy Diskette Drive, External Sony Cassette Recorder, Locomotive BASIC 1.1, CTM-644 Monitor
User avatar
SMG
Level 6
Level 6
Posts: 1480
Joined: Sun Jul 26, 2020 6:15 pm
Location: USA

Re: Unexpected Shutdowns

Post by SMG »

omg_me wrote:
Tue Sep 22, 2020 6:02 am
I had four terminals open and observed the following:
  • CPU was always around 2400 MHz
  • Until the fans kicked in, CPU temperature rose to almost 100°C
  • After the fans started working, CPU was stable between 75 and 80°C
This seems like it would fit those messages we saw earlier about the temps being critical then okay, especially if critical is in the 90-100°C range.

I don't know how long they were 75-80°C, but not only is that hot for a sustained temperature, but it is also not really that far from critical. (It's actually closer to critical than to desired temps of less than 50°C.)
omg_me wrote:
Tue Sep 22, 2020 6:02 am
Is this something interesting to look at?

Code: Select all

Sep 17 11:35:48 gam0r-PC thermald[845]: [WARN]sensor id 10 : No temp sysfs for reading raw temp
Sep 17 11:35:48 gam0r-PC thermald[845]: I/O warning : failed to load external entity "/etc/thermald/thermal-conf.xml"
The OP in this thread System Crash, Possible Sysfs Problem? was seeing the same I/O warning about thermal-conf.xml, but so far there didn't seem to be a tie-in with the issue.

I didn't see anything in the log files other than a plethora of PCIe Bus Errors corrected, but perhaps all those calls are making the cpu hot.
LM20.0 Cinnamon
senjoz
Level 3
Level 3
Posts: 175
Joined: Tue Jun 09, 2020 3:55 am

Re: Unexpected Shutdowns

Post by senjoz »

@omg_me

I read your first post again.
omg_me wrote:
Thu Aug 27, 2020 9:43 pm

Code: Select all

grubi    tty7         :0               Thu Aug 27 14:54    gone - no logout
runlevel (to lvl 5)   5.4.0-42-generic Thu Aug 27 14:54   still running
reboot   system boot  5.4.0-42-generic Thu Aug 27 14:54   still running
grubi    tty7         :0               Thu Aug 27 13:47 - crash  (01:06)
runlevel (to lvl 5)   5.4.0-42-generic Thu Aug 27 13:47 - 14:54  (01:06)
reboot   system boot  5.4.0-42-generic Thu Aug 27 13:47   still running
grubi    tty7         :0               Wed Aug 26 14:33 - crash  (23:14)
runlevel (to lvl 5)   5.4.0-26-generic Wed Aug 26 14:33 - 13:47  (23:14)
reboot   system boot  5.4.0-26-generic Wed Aug 26 14:33   still running
grubi    tty7         :0               Wed Aug 26 10:39 - crash  (03:53)
runlevel (to lvl 5)   5.4.0-26-generic Wed Aug 26 10:39 - 14:33  (03:53)
reboot   system boot  5.4.0-26-generic Wed Aug 26 10:39   still running
shutdown system down  5.4.0-26-generic Tue Aug 25 22:24 - 10:39  (12:15)
Output of "last -x" is somehow strange. Why are there lines with "still running" after lines with "crash"? I believe that the entry "still running" should be only for the current running session. If I run "last -x" on my machine, only the current running session has "still running". I have one crash in that output, but no "still running" after it.
omg_me wrote:
Thu Aug 27, 2020 9:43 pm
The last shutdown I observed was at Aug 27, 14:44.
You observed a shutdown on Aug 27 at 14:44. Were you at the machine at that time? Output of "last -x" reported that the crash happened at 13:47 + 1:06 = 14:53, runlevel 5 ended at 14:54 and reboot occurred at 14:54. What was going on in the 10 minutes between?

You can use "last -xF", you will get more accurate output.

You mentioned that you got a Cryptsetup unlock screen after crashes and reboots. Do you use encryption? Is everything okay with encryption? After so many crashes, is file system still okay? What software was active when crashes occurred? Is your disk okay? Check it. You can install nvme-cli and check also error-log on disk (sudo nvme error-log /dev/nvme0n1).
omg_me wrote:
Tue Sep 22, 2020 6:02 am
I had four terminals open and observed the following:

CPU was always around 2400 MHz
Until the fans kicked in, CPU temperature rose to almost 100°C
After the fans started working, CPU was stable between 75 and 80°C
Regarding CPU temperatures, my opinion is that temperature 40-50 °C at idle and 70-80 °C at 100 % load on all CPU cores is normal. All my four machines have CPU temperatures in that range. Not so normal is the temperature almost 100°C and frequency always around 2400 MHz. If you start the stress application at idle (CPU temperature 40-50 °C), the processor should go first to 4.0 GHz and when temperature becomes high frequency should drop to a lower value. Check UEFI, maybe there are settings for fan and/or cooling policy. But your machine did not shut down or reboot when the temperature was almost 100°C. Is then high CPU temperature really the reason for shutdowns or reboots?

Regards, Jože
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

antikythera wrote:
Tue Sep 22, 2020 6:06 am
Running sensors-detect sometimes allows for better temperature readings from your laptop by correctly identifying the type of onboard sensors rather than using generic defaults. It could be that your temperature readings are currently out from the proper values.
Thank you for your explanation!
SMG wrote:
Tue Sep 22, 2020 7:10 pm
I don't know how long they were 75-80°C, but not only is that hot for a sustained temperature, but it is also not really that far from critical. (It's actually closer to critical than to desired temps of less than 50°C.)
It was only that high while the stress command was running. Under "normal" workload, the CPU temperature seems to be between 35°C and 50°C. Under more advanced, but not 100% workload the temperatures were around 70°C.
SMG wrote:
Tue Sep 22, 2020 7:10 pm
I didn't see anything in the log files other than a plethora of PCIe Bus Errors corrected, but perhaps all those calls are making the cpu hot.
Since under "normal" workload, the temperature is not that high, I don't think those calls are really making the CPU hot. But I might be wrong there.
senjoz wrote:
Wed Sep 23, 2020 11:18 am
Output of "last -x" is somehow strange. Why are there lines with "still running" after lines with "crash"? I believe that the entry "still running" should be only for the current running session. If I run "last -x" on my machine, only the current running session has "still running". I have one crash in that output, but no "still running" after it.
I was very confused about that too. But now if I rerun last -xF, it looks better:

Code: Select all

grubi    tty7         :0               Fri Sep 25 08:12:53 2020   gone - no logout
runlevel (to lvl 5)   5.4.0-47-generic Fri Sep 25 08:10:22 2020   still running
reboot   system boot  5.4.0-47-generic Fri Sep 25 08:10:21 2020   still running
shutdown system down  5.4.0-47-generic Thu Sep 24 17:24:03 2020 - Fri Sep 25 08:10:21 2020  (14:46)
grubi    tty7         :0               Thu Sep 24 16:56:18 2020 - Thu Sep 24 17:24:01 2020  (00:27)
runlevel (to lvl 5)   5.4.0-47-generic Thu Sep 24 16:56:04 2020 - Thu Sep 24 17:24:03 2020  (00:27)
reboot   system boot  5.4.0-47-generic Thu Sep 24 16:56:02 2020 - Thu Sep 24 17:24:03 2020  (00:28)
shutdown system down  5.4.0-47-generic Wed Sep 23 15:43:02 2020 - Thu Sep 24 16:56:02 2020 (1+01:13)
grubi    tty7         :0               Wed Sep 23 13:16:16 2020 - Wed Sep 23 15:43:00 2020  (02:26)
runlevel (to lvl 5)   5.4.0-47-generic Wed Sep 23 13:16:07 2020 - Wed Sep 23 15:43:02 2020  (02:26)
reboot   system boot  5.4.0-47-generic Wed Sep 23 13:16:06 2020 - Wed Sep 23 15:43:02 2020  (02:26)
grubi    tty7         :0               Wed Sep 23 08:44:23 2020 - crash                     (04:31)
runlevel (to lvl 5)   5.4.0-47-generic Wed Sep 23 08:43:23 2020 - Wed Sep 23 13:16:07 2020  (04:32)
reboot   system boot  5.4.0-47-generic Wed Sep 23 08:43:21 2020 - Wed Sep 23 15:43:02 2020  (06:59)
shutdown system down  5.4.0-47-generic Tue Sep 22 22:41:58 2020 - Wed Sep 23 08:43:21 2020  (10:01)
grubi    tty7         :0               Tue Sep 22 20:58:18 2020 - Tue Sep 22 22:41:56 2020  (01:43)
runlevel (to lvl 5)   5.4.0-47-generic Tue Sep 22 20:58:01 2020 - Tue Sep 22 22:41:58 2020  (01:43)
reboot   system boot  5.4.0-47-generic Tue Sep 22 20:57:59 2020 - Tue Sep 22 22:41:58 2020  (01:43)
grubi    tty7         :0               Tue Sep 22 12:05:52 2020 - crash                     (08:52)
runlevel (to lvl 5)   5.4.0-47-generic Tue Sep 22 12:05:42 2020 - Tue Sep 22 20:58:01 2020  (08:52)
reboot   system boot  5.4.0-47-generic Tue Sep 22 12:05:41 2020 - Tue Sep 22 22:41:58 2020  (10:36)
shutdown system down  5.4.0-47-generic Tue Sep 22 12:05:06 2020 - Tue Sep 22 12:05:41 2020  (00:00)
grubi    tty7         :0               Tue Sep 22 09:15:58 2020 - Tue Sep 22 12:05:04 2020  (02:49)
runlevel (to lvl 5)   5.4.0-47-generic Tue Sep 22 09:15:15 2020 - Tue Sep 22 12:05:06 2020  (02:49)
reboot   system boot  5.4.0-47-generic Tue Sep 22 09:15:14 2020 - Tue Sep 22 12:05:06 2020  (02:49)
shutdown system down  5.4.0-47-generic Sun Sep 20 19:47:33 2020 - Tue Sep 22 09:15:14 2020 (1+13:27)
grubi    tty7         :0               Sun Sep 20 18:37:06 2020 - Sun Sep 20 19:47:31 2020  (01:10)
runlevel (to lvl 5)   5.4.0-47-generic Sun Sep 20 18:36:54 2020 - Sun Sep 20 19:47:33 2020  (01:10)
reboot   system boot  5.4.0-47-generic Sun Sep 20 18:36:53 2020 - Sun Sep 20 19:47:33 2020  (01:10)
shutdown system down  5.4.0-47-generic Fri Sep 18 13:57:21 2020 - Sun Sep 20 18:36:53 2020 (2+04:39)
grubi    tty7         :0               Fri Sep 18 09:32:39 2020 - Fri Sep 18 13:57:19 2020  (04:24)
runlevel (to lvl 5)   5.4.0-47-generic Fri Sep 18 09:32:18 2020 - Fri Sep 18 13:57:21 2020  (04:25)
reboot   system boot  5.4.0-47-generic Fri Sep 18 09:32:16 2020 - Fri Sep 18 13:57:21 2020  (04:25)
shutdown system down  5.4.0-47-generic Fri Sep 18 09:30:08 2020 - Fri Sep 18 09:32:16 2020  (00:02)
grubi    tty7         :0               Fri Sep 18 08:35:00 2020 - Fri Sep 18 09:30:06 2020  (00:55)
runlevel (to lvl 5)   5.4.0-47-generic Fri Sep 18 08:34:18 2020 - Fri Sep 18 09:30:08 2020  (00:55)
reboot   system boot  5.4.0-47-generic Fri Sep 18 08:34:16 2020 - Fri Sep 18 09:30:08 2020  (00:55)
shutdown system down  5.4.0-47-generic Thu Sep 17 22:59:48 2020 - Fri Sep 18 08:34:16 2020  (09:34)
grubi    tty7         :0               Thu Sep 17 13:51:59 2020 - Thu Sep 17 22:59:46 2020  (09:07)
runlevel (to lvl 5)   5.4.0-47-generic Thu Sep 17 13:51:49 2020 - Thu Sep 17 22:59:48 2020  (09:07)
reboot   system boot  5.4.0-47-generic Thu Sep 17 13:51:47 2020 - Thu Sep 17 22:59:48 2020  (09:08)
grubi    tty7         :0               Thu Sep 17 11:36:15 2020 - crash                     (02:15)
runlevel (to lvl 5)   5.4.0-47-generic Thu Sep 17 11:35:48 2020 - Thu Sep 17 13:51:49 2020  (02:16)
reboot   system boot  5.4.0-47-generic Thu Sep 17 11:35:46 2020 - Thu Sep 17 22:59:48 2020  (11:24)
shutdown system down  5.4.0-47-generic Wed Sep 16 22:12:14 2020 - Thu Sep 17 11:35:46 2020  (13:23)
grubi    tty7         :0               Wed Sep 16 14:12:42 2020 - Wed Sep 16 22:12:12 2020  (07:59)
runlevel (to lvl 5)   5.4.0-47-generic Wed Sep 16 14:12:36 2020 - Wed Sep 16 22:12:14 2020  (07:59)
reboot   system boot  5.4.0-47-generic Wed Sep 16 14:12:35 2020 - Wed Sep 16 22:12:14 2020  (07:59)
grubi    tty7         :0               Wed Sep 16 09:46:15 2020 - crash                     (04:26)
runlevel (to lvl 5)   5.4.0-47-generic Wed Sep 16 09:46:08 2020 - Wed Sep 16 14:12:36 2020  (04:26)
reboot   system boot  5.4.0-47-generic Wed Sep 16 09:46:06 2020 - Wed Sep 16 22:12:14 2020  (12:26)

<no more entries with "still running">
senjoz wrote:
Wed Sep 23, 2020 11:18 am
You observed a shutdown on Aug 27 at 14:44. Were you at the machine at that time? Output of "last -x" reported that the crash happened at 13:47 + 1:06 = 14:53, runlevel 5 ended at 14:54 and reboot occurred at 14:54. What was going on in the 10 minutes between?
I was imprecise there, sorry. I only observed one of the shutdowns. I vaguely remember the screen turning black, but the backlight of the screen was still on, so something must still have been running.
All the other times I was not at the machine, but deduced the shutdown times from the last logs of my minutely cron-job.
senjoz wrote:
Wed Sep 23, 2020 11:18 am
Do you use encryption? Is everything okay with encryption? After so many crashes, is file system still okay?
Yes, I use encryption. So far I did not have problems opening a file or navigating the file system. Additionally I ran

Code: Select all

sudo badblocks -v  /dev/nvme0n1p1
Checking blocks 0 to 524287
Checking for bad blocks (read-only test): done  

Pass completed, 0 bad blocks found. (0/0/0 errors)
sudo badblocks -v  /dev/nvme0n1p2
Checking blocks 0 to 749567
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

sudo badblocks -v  /dev/nvme0n1p3
Checking blocks 0 to 498832383
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

sudo badblocks -v /dev/mapper/nvme0n1p3_crypt
Checking blocks 0 to 498815999
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

sudo badblocks -v /dev/mapper/vgmint-swap_1
Checking blocks 0 to 1003519
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
Should I run fsck as well?
senjoz wrote:
Wed Sep 23, 2020 11:18 am
What software was active when crashes occurred?
Usually there is only Firefox and/or Brave, a SSH terminal, VS Code with a couple of node.js applications and sometimes thunderbird running. But I think I also had a shutdown once, where no non-system program was running (in the foreground).
senjoz wrote:
Wed Sep 23, 2020 11:18 am
Is your disk okay? Check it. You can install nvme-cli and check also error-log on disk (sudo nvme error-log /dev/nvme0n1).

Code: Select all

Error Log Entries for device:nvme0n1 entries:64
.................
 Entry[ 0]   
.................
error_count  : 0
sqid         : 0
cmdid        : 0
status_field : 0(SUCCESS: The command completed successfully)
parm_err_loc : 0
lba          : 0
nsid         : 0
vs           : 0
cs           : 0
.................

<63 more lines like the above>
But I might need to re-run that after a shutdown, right?
senjoz wrote:
Wed Sep 23, 2020 11:18 am
If you start the stress application at idle (CPU temperature 40-50 °C), the processor should go first to 4.0 GHz and when temperature becomes high frequency should drop to a lower value. Check UEFI, maybe there are settings for fan and/or cooling policy. But your machine did not shut down or reboot when the temperature was almost 100°C. Is then high CPU temperature really the reason for shutdowns or reboots?
Sorry, I was imprecise again. During the spike to almost 100°C, the CPU frequency was around 3500MHz. The behaviour was pretty much how you described it.
No, the machine did not shut down when the temperature was almost 100°C, the fans kicked in and cooled them down to around 70°C.
I'm not sure. It seems like a reasonable explanation, because my shutdowns seem "random" and nothing else shows in the error logs.

I'm also in contact with Lenovo, they also asked about overheating problems.
senjoz
Level 3
Level 3
Posts: 175
Joined: Tue Jun 09, 2020 3:55 am

Re: Unexpected Shutdowns

Post by senjoz »

omg_me wrote:
Fri Sep 25, 2020 4:25 am

Code: Select all

shutdown system down  5.4.0-47-generic Thu Sep 17 22:59:48 2020 - Fri Sep 18 08:34:16 2020  (09:34)
grubi    tty7         :0               Thu Sep 17 13:51:59 2020 - Thu Sep 17 22:59:46 2020  (09:07)
runlevel (to lvl 5)   5.4.0-47-generic Thu Sep 17 13:51:49 2020 - Thu Sep 17 22:59:48 2020  (09:07)
reboot   system boot  5.4.0-47-generic Thu Sep 17 13:51:47 2020 - Thu Sep 17 22:59:48 2020  (09:08)
grubi    tty7         :0               Thu Sep 17 11:36:15 2020 - crash                     (02:15)
runlevel (to lvl 5)   5.4.0-47-generic Thu Sep 17 11:35:48 2020 - Thu Sep 17 13:51:49 2020  (02:16)
reboot   system boot  5.4.0-47-generic Thu Sep 17 11:35:46 2020 - Thu Sep 17 22:59:48 2020  (11:24)
shutdown system down  5.4.0-47-generic Wed Sep 16 22:12:14 2020 - Thu Sep 17 11:35:46 2020  (13:23)
Output of "last -xF" is also strange, for instance second line from the bottom
reboot system boot 5.4.0-47-generic Thu Sep 17 11:35:46 2020 - Thu Sep 17 22:59:48 2020 (11:24)
I understand this line as: this boot was active from 11:35:46 till 22:59:48. But, in the meantime there was a crash and reboot. How is this possible? Was there really a reboot? At normal shutdowns and reboots journal logs line with "Sending SIGTERM to remaining processes". If you grep that lines

Code: Select all

journalctl | grep "Sending SIGTERM to remaining processes"
can you see lines with the time when "crashes" occurred (Sep 16 14:12:36, Sep 17 13:51:49, Sep 22 20:58:01 and Sep 23 13:16:07)?

It is interesting that crashes occur when you are not at the machine. Maybe the problem is related to the screen saver or power management or is triggered by the SSH terminal or Visual Studio Code (M$).

Regards, Jože


EDIT: Actually the red line is logical. If the operating system crashes, the end of the session cannot be recorded. Also lines with "Sending SIGTERM to remaining processes" cannot be recorded in the journal.
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

senjoz wrote:
Fri Sep 25, 2020 4:21 pm
It is interesting that crashes occur when you are not at the machine. Maybe the problem is related to the screen saver or power management or is triggered by the SSH terminal or Visual Studio Code (M$).
I think we are on the right path with this. I disabled the screen saver and the suspension. Up to now, there are no shutdowns. Next, I'm going to try to find out, what is the problem, the screen saver or the suspension...
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

I finally had some time to experiment yesterday and am pretty confident, that during the transition to the suspended state something goes wrong sometimes.
Any ideas on how to debug that? Or is that more likely a hardware thing?
1000
Level 3
Level 3
Posts: 174
Joined: Wed Jul 29, 2020 2:14 am

Re: Unexpected Shutdowns

Post by 1000 »

I need to rest and read what was going on before.

But try read this. https://wiki.ubuntu.com/DebuggingProcedures
senjoz
Level 3
Level 3
Posts: 175
Joined: Tue Jun 09, 2020 3:55 am

Re: Unexpected Shutdowns

Post by senjoz »

@omg_me
Can you see anything in Crash Reports (Menu - Sytem Reports - Crash Reports)?

Regards, Jože
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

senjoz wrote:
Sun Oct 18, 2020 2:47 am
@omg_me
Can you see anything in Crash Reports (Menu - Sytem Reports - Crash Reports)?

Regards, Jože
No, there are no entries there.
1000 wrote:
Sun Oct 18, 2020 1:41 am
I need to rest and read what was going on before.

But try read this. https://wiki.ubuntu.com/DebuggingProcedures
Thanks for the hint. I tried out

Code: Select all

sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend"
twice so far. Once my computer entered the sleep mode correctly, once it shut down and restarted.

The site mentions something about multiple hash matches statements, which could cause this. My dmesg output looks like this

Code: Select all

[Sun Oct 18 12:02:48 2020] PM:   Magic number: 0:203:321
[Sun Oct 18 12:02:48 2020] PM:   hash matches drivers/base/power/main.c:1517
[Sun Oct 18 12:02:48 2020] tty tty46: hash matches
[Sun Oct 18 12:02:48 2020] pci 0000:00:02.0: hash matches
But line three and four are not starting with hash matches. But I think that

There may well be another 'hash matches' line beyond that. If so, then you are in luck because the last one is the likely culprit. For example:

hash matches device i2c-9191

The only way to prove this is to remove the module prior to initiating suspend. Repeat as needed.

(see https://wiki.ubuntu.com/DebuggingKernelSuspend).

Do you think that causes the problems?
User avatar
SMG
Level 6
Level 6
Posts: 1480
Joined: Sun Jul 26, 2020 6:15 pm
Location: USA

Re: Unexpected Shutdowns

Post by SMG »

I had to take some time to go back through the thread as well.

Suspend is handled partially by the operating system and partially by the hardware (a hand-off from the OS is made to BIOS for the power states not specified by the OS).
omg_me wrote:
Sun Oct 18, 2020 6:30 am
I tried out

Code: Select all

sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend"
twice so far. Once my computer entered the sleep mode correctly, once it shut down and restarted.
Was the dmesg output for hashes you listed from the successful sleep or the one where it shut down? Or maybe the dmesg was the same for both?

The fact one attempt did not result in sleeping, but was a shutdown seems to indicate to me that the issue might be something in the "go to sleep" part of the process. Usually the issues are in waking up from suspend. I'm not sure what to check at this point other than maybe there is something else in the dmesg output when you compare the two times you did it that might be a clue to what is happening.
LM20.0 Cinnamon
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

SMG wrote:
Sun Oct 18, 2020 1:17 pm
Was the dmesg output for hashes you listed from the successful sleep or the one where it shut down? Or maybe the dmesg was the same for both?
I can't really tell, because the command messes up the timestamp on my system. I'll try to cause another shutdown and then add only the relevant parts of dmesg up here.
User avatar
SMG
Level 6
Level 6
Posts: 1480
Joined: Sun Jul 26, 2020 6:15 pm
Location: USA

Re: Unexpected Shutdowns

Post by SMG »

omg_me wrote:
Sun Oct 18, 2020 2:15 pm
I can't really tell, because the command messes up the timestamp on my system.
I did see where it said those commands messed with the RTC.
omg_me wrote:
Sun Oct 18, 2020 2:15 pm
I'll try to cause another shutdown and then add only the relevant parts of dmesg up here.
Usually people want to keep their computer running and not "cause a shutdown". :lol: (I know why you said it; it just struck my funny bone.)

Do check to make sure your computer's sleep and suspend settings are in sync. There are screensaver settings as well as power settings and both can act separately on the computer.
LM20.0 Cinnamon
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

SMG wrote:
Sun Oct 18, 2020 2:42 pm
Usually people want to keep their computer running and not "cause a shutdown". :lol: (I know why you said it; it just struck my funny bone.)
Hahaha, true. Ideally, this is where we will arrive :D
SMG wrote:
Sun Oct 18, 2020 2:42 pm
Do check to make sure your computer's sleep and suspend settings are in sync.
How do you mean that?
User avatar
SMG
Level 6
Level 6
Posts: 1480
Joined: Sun Jul 26, 2020 6:15 pm
Location: USA

Re: Unexpected Shutdowns

Post by SMG »

omg_me wrote:
Sun Oct 18, 2020 3:46 pm
SMG wrote:
Sun Oct 18, 2020 2:42 pm
Do check to make sure your computer's sleep and suspend settings are in sync.
How do you mean that?
The screensaver program and it locking the screen is separate from the power settings which can turn off the screen and suspend the computer. Look to see how the timing you might have set for each might overlap or interfere.
LM20.0 Cinnamon
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

Ah, got it. But as I was able to trigger a shutdown with the command I mentioned, I think it is independent of the settings?

By the way: My machine went to sleep without shutting down for at least 30 times. Now I want a shutdown to debug, it doesn't happen :lol: :roll:
User avatar
SMG
Level 6
Level 6
Posts: 1480
Joined: Sun Jul 26, 2020 6:15 pm
Location: USA

Re: Unexpected Shutdowns

Post by SMG »

It heard us talking about it and refuses to cooperate. Using reverse psychology just like on a kid. :D We should keep talking about it. :lol:

You were able to trigger the shutdown, but I wouldn't presume at this point that it is independent of the settings. It might be, but there could be something we just do not yet know. Those settings do interact with sleep mode.
LM20.0 Cinnamon
omg_me
Level 1
Level 1
Posts: 35
Joined: Thu Aug 27, 2020 9:16 pm

Re: Unexpected Shutdowns

Post by omg_me »

We should have used reversed-reversed psychology, because I was able to trigger a shutdown.

But my plan did not work out. I thought I could store

dmesg > dmesg_pre_shutdown.log


and compare it to /var/log/dmesg.0, and ideally the difference would contain an indicator what triggered the shutdown.

But my dmesg_pre_shutdown.log actually has more content than /var/log/dmesg.0 - so that seems to be a dead end - unless there is some way to configure the output to /var/log/dmesg to be written more frequently?
User avatar
SMG
Level 6
Level 6
Posts: 1480
Joined: Sun Jul 26, 2020 6:15 pm
Location: USA

Re: Unexpected Shutdowns

Post by SMG »

If you know the approximate time of the shutdown, can you see anything in syslog at that time that might indicate what happened? Syslog does contain kernel information (plus a whole lot more).
LM20.0 Cinnamon
Post Reply

Return to “Newbie Questions”