[SOLVED] Shutdown hangs Jessie i386

[ticojohn]

The computer occasionally hangs during shutdown. When it finally shuts down, after maybe 2 minutes, the messages on the screen flash by so fast that I don't get a chance to see where the problem is. I tried journalctl on the next boot but there is no journal information available. I also looked at systemctl but nothing is obvious to me, mainly because none of the info in systemctl is dated so I have no idea when things occurred.

So what tool, or what options for journalctl, can I use to see what happened at the last shutdown.

UPDATE: I tried using

Code: Select all

 journalctl --since=2017-04-05

and there are no entries for that time period, only for today. Maybe I am doing it incorrectly.

UPDATE 2: If what I have read is correct, then journals are not kept from previous shutdowns unless I do some kind of setup. Not sure exactly what I need to do as the only reference I have found thus far, is related to CentOs (or some such). Not sure where to go from here. Some explicit instructions would be helpful (and telling me to go to H--- would not be helpful. LOL) .

UPDATE 3: Okay. Maybe this is what I need to do (from /usr/share/doc/systemd/README.Debian)

Code: Select all

install -d -g systemd-journal /var/log/journal
setfacl -R -nm g:adm:rx,d:g:adm:rx /var/log/journal

If correct, this would apparently set up persistent logging. Will the first line actually create /var/log/journal or do I need to do that as root?
Once enabled, and I discover the problem, how do I turn off persistent logging?

[pylkko]

https://freedesktop.org/wiki/Software/s ... /#index2h1

[ticojohn]

https://freedesktop.org/wiki/Software/s ... /#index2h1

Thanks. That's totally clear to me.
Okay. After more reading it looks like this line

Code: Select all

systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0

from the referenced link goes in /etc/default/grub; something like this

Code: Select all

GRUB_CMDLINE_LINUX="systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0" 

Is that correct? And then I save the following script

Code: Select all

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /

as /usr/lib/systemd/system-shutdown/debug.sh and make it executable. An affirmative response would be welcome.

[Head_on_a_Stick]

Okay. Maybe this is what I need to do (from /usr/share/doc/systemd/README.Debian)

Code: Select all

install -d -g systemd-journal /var/log/journal
setfacl -R -nm g:adm:rx,d:g:adm:rx /var/log/journal

If correct, this would apparently set up persistent logging. Will the first line actually create /var/log/journal or do I need to do that as root?
Once enabled, and I discover the problem, how do I turn off persistent logging?

You should instead edit the file at /etc/systemd/journald.conf (as root!) and change this line:

Code: Select all

#Storage=auto

Edit that line so that it looks like this instead:

Code: Select all

Storage=persistent

To revert this change, simply comment out the line again.

For more, read the output of:

Code: Select all

man journald.conf

[ticojohn]

You should instead edit the file at /etc/systemd/journald.conf (as root!) and change this line:

Code: Select all

#Storage=auto

Edit that line so that it looks like this instead:

Code: Select all

Storage=persistent

To revert this change, simply comment out the line again.

For more, read the output of:

Code: Select all

man journald.conf

Hey, thanks man. That looks a lot more simple than the previous suggestion. I did read the man page but wasn't sure about making that change. I'll give it a try.

Just one more question, if I may. To then look at a previous days journal would I use something like

Code: Select all

journalctl -b -1

or will the journal just be continuous over whatever time frame I have persistent enabled?

[Head_on_a_Stick]

I do not understand your question, please read this general guide:

https://www.digitalocean.com/community/ ... stemd-logs

[ticojohn]

I do not understand your question, please read this general guide:

https://www.digitalocean.com/community/ ... stemd-logs

Sorry. What I meant was will the journal log just keep appending each time I shut down, and if so and if there is a lengthy file, is there a simple way to look for a specific date range? I suspect it might be something like

Code: Select all

journalctl --since=DATE 

I'll figure it out. Thanks HOAS

[cronoik]

You have a --since and an --until parameter to look for logs within a specific time frame.

[ticojohn]

You have a --since and an --until parameter to look for logs within a specific time frame.

Thanks. Figured it out.

[ticojohn]

Well, this is strange. I edited the journal.conf file to have persistent storage, and that seems to be working. I then commented out the line for persistent storage and after reboot all of the previous journal records are still there and the journal keeps growing in size. What do I do about that? I don't want the journal to grow forever and the --vacuum-size option is apparently not available for Jessie! YIKES!

[cronoik]

This is normal beheaviour.

..."auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes....Defaults to "auto".

If you don't want to keep the logs, set it to 'none' or delete the file. If you want to keep them, check the SystemMaxUse parameter.

[ticojohn]

This is normal beheaviour.

..."auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes....Defaults to "auto".

If you don't want to keep the logs, set it to 'none' or delete the file. If you want to keep them, check the SystemMaxUse parameter.

Thanks for that info.

I may have fixed the issue with the shutdown hanging. Not sure. Found this in the log.

Code: Select all

Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object 

Strange because the graphics and audio is handled by this chipset

Code: Select all

lspci -vnn | grep VGA -A 12
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller 

Anyway, the last time the system hung, and after waiting a couple of minutes, I did a CTRL-ALT-DLT and saw a couple of line indicating that the system was stopping and saving the audio card and video card information, but was not progressing past that point. So, I thought to myself, these problems started after upgrading my motherboard to an Intel i5 (Haswell) system. Aha, thought me (FINALLY)! So I installed, from jessie backports, xserver-xorg-video-intel and firmware-linux.

Have not seen the system hang during shutdown since doing that. Hope that solves that issue. Consider this closed.

[ticojohn]

This is normal beheaviour.

..."auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes....Defaults to "auto".

If you don't want to keep the logs, set it to 'none' or delete the file. If you want to keep them, check the SystemMaxUse parameter.

As I don't think I need a huge log file, I set MaxFileSec=2day . That should be sufficient to find any issues that crop up. Hope so. I can always change it if need be. Thanks for your feedback.

[ticojohn]

It appears that updating firmware-linux and xserver-xorg-video-intel, from jessie-backports, did NOT take care of the problem (Shutdown hangs), and I have not been able to find anything in any logs that would indicate what is causing the problem.

I did, however, find that if I Log Out of my XFCE session and then reboot, or shutdown, the system does not hang. Don't know what that might indicate. Some smart person (if they happen to read this) might have a solution. As for me, I'll just do the Log Out first and be done with it.

It may be interesting to note that I have Stretch (amd64) installed on a HDD and it does not seem to experience the "hang" issue. I need to keep my Jessie (i386) installation as there are some things that I use; primarily a printer with only 32 bit drivers, and I can't get it to run on 64 bit Stretch. So for the foreseeable future I'll be sticking with i386 systems. May install Stretch i386 on the HDD to see how things go before trying to update Jessie to Stretch. Jessie is on a SSD and I really like the speed but want to be sure all is good before updating. In fact, I may install Jessie on the HDD and go through the upgrade process just to be sure it all works smoothly.

Thanks for all the suggestions, even though they were mainly about journalctl and not directly related to the "hang" problem.

[bw123]

It appears that updating firmware-linux and xserver-xorg-video-intel, from jessie-backports, did NOT take care of the problem (Shutdown hangs), and I have not been able to find anything in any logs that would indicate what is causing the problem.

I did, however, find that if I Log Out of my XFCE session and then reboot, or shutdown, the system does not hang.

That's a workaround. That's good, but not really a solution, so i hope you keep trying for a real solution. At the very least you seem close to finding out the right place to file a bug report.

Thanks for all the suggestions, even though they were mainly about journalctl and not directly related to the "hang" problem.

I really didn't understand why the system journal was relevant. But the thought occurs, while sysV init is still available and working in jessie, have you thought about installing package sysvinit-core and seeing what happens?

[ticojohn]

I really didn't understand why the system journal was relevant. But the thought occurs, while sysV init is still available and working in jessie, have you thought about installing package sysvinit-core and seeing what happens?

Had not thought about it. Seems like another workaround.

[bw123]

Seems like another workaround.

I'm not blind, but this link seems relevant somehow?

http://www.afb.org/info/living-with-vis ... blem/12345

Discussion: Isolate the Problem

“So you have paid attention to being or feeling off-course and you discern there is a problem. Now what? Uncover the precise problem. Think through what has happened and isolate the deviation from the intended course. In other words, what is it that veered you off course or kept you from succeeding?”

By eliminating systemd from the possible causes of the problem you can 'see' the remaining possible causes.

By using sysV init you may also get some more info in individual logs under /var/log and it seems to me that systemd does not log as much information from it's 'units' as sysV does.

[ticojohn]

Seems like another workaround.

I'm not blind, but this link seems relevant somehow?

http://www.afb.org/info/living-with-vis ... blem/12345

Discussion: Isolate the Problem

“So you have paid attention to being or feeling off-course and you discern there is a problem. Now what? Uncover the precise problem. Think through what has happened and isolate the deviation from the intended course. In other words, what is it that veered you off course or kept you from succeeding?”

By eliminating systemd from the possible causes of the problem you can 'see' the remaining possible causes.

By using sysV init you may also get some more info in individual logs under /var/log and it seems to me that systemd does not log as much information from it's 'units' as sysV does.

I stand properly rebuked !

[ticojohn]

I've been doing quite a bit of reading on this issue and it was first reports about 2 years ago. The cause of the problem is not apparent to me, or many people much smarter than me, but seems to be related to jobs not halting when sent the message to do so. Many of the posts blame the aggressive way that systemd shuts down jobs. I am not smart enough to have a clue, so I'm just babbling. Logging out prior to reboot/shutdown seems to avoid the issue. Not sure where to go with this. I've tried to incorporate some things, such as enabling debug, but don't see anything helpful. Guess I'll just move on from this and deal with it.

However, it is interesting that I didn't see this issue until after I upgraded to a newer motherboard with Intel i5 processor. Maybe an issue with Jessie i386 and this particular motherboard (Gigabyte GA-H81M-H). Stretch amd64 does not hang on reboot on this hardware. HMMMM !

[dasein]

Discussion: Isolate the Problem

“...[Y]ou discern there is a problem. Now what? Uncover the precise problem.”

(Emphasis added)

By eliminating systemd from the possible causes of the problem you can 'see' the remaining possible causes.

Your point is quite well-taken, of course. And you're quite correct in assessing that systemd is indeed a very likely culprit, and that deploying sysV would therefore likely fix the problem. The larger issue for this OP is that any systematic approach focused on finding a solution might actually succeed; consider one viable alternative...

1) Look for a relevant systemd bug (ideally, Jessie-specific, since Stretch supposedly doesn't have the problem):
https://lmsptfy.com/?q=systemd%20shutdo ... debian.org

2) Sure enough, there are perhaps as many as 100. Click on the first link:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=788303

3) Wow. Sure sounds potentially pertinent. Is the bug fixed?

4) According to the bug report, yes, the bug is fixed. Is that fix available in jessie-backports?

5) Yes.

6) Consider applying fix, instead of merely bemoaning the problem (or raising obviously irrelevant issues such as video drivers ).

7) Repeat as necessary. Or install sysV. Or install Stretch and be done with it.

And therein lies the real issue: some folks would rather wallow in a problem than fix it.