Netgate SG3100 restarting frequently

heper

logs don't indicate why it has crashed. doesn't it ask to send crashdumps ?

ayanbanerjee

Sorry, I didn't get any crash dump.. could you please help me on this.. how to get the dump file ?

Gertjan

After a crash, when you enter the GUI, you should see a notifications that informs you that a crash dump exists.

Btw : when entering the GUI, remove some or all packages (I would start with the real resource hogs like squid and bandwidthd for the duration of the tests)

jimp

Depending on the type of crash, it may not offer a crash dump. This doesn't look like the type of crash that generates a crash dump that the GUI would handle.

Signal 11 issues are tricky. They usually, but not always, indicate a physical problem of some sort: Overheating, unstable power, hardware issue, etc. They can also be software, but in this case since even the sysctl command is crashing that seems less likely.

First thing, get a backup from Diagnostics > Backup/Restore. Next, try moving it to a different power source, preferably a UPS or at least something with a power/line conditioner. Check the temperature in the GUI and see if it's getting overheated. Then, you might try to reinstall the operating system on that unit.

If all else fails, visit https://go.netgate.com/support/home and open a ticket and the support crew can assist.

msf2000

I'm having the same problem too. Spontaneous reboots overnight. Nothing in the logs of course. Still looking into it....

Uncle_Bacon

Does anyone have any updates to this? I am a new SG-3100 owner and I'm finding that for no apparent reason, the device just reboots. The logs show nothing to do with a possible reason why either... Is it possible the device is overheating? What are the temperature limits on these devices?

...
Oct 4 21:53:47	check_reload_status		Syncing firewall
Oct 4 21:53:47	php-fpm		/firewall_rules.php: Beginning configuration backup to .https://acb.netgate.com/save
Oct 4 21:53:48	php-fpm		/firewall_rules.php: End of configuration backup to https://acb.netgate.com/save (success).
Oct 4 21:53:56	check_reload_status		Syncing firewall
Oct 4 21:53:56	php-fpm		/firewall_rules_edit.php: Beginning configuration backup to .https://acb.netgate.com/save
Oct 4 21:53:57	php-fpm		/firewall_rules_edit.php: End of configuration backup to https://acb.netgate.com/save (success).
Oct 4 21:54:04	check_reload_status		Reloading filter
Oct 4 21:57:07	syslogd		kernel boot file is /boot/kernel/kernel
Oct 4 21:57:07	kernel		Copyright (c) 1992-2018 The FreeBSD Project.
Oct 4 21:57:07	kernel		Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
Oct 4 21:57:07	kernel		The Regents of the University of California. All rights reserved.
Oct 4 21:57:07	kernel		FreeBSD is a registered trademark of The FreeBSD Foundation.
Oct 4 21:57:07	kernel		FreeBSD 11.2-RELEASE-p3 #12 220591260a0(factory-RELENG_2_4_4): Thu Sep 20 10:03:17 EDT 2018
Oct 4 21:57:07	kernel		root@buildbot3:/crossbuild/244/obj/armv6/zusWWsAv/arm.armv6/crossbuild/244/pfSense/tmp/FreeBSD-src/sys/pfSense-SG-3100 arm
Oct 4 21:57:07	kernel		FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Oct 4 21:57:07	kernel		CPU: ARM Cortex-A9 r4p1 (ECO: 0x00000000)
...

Grimson

https://forum.netgate.com/topic/135376/solved-random-reboots/25

jimp

A reboot without any log entries like that is nearly always a physical cause, typically power or heat. I haven't seen either of mine reset for that but they tend to stay fairly comfortable where I have them.

msf2000

Some time ago, I identified the source of my random reboots. The culprit was snort signature updates. I had configured /tmp to be in RAM, and the system was running out of memory/drive space during the rule update. This caused a spontaeous reboot. After disabling the /tmp in RAM feature (and reducing the number of enabled rules), the reboots stopped and the platform is stable.

Uncle_Bacon

I appreciate the suggestions. I put it on a UPS for a more clean supply of power. The heat seems to hover around 60-63°C. However, through some further research followed by some trial and error, I have narrowed the issue to having a traffic shaper on a VLAN. Seems to be a common issue for some. I have since removed all VLAN traffic shapers and I've been up for nearly 24 hours. It was rebooting every hour before. Thanks for all the help!