Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 23 replies
  • Subscribers 2 subscribers
  • Views 9074 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro Rebooting for no Reason

mario@unosquare.com
I have UTM 9 with a purchased subscription.
Here's the background info:
Had Astaro 8 in a physical machine serving 50 or 60 devices. It never crashed or gave me any issues at all.
Decided to virtualize in Hyper-V and upgrade to UTM 9 serving the same amount of devices. Server randomly reboots
Spent multiple hours with support, this form, log files, reconfiguring from scratch, etc. Nothing helped. I still exprienced random reboots.
Moved UTM 9 to a physical machine last Friday: same random reboots for no apparent reason.

This situation is extremely frustrating. I'm going to downgrade to 8 -- when all users leave the office and waste just a little bit more of my time to keep giving this distro a shot as I already paid for it.

If anyone has got ANY suggestion please help! I'm desperate and extremely frustrated now. Please do NOT suggest:
It's a UPS problem
CPU cooling issue
Reconfigure from scratch
Serious corruption


This thread was automatically locked due to age.
  • 0
    1. Have you checked the NUMA configuration on the VM? Is it properly configured?
    2. Have you tried using static memory instead of dynamic?

    Anything in the logs before the reboot?

    Bryan
  • 0 in reply to bryans2k
    Well... when you say reboot -- do you mean the Hyper-V host reboots, or just the VM?  As for reboots / crashes on physical hardware, that's likely due to bad or incompatible hardware.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0
    1. NUMA config is good. All of the other VMs run without a problem
    2. I don't think Linux supports dynamic memory so I never enable it for Linux VMs
    3. I see the exact same bahavior on a physical machine (current setup)
    4. The logs have nothing. Here's an extract:

    boot log:

    2013:03:18-09:48:53 gdl-firewall kernel: [    6.276929] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: discard
    2013:03:18-09:48:53 gdl-firewall kernel: [    6.290687] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: discard
    2013:03:18-09:48:53 gdl-firewall kernel: [    6.307816] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: discard
    2013:03:18-09:48:53 gdl-firewall kernel: [    6.319771] EXT4-fs (sda8): mounted filesystem with ordered data mode. Opts: discard
    2013:03:18-09:48:53 gdl-firewall kernel: [    6.824933] RED: starting, Copyright (c) 2009 Sven Schnelle 
    2013:03:18-09:48:55 gdl-firewall syslog-ng[2763]: Termination requested via signal, terminating;
    2013:03:18-09:48:55 gdl-firewall syslog-ng[2763]: syslog-ng shutting down; version='3.0.10'
    2013:03:18-09:52:56 gdl-firewall kernel: [    0.000000] Linux version 3.3.8-74.g487ae8c-smp (abuild@axgbuild) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Mon Jan 21 14:28:45 UTC 2013
    2013:03:18-09:52:56 gdl-firewall kernel: [    0.000000] BIOS-provided physical RAM map:
    2013:03:18-09:52:56 gdl-firewall kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
    2013:03:18-09:52:56 gdl-firewall kernel: [    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)


    Fallback log:

    2013:03:18-09:32:42 gdl-firewall [daemon[:D]ebug] rrdcached[3629]:  rotating journals
    2013:03:18-09:32:42 gdl-firewall [daemon[:D]ebug] rrdcached[3629]:  started new journal /var/log/reporting/rrd/rrd.journal.1363620762.335447
    2013:03:18-09:32:42 gdl-firewall [daemon[:D]ebug] rrdcached[3629]:  removing old journal /var/log/reporting/rrd/rrd.journal.1363613562.335442
    2013:03:18-09:35:58 gdl-firewall [daemon:info] irqd[3190]:  ppp1 ppp  
    2013:03:18-09:36:00 gdl-firewall [daemon:info] irqd[3190]:  ppp1 ppp  
    2013:03:18-09:48:55 gdl-firewall [daemon:info] acpid:  starting up
    2013:03:18-09:48:55 gdl-firewall [daemon:info] acpid:  1 rule loaded
    2013:03:18-09:48:55 gdl-firewall [daemon:info] acpid:  waiting for events: event logging is off
    2013:03:18-09:48:55 gdl-firewall [daemon:err] /usr/local/bin/reporter/admin-reporter.pl[2875]:  Cannot connect: Connection refused
    2013:03:18-09:48:55 gdl-firewall [daemon:err] /usr/local/bin/reporter/pfilter-reporter.pl[2874]:  Cannot connect: Connection refused
    2013:03:18-09:48:55 gdl-firewall [daemon:err] /usr/local/bin/reporter/websec-reporter.pl[2879]:  Cannot connect: Connection refused
    2013:03:18-09:48:56 gdl-firewall [user:notice] rchal:  powersave cpufreq governor could not be loaded
    2013:03:18-09:48:56 gdl-firewall [user:notice] rchal:  userspace cpufreq governor could not be loaded


    Middleware log:

    2013:03:18-09:36:00 gdl-firewall middleware[3848]: T core::Config::Changed:142() => nodes=0 objects=2 triggers=0
    2013:03:18-09:36:00 gdl-firewall middleware[3848]: T core::Config::load:267() => modules=6,4
    2013:03:18-09:36:00 gdl-firewall middleware[3848]: T main::top-level:257() => ending cycle 19, caught 0 signals, 0 children still running
    2013:03:18-09:49:01 gdl-firewall middleware[3851]: T main::top-level:62() => MiddleWare starting
    2013:03:18-09:49:01 gdl-firewall middleware[3851]: T main::top-level:210() => starting cycle 0, caught 0 signals
    2013:03:18-09:49:01 gdl-firewall middleware[3851]: T core::Config::Changed:132() => configversion=0


    Service Monitor Log:

    2013:03:18-09:28:53 gdl-firewall service_monitor[4653]: id="4000" severity="info" sys="System" sub="loadbalancing" name="Set Availability Group REF_NetAvaGdldirecto to 192.168.42.130"
    2013:03:18-09:28:55 gdl-firewall service_monitor[4653]: id="4000" severity="info" sys="System" sub="loadbalancing" name="REF_NetAvaUnosqDnsForwa ICMP 172.16.16.2 changed state to ONLINE"
    2013:03:18-09:28:55 gdl-firewall service_monitor[4653]: id="4000" severity="info" sys="System" sub="loadbalancing" name="Set Availability Group REF_NetAvaUnosqDnsForwa to 172.16.16.2"
    2013:03:18-09:28:55 gdl-firewall service_monitor[4653]: id="4000" severity="info" sys="System" sub="loadbalancing" name="REF_NetAvaGdldirecto ICMP 172.16.16.2 changed state to ONLINE"
    2013:03:18-09:28:55 gdl-firewall service_monitor[4653]: id="4000" severity="info" sys="System" sub="loadbalancing" name="Set Availability Group REF_NetAvaGdldirecto to 172.16.16.2"
    2013:03:18-09:49:06 gdl-firewall service_monitor[4657]: id="4000" severity="info" sys="System" sub="loadbalancing" name="Starting real server checker with 21 threads"
    2013:03:18-09:49:06 gdl-firewall service_monitor[4657]: id="4002" severity="info" sys="System" sub="loadbalancing" name="Open ICMPv4 socket"
    2013:03:18-09:49:06 gdl-firewall service_monitor[4657]: id="4002" severity="info" sys="System" sub="loadbalancing" name="Open ICMPv6 socket"
  • 0

    Well... when you say reboot -- do you mean the Hyper-V host reboots, or just the VM? As for reboots / crashes on physical hardware, that's likely due to bad or incompatible hardware.


    The Hyper-V host never reboots and none of the VMs show a single problem. The astaro is the only one rebooting. Time Sync integration service is off (obviously).

    The exact same random reboot behavior happens in brand new hardware.
  • 0 in reply to mario@unosquare.com
    Mario, I have a lot UTMV9 installations deployed, both on UTM hardware and custom hardware, and none of them reboot at random.  You might want to check the kernel / system logs on the UTM around the time of the reboot for clues.  As for Hyper-V --- well, we don't use it anywhere with Linux OS's given that VMware tends to run them better (and Windows too)... so I'll have to leave it up to others in regards to that.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0
    System Log (this repeats whenever a restart occurs)

    2013:03:18-09:53:08 gdl-firewall syslog-ng[2882]: Syslog connection established; fd='36', server='AF_INET(172.16.16.5:514)', local='AF_INET(0.0.0.0:0)'
    2013:03:18-09:53:08 gdl-firewall syslog-ng[2882]: Configuration reload request received, reloading configuration;
    2013:03:18-09:53:08 gdl-firewall syslog-ng[2882]: I/O error occurred while writing; fd='36', error='Operation not permitted (1)'
    2013:03:18-09:53:08 gdl-firewall syslog-ng[2882]: Syslog connection broken; fd='36', server='AF_INET(172.16.16.5:514)', time_reopen='60'
    2013:03:18-09:53:08 gdl-firewall ulogd[3842]: SIGTERM received
    2013:03:18-09:53:14 gdl-firewall system: System was restarted
    2013:03:18-09:53:15 gdl-firewall dns-resolver[4263]: No change to REF_LogMgmtProvisioningService :: logmgmt.astaro.com
    2013:03:18-09:53:15 gdl-firewall dns-resolver[4263]: No change to REF_NtpPool :: pool.ntp.org
    2013:03:18-09:53:26 gdl-firewall ntpd[4358]: Listen normally on 8 ppp0 192.168.42.193 UDP 123


    Kernel Messages

    2013:03:18-09:42:43 gdl-firewall kernel: [86925.876394] martian source 172.16.17.98 from 172.16.16.1, on dev eth1
    2013:03:18-09:42:43 gdl-firewall kernel: [86925.876398] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:42:53 gdl-firewall kernel: [86935.668116] martian source 172.16.17.99 from 172.16.16.1, on dev eth1
    2013:03:18-09:42:53 gdl-firewall kernel: [86935.668120] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:42:54 gdl-firewall kernel: [86937.560078] martian source 172.16.17.100 from 172.16.16.1, on dev eth1
    2013:03:18-09:42:54 gdl-firewall kernel: [86937.560082] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:48:55 gdl-firewall kernel: [    8.090168] NET: Registered protocol family 10
    2013:03:18-09:48:55 gdl-firewall kernel: [    8.092690] ip_tables: (C) 2000-2006 Netfilter Core Team
    2013:03:18-09:48:55 gdl-firewall kernel: [    8.093533] ip6_tables: (C) 2000-2006 Netfilter Core Team
    2013:03:18-09:48:55 gdl-firewall kernel: [    8.197182] nf_conntrack version 0.5.0 (191739 buckets, 1533912 max)
    2013:03:18-09:48:55 gdl-firewall kernel: [    8.209082] Netfilter messages via NETLINK v0.30.
    2013:03:18-09:48:55 gdl-firewall kernel: [    8.209306] ctnetlink v0.93: registering with nfnetlink.
    2013:03:18-09:49:01 gdl-firewall kernel: [   14.448147] ip_set: protocol 6
    2013:03:18-09:49:02 gdl-firewall kernel: [   14.996079] Bridge firewalling registered
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.005981] Ebtables v2.0 registered
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.078757] r8169 0000:03:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168f-1.fw (-2)
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.090746] r8169 0000:03:00.0: eth0: link down
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.090755] r8169 0000:03:00.0: eth0: link down
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.090887] ADDRCONF(NETDEV_UP): eth0: link is not ready
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.107959] NET: Registered protocol family 17
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.177984] ADDRCONF(NETDEV_UP): eth2: link is not ready
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.249900] ADDRCONF(NETDEV_UP): eth1: link is not ready
    2013:03:18-09:49:02 gdl-firewall kernel: [   15.321727] ADDRCONF(NETDEV_UP): eth4: link is not ready
    2013:03:18-09:49:03 gdl-firewall kernel: [   16.748261] igb: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
    2013:03:18-09:49:03 gdl-firewall kernel: [   16.748376] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
    2013:03:18-09:49:04 gdl-firewall kernel: [   16.928082] igb: eth4 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
    2013:03:18-09:49:04 gdl-firewall kernel: [   16.928189] ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready
    2013:03:18-09:49:04 gdl-firewall kernel: [   17.747291] igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
    2013:03:18-09:49:04 gdl-firewall kernel: [   17.747461] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
    2013:03:18-09:49:05 gdl-firewall kernel: [   18.629477] r8169 0000:03:00.0: eth0: link up
    2013:03:18-09:49:05 gdl-firewall kernel: [   18.629551] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    2013:03:18-09:49:06 gdl-firewall kernel: [   19.433071] Astaro IP Scheduler 1.1 - Loaded
    2013:03:18-09:49:06 gdl-firewall kernel: [   19.433215] [ip scheduler] Registered scheduler multipath with 65 kb
    2013:03:18-09:49:06 gdl-firewall kernel: [   19.433217] Astaro MultiPath 1.1 - Loaded :: hash size 8192, persistence 3600 seconds
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.276522] martian source 172.16.16.106 from 192.168.42.129, on dev eth1
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.276524] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.528273] martian source 172.16.16.141 from 192.168.42.129, on dev eth1
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.528275] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.624190] martian source 172.16.16.10 from 192.168.42.129, on dev eth1
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.624192] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.628185] martian source 172.16.16.109 from 192.168.42.129, on dev eth1
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.628196] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.668181] martian source 172.16.16.138 from 192.168.42.129, on dev eth1
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.668184] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.676180] martian source 172.16.16.2 from 172.16.16.1, on dev eth1
    2013:03:18-09:49:07 gdl-firewall kernel: [   20.676182] ll header: ff:ff:ff:ff:ff:ff:08:60:6e:69:2f:b2:08:06
    2013:03:18-09:49:09 gdl-firewall kernel: [   21.924776] NET: Registered protocol family 15
    2013:03:18-09:49:09 gdl-firewall kernel: [   21.925870] Initializing XFRM netlink socket
    2013:03:18-09:49:09 gdl-firewall kernel: [   21.962658] padlock_sha: VIA PadLock Hash Engine not detected.
    2013:03:18-09:49:09 gdl-firewall modprobe: FATAL: Error inserting padlock_sha (/lib/modules/3.3.8-74.g487ae8c-smp/kernel/drivers/crypto/padlock-sha.ko): No such device
    2013:03:18-09:49:09 gdl-firewall kernel: [   22.021148] padlock_sha: VIA PadLock Hash Engine not detected.
    2013:03:18-09:49:09 gdl-firewall modprobe: FATAL: Error inserting padlock_sha (/lib/modules/3.3.8-74.g487ae8c-smp/kernel/drivers/crypto/padlock-sha.ko): No such device
  • 0
    2013:03:18-09:49:02 gdl-firewall kernel: [ 15.078757] r8169 0000:03:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168f-1.fw (-2)
    use intel nics.  secondly Linux does support dynamic memory.  I don't know if this is a limitation fo the yhper-v tools for Linux or what but dynamic memory works fine for Linux under vmware..[:)]  I run hyper- 2008 i'm not sure that 2012 has been shaken out yet..i consider the win8 codebase to be beta..plus with windows 9 projected for the end of next year it's going to be even more fun.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0
    ok, the realtek adapter is integrated. I've removed it from the config. Using all intel NICs now. I'm pretty sure it will reboot. But that is a good suggestion.
  • 0
    no reboots in 36 minutes. Here's what I did:
    Per Will's suggestion, I removed the realtek adapter from the mix
    Disabled Uplink Monitoring

    At this point I don't know what helped but I'm going to go with "disabling uplink monitoring" for now because the same behavior was occuring in the Hyper-V VM with all-intel NICs.
  • 0 in reply to William Warren
    Rebooted again after 1 hour and 46 minutes.
Cookie Information Banner