FreeNAS rebooting after shutdown

Macgd016

Dabbler
Joined
Oct 3, 2020
Messages
27
I wonder if anyone has come across this before.

Every second time I shut down FreeNAS the server re-boots. Just to be clear the first time I shut down FN the server stays off, the second time I shut it down, the power goes off for 2 or 3 seconds, then it powers back on and re-boots. This is not random, I have tried it many times and it is always every other shutdown!

This happens whether the shut down is initiated by the Power button on the GUI or by a cron job but not if I use option 11 in Console or the on/off button on the server to initiate a power down (I do not cut the power!).

I have checked the BIOS and there is nothing there that will reboot the server
 
Last edited:

Kris Moore

SVP of Engineering
Administrator
Moderator
iXsystems
Joined
Nov 12, 2015
Messages
1,471
That is indeed odd. All FN does is issue an ACPI power-off request. I could suggest trying 12.0, since its new kernel and OS, perhaps a fix landed in FreeBSD which makes it stay shut-off for good.
 

Macgd016

Dabbler
Joined
Oct 3, 2020
Messages
27
Haha, having only just built 11.3 I'm not mad keen on starting again!!

Currently I've just put in two power off commands 5 minutes apart, hopefully that will do the job
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
That is indeed odd. All FN does is issue an ACPI power-off request.

It's not odd at all. ACPI sucks and I've seen this on random platforms, especially older ones, and Gigabyte in particular seems to have problems of the someone-didn't-whack-the-QA-dept-with-a-clue-by-four-hard-enough. Sometimes it'll do it for Linux too, sometimes not.

One of the reasons we push Supermicro heavily here in the forums. The random desktop boards aren't as likely to operate correctly as servers.
 

Macgd016

Dabbler
Joined
Oct 3, 2020
Messages
27
It's not odd at all. ACPI sucks and I've seen this on random platforms, especially older ones, and Gigabyte in particular seems to have problems of the someone-didn't-whack-the-QA-dept-with-a-clue-by-four-hard-enough. Sometimes it'll do it for Linux too, sometimes not.

One of the reasons we push Supermicro heavily here in the forums. The random desktop boards aren't as likely to operate correctly as servers.
You might be right but it seems unlikely that this is a case of not hitting the key hard enough as happens every second command and not randomly.

I'm only a dabbler and I'm sure there a lot of us here are just using second hand kit we have lying around to build a project. I'm sure we all appreciate the help that more knowledgeable members give us, I certainly do, but I don't think its helpful to continually knock the hardware people have after all most of this hardware has been functioning perfectly well in a Windows environment which tends to suggest that in many cases it will be FreeBSD which does not have the tolerance to work with all hardware.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
You might be right but it seems unlikely that this is a case of not hitting the key hard enough as happens every second command and not randomly.

I don't recall saying it happens randomly. I have in fact seen that exact "every other" thing happen.

I'm only a dabbler and I'm sure there a lot of us here are just using second hand kit we have lying around to build a project. I'm sure we all appreciate the help that more knowledgeable members give us, I certainly do, but I don't think its helpful to continually knock the hardware people have after all most of this hardware has been functioning perfectly well in a Windows environment which tends to suggest that in many cases it will be FreeBSD which does not have the tolerance to work with all hardware.

The problem with the PC world is that much of the hardware is manufactured in a race to the bottom; manufacturers put just enough effort into a design that it sorta-works on today's version of Windows. By way of comparison, Supermicro (and Dell and HP, at least on their server products) make their products to run as servers, with all the bells and whistles that servers require. When you look at some of the "also-rans" like Tyan or ASRock, you can find many unsanded rough edges on their gear as well, because they don't have the volume to pay some high powered BIOS guy the big bucks to make the esoteric things work. Someone who bothered to track this down might find that Windows uses a slightly different ACPI call to perform a shutdown, one that perhaps violates the standard in some obscure way, and that the Gigabyte board was relying on that. This kind of thing happens in the PC world. It sucks. It isn't the fault of FreeBSD or Linux if they're emitting a standards-compliant call that the hardware chokes on. Trying to make every bit of PC hardware work 100% correctly is a game that neither the FreeBSD nor Linux folks can win.

Anyways, it also isn't *my* fault that you're running FreeNAS on a non-server platform. This isn't recommended. You should expect that it could be problematic. I usually don't see this happen on real servers. I've seen all kinds of strange ACPI B/S, especially on older gear, because Windows XP was a s***show.
 

Macgd016

Dabbler
Joined
Oct 3, 2020
Messages
27
Well I have spent a happy few hours reading and trying out all sorts of suggested remedies for this issue. From the reading I have done it certainly is a wide spread issue that affects a number of manufacturers and operating systems including Windows and Ubuntu and many of the suggested fixes suggest the problem may have something to do with USB's or power to USB's although there is no particular view of why this is.

In my case I did manage to find a fix which was to enable ErP, with this on ACPI shutdown works flawlessly, unfortunately I want to use WOL which requires ErP so I'm still stuck with the problem! However, my first work around of using two shutdown -p now instructions 5 minutes apart works reliably, its not particularly elegant but it works so I will leave it at that.
 

Macgd016

Dabbler
Joined
Oct 3, 2020
Messages
27
That is indeed odd. All FN does is issue an ACPI power-off request. I could suggest trying 12.0, since its new kernel and OS, perhaps a fix landed in FreeBSD which makes it stay shut-off for good.
12.0 might well be a good idea, I have read that many people who had had working Ubuntu systems discovered this problem when they updated to Ubuntu 16, having read up on what is needed to do this (actually nothing just select Update!) it shouldn't be beyond me so I might give this a go soon.
 
Top