Freeze while shutdown is in progress


#1

:: TrueOS-Desktop-2017-12-30-UNSTABLE-x64-USB.img installed into a new BE

General information

boot environment now (N) … 12.0-CURRENT-201801051307 NR 2018-01-05
after restart ® … 12.0-CURRENT-201801051307 NR 2018-01-05
boot loader …………………………………… BSD
type ……………………… EFI
CPU ………………………………………………………… Intel® Core™ i7-6500U CPU @ 2.50GHz
number of cores ……………… 4
host ……………………………………………………… TrueOS-Infinity
memory ………………………………………………… 16384 MB available, 13299 MB free
OS git branch ……………………………………………………………………………………… trueos-master
OS git revision ………………………………………………………………………………… 5085b9023
OS kernel build time ………………………………………………………… Sat 2017 Dec 30 17:10:29 UTC
OS kernel identity …………………………………………… (uname -i) GENERIC
OS platform (architecture) ……………………… (uname -m) amd64
OS release level ………………………………………………… (uname -r) 12.0-CURRENT
OS version and patch level …… (freebsd-version) 12.0-CURRENT
TrueOS package set ………………… UNSTABLE
TrueOS version …………………………… TrueOS-Desktop-201712150936
uptime ………………………………………………… 14 mins
user …………………………………………………… martin

More (TrueOS Desktop):

desktop environment …… Lumina
sound card driver ………… pcm0: <Realtek ALC269 (Internal Analog)> (play/rec) default
wireless driver ……………… iwm0
X11 drivers ………………………… modesetting_drv.so

System freezes while shutdown after the message:

  • Saving dependency cache …
    ??? where can I find the log of the messages with the red/green stars (TrueOS-messages??) of the last session?

#2

look in the /var/log/ directory for log files

What do you mean “freezes”? How long did you wait?

could be any number of things


#3

I have seen the same thing, it doesn’t “freeze” perse, but when you hit shutdown it will stop in the middle of it, at random places, too, and it doesn’t always happen. I just hit the power button and let it shutdown.
I’ll make note of where it stops if it happens again.


#4

It’s been a hard hang for me - but last attempt to reproduce it didn’t hang.


#5

I have already looked in /var/log/ but could not find these messages. That fore I hope somebody knows an answer.

Waited the first time about 20 minutes before I did a power-off-shutdown.


#6

Hi,
I’ve experienced TrueOS hanging infinitely during shutdown also,
But it was during me struggling to install this first 2018 update (no BE is created) - still not solved…

Try looking in /var/log/messages
or have a look at the timestamps of the files in /var/log to find the proper log-file

BSD-regards
Ludensen


#7

from the terminal try

sudo pc-updatemanager startupdate

or logout, and drop to a terminal to do the same.

See if that makes a difference


#8

< unwanted thread-hijack>
Already tried that :slight_smile:

From pc-updatemanager.log:
Your update is staged and ready to install.
To reboot and begin the update run # pc-updatemanager startupdate
Creating stage BE…

BUT the BE never gets created…
and obviously running the command does only reboot into current BE w/o updating…
That’s why I came here, to see if other experienced the same problem
</unwanted thread-hijack>


#9

you do realise, on both STABLE and UNSTABLE, it needs to reboot twice for majoy upgrades now


#10

Doesn’t make a difference


#11

@Ludensen start a separate thread, so we can work on your issue


#12

Strange, after a few attempts, the problem has disappeared without me having changed anything in this regard.


#13

I think the last update fixed this issue. After my computer updated, I have not seen this happen since.


#14

Was there an update to TrueOS-Desktop-2017-12-30-UNSTABLE? I don’t think so. For reasons I have deactivated ‘Automatically perform updates’ within the Update Manager so I would have noticed an update.


#15

I’m on STABLE… I’ve only recently switched out one of my machines to Unstable, and that’s because I found the Boot Envioronments GUI on SysADM and noticed how easy it was to get back to a working copy after a corrupted update made my computer unusable. I’m not yet ready to commit all my machines to unstable, though. But if it works out with that machine, I will move my other machines to the Unstable branch.


#16

Has this been solved? I also experience - on both my computers running the latest stable version - stalling during shutdown. Doesn’t happen every time; no discernible pattern. Don’t know (yet) whether it also does that when shutting down from the command line.


#17

As root:
shutdown -h halts the system, after seeing the “syncing buffers …” message go to all zeros, you should see a message saying “Operating system halted, press any key to reboot” or something to that effect. Power typically stays on with -h. Once you see the syncing buffers message go to zeros, whacking power manually after that is safe.

shutdown -r you should see most of that plus a “Rebooting system”

shutdown -p is shutdown -h plus turns the power off if possible (I think this uses ACPI stuff).

I don’t know if anything is broken with that, since I leave my systems on unless I take a power hit or I reboot due to upgrade, so this is just “the way it’s supposed to work”.


#18

Latest: stalling during shutdown can also occur when shutting down from the CL with “shutdown -h now”.

I know that you chaps never sleep (bad idea) and therefore see no need for a shutdown mechanism. Still - something seems to be wrong and should be fixed.

Cheers, jhz


#19

Can you take a picture of the screen when it stalls? I’d like to see what the last few lines look like (basically, did all the buffers for the filesystems get flushed, the syncing messages).

In the past, did the shutdown -h command power off your machine or did you manually poke the power button after seeing a “…Halted…” message?

Test:
Can you try a shutdown -p now and see if that actually powers off the machine?

Reason:

Data points.
If shutdown -h shows that all the buffers finished syncing, but not a final “Operating system halted, press any key to reboot”, then an assumption is that the system finished shutting down, but is just not showing the final couple of messages. This is something that could have come in from upstream. Keep in mind that shutdown -h was never intended to power off a machine (that’s the way it’s worked for me since about FreeBSD 3.3) and if you don’t see the final “…Halted…” message, the system appears to be hung.

The shutdown -p data point tells us that the shutdown command is actually completing and can power off your machine. If this actually powers off the machine, retrain your fingers to do -p instead of -h. Unfortunately the -h on Linux powers off the machine so if you dual boot you get into “crap they’re different”.


#20


Liked to prevent me taking photos of the screen. That is why I asked for the log I haven’t found yet, assuming it does not exist.
Back to the shutdown issue: photo taken after shutdown -h. The system does not power-off, the last message I see is ‘Saving dependency cache’. Waited 3 minutes then took the photo. I haven’t seen the syncing buffers message with the latest UNSTABLE.
It’s the same with ‘shutdown -p’ but the machine powers off several seconds after the ‘Saving dependency cache’ message.