Extremely slow (rather forever) shutdown on Linux Mint

[morpheus327]

Hi "sbroccolo"

You could take a look at any errors that might have occurred after shutdown as:

dmesg |tail

Don't think I quite got this part. How do you call desmg after initiating shutdown?
Once booted after shutdown (or rather having hard-pressed the power button to shutdown), desmg would have no history of the previous session, isn't it?

Sorry I'm bit confused...

[sbroccolo]

It writes to to the dmesg | tail log as it is shutting down. So, there is a possibility that there may be a helpful entry there showing what the last thing it was trying to do. Worth looking at is all I am saying.

[rambo919]

Might be premature but the upgrade to 18.2, including new kernel and lightdm, seems to have solved my particular case.

[morpheus327]

Might be premature but the upgrade to 18.2, including new kernel and lightdm, seems to have solved my particular case.

Ah I could try that for sure. Thanks!

[morpheus327]

I got these messages at shutdown. Would that help in resolving the mystery? Anyone?

[IBM29]

I have a Dell 1501 Laptop with a TL-56 1.8GHz Dual-Core, 4GB memory and 64GB SSD.

I upgraded from 18.1 (Xfce) to 18.2 (Xfce), including Light-DM and new Kernel. Using any 4.8x or 10.x Kernel breaks Restart and Shutdown. The system will hang with either the Mint Logo or a non-blinking cursor in the upper left corner.

I wish I could articulate the thought process that led me to the solution, but here it is:

I disabled PowerNow! within BIOS. (It's AMD's version of Intel's SpeedStep Technology)

Problem solved!

If you have an AMD system and can live with somewhat reduced battery life, this looks like a solution.

[MrJonas]

Hi, my shutdown is also quite slow (ca. 1min) while the boot is done in a few seconds (approx 5 after grub menu)

Code: Select all

jonas@jonas-Aspire ~ $ inxi -Fyz
Error 21: Width option requires an integer value of 80 or more.
You entered: z
jonas@jonas-Aspire ~ $ inxi -Fy80
System:    Host: jonas-Aspire Kernel: 4.13.0-36-generic x86_64 (64 bit)
           Desktop: Cinnamon 3.6.7  Distro: Linux Mint 18.3 Sylvia
Machine:   System: Acer (portable) product: Aspire VN7-591G v: V1.08
           Mobo: Acer model: Aspire VN7-591G v: V1.08
           Bios: Insyde v: V1.08 date: 09/12/2014
CPU:       Quad core Intel Core i7-4710HQ (-HT-MCP-) cache: 6144 KB 
           clock speeds: max: 3500 MHz 1: 2494 MHz 2: 2494 MHz 3: 2494 MHz
           4: 2494 MHz 5: 2494 MHz 6: 2494 MHz 7: 2494 MHz 8: 2494 MHz
Graphics:  Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
           Card-2: NVIDIA GM107M [GeForce GTX 860M]
           Display Server: X.Org 1.18.4 driver: nvidia
           Resolution: 1920x1080@60.02hz, 2560x1440@59.95hz
           GLX Renderer: GeForce GTX 860M/PCIe/SSE2
           GLX Version: 4.5.0 NVIDIA 384.111
Audio:     Card-1 Intel 8 Series/C220 Series High Definition Audio Controller
           driver: snd_hda_intel
           Card-2 Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller
           driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture v: k4.13.0-36-generic
Network:   Card-1: Qualcomm Atheros AR9462 Wireless Network Adapter
           driver: ath9k
           IF: wlp7s0 state: up mac: 10:08:b1:a6:6a:2b
           Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169
           IF: enp8s0 state: down mac: 20:6a:8a:9d:88:0e
Drives:    HDD Total Size: 1256.3GB (4.0% used)
           ID-1: /dev/sda model: TOSHIBA_THNSNJ25 size: 256.1GB
           ID-2: /dev/sdb model: WDC_WD10JPVX size: 1000.2GB
Partition: ID-1: / size: 57G used: 43G (80%) fs: ext4 dev: /dev/sda5
           ID-2: swap-1 size: 4.21GB used: 0.00GB (0%) fs: swap dev: /dev/sda6
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 61.0C mobo: 27.8C gpu: 57C
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 247 Uptime: 19 min Memory: 1691.1/15963.3MB
           Client: Shell (bash) inxi: 2.2.35 

here is also my dmesg |tail (as sbroccolo has suggested) for a slow shut down:

Code: Select all

[   63.287680] usb 3-10: new full-speed USB device number 11 using xhci_hcd
[   68.315671] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   68.523733] usb 3-10: Device not responding to setup address.
[   68.731669] usb 3-10: device not accepting address 11, error -71
[   68.851677] usb 3-10: new full-speed USB device number 12 using xhci_hcd
[   68.872847] usb 3-10: New USB device found, idVendor=0489, idProduct=e076
[   68.872853] usb 3-10: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   68.975309] Bluetooth: RFCOMM TTY layer initialized
[   68.975317] Bluetooth: RFCOMM socket layer initialized
[   68.975320] Bluetooth: RFCOMM ver 1.11

and this is after a fast shut down (few sec) -this happens, when I did not do much just boot and then reboot:

Code: Select all

[   12.044385] Bluetooth: BNEP filters: protocol multicast
[   12.044388] Bluetooth: BNEP socket layer initialized
[   24.916009] usb 3-10: device descriptor read/64, error -110
[   25.143929] usb 3-10: new full-speed USB device number 9 using xhci_hcd
[   30.291972] usb 3-10: device descriptor read/64, error -110
[   30.540966] usb 3-10: New USB device found, idVendor=0489, idProduct=e076
[   30.540969] usb 3-10: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   30.640681] Bluetooth: RFCOMM TTY layer initialized
[   30.640685] Bluetooth: RFCOMM socket layer initialized
[   30.640688] Bluetooth: RFCOMM ver 1.11

What is the number in the [ ] before the log? -if it is supposed to be the time then it's wrong; the second shut down took like 5 sec. (sorry for newbie question)

I don't know if that is of any help: I only have a keyboard and a mouse connected to the usb ports (because its in the dmesg).

[JackD313]

This long shutdown problem appeared for me over the last few days. Two recent changes I made were the recent kernel update (via Update Manager) and installing Private Internet Access VPN.

Turns out that shutting down with PIA active causes extended shutdown - 30 seconds to almost three minutes sometimes. Exiting PIA before shutdown results in normal (~2 second) shutdown. This is consistent over ten shutdowns with PIA active/inactive. Not sure why, as I'm new to Linux and not a real techie, but I thought this might help someone else coming here for answers.

p.s. Thanks for an amazing operating system. Two months into Linux Mint 18.3 and loving it. Not looking back...

[Reddog1]

Something you can try/do. Instead of choosing 'shutdown' from the menu option, choose 'logout'. It should log you out immediately and return you to the log-in screen. If it does as it should, instead of logging in, choose the button in the upper right corner (for xfce, Mate and Cinn may be different) and choose 'Quit'. That should take you to a block where you can choose 'Shutdown'. See if that does an immediate shutdown. Mine takes about 3 seconds, and when my machine would take an inordinate amount of time to shut off I started doing that. The entire process takes about 10 seconds on my Acer laptop.

[morpheus327]

After having struggled with this for over a year, finally the problem seems to have found some fix. Perhaps it was automatic, maybe due to an update, I'm not sure. Just want to mention that it was recurring until the past one week before I did the following things:

1. Rolled back to the original (rather I read somewhere LTS) kernel, which in this case was the 4.4 kernel. I was using the 4.15. Nevertheless, I went ahead and deleted every other one except the most recent 4.4 version which was 4.4.135.
2. Made sure to do a logoff before shutdown (ie

Code: Select all

gnome-session-quit; shutdown now

).

Ever since about a week that I did the above changes, I haven't had frozen shutdowns.

Thought I let you all know.

Best.

[AZgl1800]

I have been following your thread, and I am using a Custom Shortcut key
like these below.

Keyboard Custom Shortcut keys using => Control-Alt-O

and use one of these commands
systemctl poweroff works in 18.3 Cinnamon
shutdown now works in 18.3 Cinnamon
gnome-session-quit; shutdown now ( if you are using a gnome based Linux )

The 1st two work in 18.3 Cinnamon, the 3rd one will not.

and the reason for this post, is I got to wondering if there is any material difference between systemctl poweroff and shutdown now and going thru the Mouse Click menus to finally reach shutdown ?

[morpheus327]

and the reason for this post, is I got to wondering if there is any material difference between systemctl poweroff and shutdown now and going thru the Mouse Click menus to finally reach shutdown ?

My bad.

Reason for this post was to recommend
(1) Switching to LTS kernel and
(2) a log off followed by shutdown (no matter how its done, whether through console or shortcuts),
to have higher chances of achieving non-frozen shutdown.

[rambo919]

I find it rather strange that a normal shutdown itself does not first force a logoff.... a case of trying to be faster by taking dangerous shortcuts.

[morpheus327]

I find it rather strange that a normal shutdown itself does not first force a logoff.... a case of trying to be faster by taking dangerous shortcuts.

It was not that shutdown would always take foreveer. At some instances it would occur normally. Usually that was the case when I had to shutdown within a few minutes of booting. At other instances howeveer (which was say 80% of the time), the shutdown would lead to its splash screen and take forever. I don't know what a regular shutdown was missing... and a user-initiated logout followed by shutdown did different.

Could you elaborate how that shortcut was dangerous?

[rambo919]

The shortcut of trying to log out via shut down is problematic simply because it's that which causes the extra long shut downs.... simply shutting down leads to the system waiting for hanged processes in a way that logging out does not since the shutdown assumes a logout has already taken place and that it only still needs to wait for critical processes to close. Logging out can more easily force-close running processes because it's by it's own assumption not going to kill anything critical. Basically this chain of assumptions leads to the whole system potentially hanging because of one stubborn non-critical process that itself is hanging... this is something that (ironically enough) windows prevents by warning of programs that are taking extraordinary long to close and giving the option to force-close them during logout.... also it never shuts down directly before doing a complete logout leaving no assumption to chance.

I have only thought so deeply about all this because I noticed the exact same program causing hangs in both OS's during shutdown and have because of it more closely observed the differences in shutdown methodology though I might be a bit off on some of the technicalities. In Windows I can shutdown much much faster than in Linux when this problem occurs because then even going to a tty and manually inputting shutdown commands nothing happens.

[morpheus327]

Great insight. Thanks.
Though few folks mentioned above that I could look into some system logs etc. to seek which might be culprit-processes, I gave up after a wihle, because I wasn't able to spot them exactly. Perhaps that can be done through the dmesg command. I am open to learn how to do that. You said an exact same application caused hanged-OS in both windows and linux. While windows shows that information directly, may I know how were you able to dig it out in linux?

Appreciate your replies.

The shortcut of trying to log out via shut down is problematic simply because it's that which causes the extra long shut downs.... simply shutting down leads to the system waiting for hanged processes in a way that logging out does not since the shutdown assumes a logout has already taken place and that it only still needs to wait for critical processes to close. Logging out can more easily force-close running processes because it's by it's own assumption not going to kill anything critical. Basically this chain of assumptions leads to the whole system potentially hanging because of one stubborn non-critical process that itself is hanging... this is something that (ironically enough) windows prevents by warning of programs that are taking extraordinary long to close and giving the option to force-close them during logout.... also it never shuts down directly before doing a complete logout leaving no assumption to chance.

I have only thought so deeply about all this because I noticed the exact same program causing hangs in both OS's during shutdown and have because of it more closely observed the differences in shutdown methodology though I might be a bit off on some of the technicalities. In Windows I can shutdown much much faster than in Linux when this problem occurs because then even going to a tty and manually inputting shutdown commands nothing happens.

[rambo919]

There was no need for digging it was a simple deduction almost accidentally made. Having had the app running solely on linux and having this problem I eventually ragequit the OS and went back to win7 till now... will probably dualboot again when 19.1 comes out since win7 is becoming extremely buggy. Anyway when I loaded the app on win7 I noticed that shutting down and waiting for it to close.... it sometimes never closed until I used the force close option. qBittorrent, it has a bug where if there is ANY transfer happening it refuses to properly exit until all the currently active blocks have been transferred.... this can take a very very long time if either side has a slow transfer connection for a particular block. It only happens with active transfers, simply having it running causes no problems at all. Since it takes so long to properly close even closing it beforehand does not help but force-closing it on log off (in the win7 scenario anyway) works fine.