IPFire shutting down

General questions.
Post Reply
Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

IPFire shutting down

Post by Sitrucy » May 10th, 2017, 2:26 am

I have tried to figure out the issue, but I cannot. I am pretty competent with linux and computers in general. My ipfire installation is shutting itself down for no reason and I cannot find anywhere in the logs for a reason as to why. Any help would be grateful. Here is my logs around the time of shutdown.

Code: Select all

May  9 20:54:57 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=46.118.20.86 DST= LEN=40 TOS=0x00 PREC=0x20 TTL=45 ID=1567 PROTO=TCP SPT=49847 DPT=23 WINDOW=53925 RES=0x00 SYN URGP=0
May  9 20:55:01 Heimdall kernel: DROP_NEWNOTSYN IN=green0 OUT=red0 MAC=00:13:3b:0f:34:05:0c:fe:45:24:bc:35:08:00 SRC=10.10.26.4 DST= LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=52763 DF PROTO=TCP SPT=51093 DPT=443 WINDOW=1039 RES=0x00 ACK URGP=0
May  9 20:55:12 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=123.207.10.26 DST= LEN=40 TOS=0x00 PREC=0x20 TTL=236 ID=36843 PROTO=TCP SPT=53775 DPT=23 WINDOW=1024 RES=0x00 SYN URGP=0
May  9 21:21:57 Heimdall syslogd 1.5.1: restart.
May  9 21:21:57 Heimdall unbound: [1358:0] notice: init module 0: validator
May  9 21:21:57 Heimdall unbound: [1358:0] notice: init module 1: iterator
May  9 21:21:57 Heimdall unbound: [1358:0] info: start of service (unbound 1.6.1).
Also my system logs on the WUI show that the ntp synchronization was running right before shutdown. I believe it is the synchronizations causing the shutdown, but can find no evidence to support it. It is the only thing happening at most of the shutdowns in the system logs.

e1iminator
Posts: 31
Joined: January 4th, 2017, 5:39 pm

Re: IPFire shutting down

Post by e1iminator » May 10th, 2017, 5:51 am

check watcgdog timer

Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

Re: IPFire shutting down

Post by Sitrucy » May 10th, 2017, 11:23 am

Ive looked everywhere for watchdog timer logs and the only one i can find in any of the logs is this

Code: Select all

[    0.096756] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
I also see the watchdog running 4 seperate daemons for each cpu. Honestly I dont know how to check it other than the system logs. If there is another way please let me know and I will do more research into the issue and provide more information if I can for anyone to help with the issue. Just let me know if I need to provide anymore output for you guys. Also I turned off the NTP synchronization completely and the firewall has not shutdown since, but I would like to use the service and provide it to the rest of the network.

Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

Re: IPFire shutting down

Post by Sitrucy » May 10th, 2017, 1:34 pm

Nvm, shutting down the ntp server did not stop the issue it lasted about 16 hours and then shutdown again on its own. Pls any help would be grateful.

e1iminator
Posts: 31
Joined: January 4th, 2017, 5:39 pm

Re: IPFire shutting down

Post by e1iminator » May 10th, 2017, 2:38 pm

disable watchdog timer from the bios

i guess you are using a supermicro motherboard

Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

Re: IPFire shutting down

Post by Sitrucy » May 10th, 2017, 5:46 pm

I'm using an old Gateway lx6810-01 motherboard which does not have a watchdog timer. Unless my research is wrong. The only watchdog would be the one the kernel is running

User avatar
Deepcuts
Posts: 461
Joined: March 1st, 2016, 3:18 pm
Location: Romania

Re: IPFire shutting down

Post by Deepcuts » May 10th, 2017, 6:42 pm

Are you using an UPS?
Image
Image

Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

Re: IPFire shutting down

Post by Sitrucy » May 10th, 2017, 6:51 pm

I am not using an UPS. The last message written in all occasions is coming from an attack from outside the network. It is the same person with different IP addresses.

Code: Select all

May 10 11:06:13 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=216.218.206.105 DST=LEN=40 TOS=0x00 PREC=0x20 TTL=242 ID=54321 PROTO=TCP SPT=55051 DPT=2323 WINDOW=65535 RES=0x00 SYN URGP=0
May 10 11:07:29 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=187.58.83.161 DST= LEN=44 TOS=0x00 PREC=0x20 TTL=50 ID=52573 PROTO=TCP SPT=33394 DPT=23 WINDOW=36962 RES=0x00 SYN URGP=0
May 10 11:07:33 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=78.188.232.115 DST= LEN=40 TOS=0x00 PREC=0x20 TTL=42 ID=22886 PROTO=TCP SPT=32930 DPT=23 WINDOW=55757 RES=0x00 SYN URGP=0
May 10 11:08:17 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=91.211.2.108 DST= LEN=40 TOS=0x00 PREC=0x20 TTL=242 ID=26065 PROTO=TCP SPT=56614 DPT=3398 WINDOW=1024 RES=0x00 SYN URGP=0
May 10 11:08:49 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=194.135.45.26 DST= LEN=40 TOS=0x00 PREC=0x20 TTL=46 ID=9642 PROTO=TCP SPT=30977 DPT=23 WINDOW=8302 RES=0x00 SYN URGP=0
May 10 11:09:20 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=5.188.10.251 DST= LEN=40 TOS=0x00 PREC=0x20 TTL=244 ID=61254 PROTO=TCP SPT=43434 DPT=10001 WINDOW=1024 RES=0x00 SYN URGP=0
May 10 11:10:23 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=23.239.69.66 DST= LEN=441 TOS=0x00 PREC=0x20 TTL=51 ID=26837 DF PROTO=UDP SPT=5060 DPT=5060 LEN=421
May 10 11:10:53 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=217.251.124.54 DST=LEN=44 TOS=0x00 PREC=0x20 TTL=54 ID=61354 PROTO=TCP SPT=65414 DPT=23 WINDOW=63118 RES=0x00 SYN URGP=0
May 10 11:12:45 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=112.167.20.31 DST= LEN=40 TOS=0x00 PREC=0x20 TTL=238 ID=32138 PROTO=TCP SPT=24573 DPT=7547 WINDOW=14600 RES=0x00 SYN URGP=0
May 10 11:13:43 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=54.251.185.92 DST=LEN=52 TOS=0x00 PREC=0x20 TTL=106 ID=15057 DF PROTO=TCP SPT=63266 DPT=3389 WINDOW=8192 RES=0x00 SYN URGP=0
May 10 11:13:44 Heimdall kernel: DROP_INPUT IN=red0 OUT= MAC=00:13:3b:0f:34:06:58:97:bd:98:14:22:08:00 SRC=54.251.185.92 DST= LEN=52 TOS=0x00 PREC=0x20 TTL=106 ID=16219 DF PROTO=TCP SPT=64546 DPT=3389 WINDOW=8192 RES=0x00 SYN URGP=0

e1iminator
Posts: 31
Joined: January 4th, 2017, 5:39 pm

Re: IPFire shutting down

Post by e1iminator » May 10th, 2017, 7:32 pm

overheating?

Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

Re: IPFire shutting down

Post by Sitrucy » May 10th, 2017, 7:38 pm

hmmm..... could be. How would I see if it is being caused by overheating? Is there a way to log it in the logs just so I could tell that is what happened right before the shutdown?

bloater99
Posts: 482
Joined: October 13th, 2014, 3:47 pm

Re: IPFire shutting down

Post by bloater99 » May 10th, 2017, 7:52 pm

Do a visual exam of the motherboard. Check capacitors for swelling/bulging tops. Try a different power supply.
Image

Image

Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

Re: IPFire shutting down

Post by Sitrucy » May 10th, 2017, 10:25 pm

I have changed the power supply and did a visual examination of the motherboard. I did not find any bulging capacitors or tops, no unusual looking components whatsoever. I will keep everyone updated on the outcome of the new power supply.

petergunn
Posts: 15
Joined: October 5th, 2015, 10:18 pm

Re: IPFire shutting down

Post by petergunn » May 11th, 2017, 12:40 am

I had issues with mysterious crashes until I discovered ipfire was running out of disk space. I had originally partitioned 2Gb and it wasn't enough to handle updates for squid etc. I resized to 8gb and I've had no issues since. Worth a quick check to make sure you have free space.

-PG

Sitrucy
Posts: 8
Joined: May 10th, 2017, 2:16 am

Re: IPFire shutting down

Post by Sitrucy » May 12th, 2017, 5:21 am

So the Firewall has been running for a little over a day now with now shutdowns or issues. I had the original power supply in the case that came with the computer. My assumption is that it was old and not putting out enough power for the components on the motherboard. I installed a newer power supply that I had lying around. The specs say it is about 40W shy of what the original PS was supposed to be putting out. It is running fine now thank you guys for all of the help, I appreciate everyone who posted suggestions as to what could be wrong. Sorry for the late reply I was just wanting to at least wait 24 hours of non-stop running to ensure that it is working properly.
petergunn wrote:I had issues with mysterious crashes until I discovered ipfire was running out of disk space. I had originally partitioned 2Gb and it wasn't enough to handle updates for squid etc. I resized to 8gb and I've had no issues since. Worth a quick check to make sure you have free space.

-PG
I have a 200Gb drive installed so I knew that this was not the issue, that should be more than enough storage space for the proxy and other logs.

User avatar
Deepcuts
Posts: 461
Joined: March 1st, 2016, 3:18 pm
Location: Romania

Re: IPFire shutting down

Post by Deepcuts » February 2nd, 2019, 1:01 am

Just had a reboot (not a shutdown) without me requesting it.
In logs I can see:

agetty: checkname failed: Operation not permitted
shutdown: shutting down for system reboot
init: switching to runlevel: 6

The machine rebooted and it is working now, but I must say I have never experienced such a behavior from any of my linux machines. Ever.
Image
Image

Post Reply