Page 1 of 3 123 LastLast
Results 1 to 10 of 21
  1. #1
    Untangler
    Join Date
    Jan 2019
    Posts
    36

    Default Slow boot and "A start job is running for Raise network interfaces"

    New user here.
    I have a fairly fast machine (Core i5), normally booting in < 30s.
    For some reason, my settings make boot very slow, with the console hanging at "A start job is running for Raise network interfaces" for 5 minutes, the duration of the timeout. After that, it's all good.

    The odd thing is that I did a fresh install, which boots fast. After restoring my settings, I get the slow boot. If I "reset to factory defaults", it boots fast again. My networking settings are very straightforward: 1WAN-DHCP, 1LAN and a VLANed LAN. Even if I remove the VLAN interface or change the LAN interface, I still have the same issue. I even tried to run the "wizard" again, and no luck, still slow.

    I googled the issue and found nothing untangle-related, but a bunch of Ubuntu links of people complaining the content of /etc/network/interfaces. Mine clearly names the enabled interfaces as "auto", so waits for them to be up, and the kernel boot trace shows both eth0 and eth1 going up before the wait.

    Code:
    Jan 31 22:16:36 untangle kernel: [    3.788991] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    Jan 31 22:16:48 untangle kernel: [   15.727673] random: crng init done
    Jan 31 22:16:48 untangle kernel: [   15.729437] random: 7 urandom warning(s) missed due to ratelimiting
    Jan 31 22:16:53 untangle kernel: [   20.818857] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
    Jan 31 22:16:53 untangle kernel: [   20.823677] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Jan 31 22:16:59 untangle kernel: [   27.101274] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
    Jan 31 22:17:00 untangle kernel: [   27.317260] 8021q: 802.1Q VLAN Support v1.8
    Jan 31 22:17:00 untangle kernel: [   27.317885] 8021q: adding VLAN 0 to HW filter on device eth0
    Jan 31 22:17:00 untangle kernel: [   27.318505] 8021q: adding VLAN 0 to HW filter on device eth1
    Jan 31 22:17:00 untangle kernel: [   27.319131] 8021q: adding VLAN 0 to HW filter on device eth2
    Jan 31 22:17:00 untangle kernel: [   27.319821] 8021q: adding VLAN 0 to HW filter on device eth3
    Jan 31 22:17:00 untangle kernel: [   27.320424] 8021q: adding VLAN 0 to HW filter on device eth4
    Jan 31 22:17:00 untangle kernel: [   27.321063] 8021q: adding VLAN 0 to HW filter on device eth5
    Jan 31 22:17:00 untangle kernel: [   27.331567] IPv6: ADDRCONF(NETDEV_UP): eth1.3: link is not ready
    Jan 31 22:17:02 untangle kernel: [   29.359800] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
    >>>>>WAIT 5 MIN <<<<<
    Jan 31 22:21:35 untangle kernel: [  302.537933] ip_set: protocol 6
    Jan 31 22:21:35 untangle kernel: [  302.569294] NET: Registered protocol family 15
    Jan 31 22:21:35 untangle kernel: [  302.608006] Initializing XFRM netlink socket
    Jan 31 22:21:35 untangle kernel: [  302.660335] NET: Registered protocol family 38
    There are mentions of IPv6 not being ready, but IPv6 seems disabled in the /etc/networking/interfaces (I am not proficient enough to know if that's correct):
    Code:
    ## Interface 1 IPv4 (AUTO)
    auto eth0
    iface eth0 inet dhcp
            untangle_interface_index 1
    
    
    ## Interface 1 IPv6 (DISABLED)
    iface eth0 inet6 manual
            untangle_interface_index 1
            pre-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6 || true
    
    
    ## Interface 2 IPv4 (STATIC)
    auto eth1
    iface eth1 inet manual
            untangle_interface_index 2
            untangle_v4_address 192.168.1.1
            untangle_v4_netmask 255.255.255.0
    
    
    ## Interface 2 IPv6 (DISABLED)
    iface eth1 inet6 manual
            untangle_interface_index 2
            pre-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6 || true
    
    
    ## Interface 101 IPv4 (STATIC)
    auto eth1.3
    iface eth1.3 inet manual
            untangle_interface_index 101
            pre-up modprobe -q 8021q || true
            untangle_v4_address 192.168.3.1
            untangle_v4_netmask 255.255.255.0
    
    
    ## Interface 101 IPv6 (DISABLED)
    iface eth1.3 inet6 manual
            untangle_interface_index 101
            pre-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6 || true
    
    
    ## This is a fake interface that launches the post-networking-restart
    ## hooks using the if-up.d scripts when IFACE=networking_post_restart_hook
    auto networking_post_restart_hook
    iface networking_post_restart_hook inet manual

  2. #2
    Master Untangler
    Join Date
    May 2008
    Posts
    897

    Default

    I see the same thing happening.
    https://forums.untangle.com/networki...same-time.html
    Support blames it on my network bla bla etc. I think the real problem is that systemd needs a tune up.
    https://www.freedesktop.org/wiki/Sof...NetworkTarget/

    In my case openvpn is starting before the network is up. Not sure about yours. Couple of things to try on the cli will show errors.
    Code:
    systemd-analyze critical-chain
    Code:
    systemd-analyze blame
    It is over my head to fix it but hopefully somebody can.
    LaurentR likes this.

  3. #3
    Untangler
    Join Date
    Jan 2019
    Posts
    36

    Default

    Bingo. I had seen OpenVPN go up and down on the console boot screen while booting but hadn't thought of it more than that.

    I tried disabling the OpenVPN server and voila, kern.log reports booting in 17s, no trouble. If I enable the OpenVPN server, back to the slow boot.
    Looks like a race or indeed systemd config issue. I am out of my depth as well.
    donhwyo likes this.

  4. #4
    Untangler
    Join Date
    Jan 2019
    Posts
    36

    Default

    While I am still working on root-causing this, the best, least-intrusive work-around I found is the last answer to this related question.
    Last edited by LaurentR; 02-01-2019 at 10:54 PM.

  5. #5
    Untangler
    Join Date
    Jan 2019
    Posts
    36

    Default

    Quote Originally Posted by donhwyo View Post
    I see the same thing happening.
    Out of curiosity, what type of hw do you have? Mine is a core i5 7200U and 6x Intel 82583V.

  6. #6
    Untangler
    Join Date
    Apr 2010
    Posts
    98

    Default

    I can also vouch for that. This behavior started with v14.1. Before that reboots were very quick. Now UT takes a lot of time to boot up.

  7. #7
    Master Untangler
    Join Date
    May 2008
    Posts
    897

    Default

    Mine is on a proxmox server. I have tried all versions of virtual nics. I installed from the iso a few times and the ova image.

    I recommend opening a support ticket. You can do that even for the free version.

  8. #8
    Untangler
    Join Date
    Jan 2019
    Posts
    36

    Default

    Quote Originally Posted by MechanicalThinker View Post
    I can also vouch for that. This behavior started with v14.1. Before that reboots were very quick. Now UT takes a lot of time to boot up.
    Thanks! Do you have more data on:
    * Hardware used
    * Whether you have OpenVPN server enabled
    * Whether you can check in /var/log/kern.log to see if you indeed have the 300sec timeout during boot

  9. #9
    Untangler
    Join Date
    Apr 2010
    Posts
    98

    Default

    Quote Originally Posted by LaurentR View Post
    Thanks! Do you have more data on:
    * Hardware used
    * Whether you have OpenVPN server enabled
    * Whether you can check in /var/log/kern.log to see if you indeed have the 300sec timeout during boot
    Running on custom hardware. OpenVPN enabled. Too lazy to check logs currently.

    As the boot is stuck waiting at network interfaces coming up, my take is that this is due to having several physical interfaces that are not connected and linux is waiting for them to come up/get ip from dhcp. I have seen this on other Debian based Linux distros too.

  10. #10
    Master Untangler
    Join Date
    May 2008
    Posts
    897

    Default

    Quote Originally Posted by MechanicalThinker View Post
    , my take is that this is due to having several physical interfaces that are not connected and linux is waiting for them to come up/get ip from dhcp.
    I think if systemd was implemented better networking would work as it used to. The five minute delay should be cleared as what ever caused it resolves itself. I don't think that happens. After the time out all seems fine so it must have resolved just not reporting to systemd. It may also be a problem in the way interfaces are brought up?

    Seems according to these links systemd is not setup optimally.
    https://www.freedesktop.org/wiki/Sof...NetworkTarget/
    https://unix.stackexchange.com/quest...or-the-networkI hacked that into a vm and after about a minute (instead of 5) boot continued. That is why I think something is not clearing the delay. The 1 minute delay is either still in the script bringing up the interfaces. Or maybe I missed something in applying the hack.
    Code:
    [root @ homeuntangle] ~ # systemd-analyze blame
             42.706s untangle-vm.service
             11.215s networking.service   **** without hack would be 5 minutes
              6.769s postgresql@9.6-main.service
              2.462s suricata.service
              2.358s dev-vda1.device
              1.118s apache2.service
              1.028s untangle-hardware-config.service
               989ms softflowd.service
               972ms exim4.service
               782ms ntp.service
               686ms nvi.service
               674ms ddclient.service
               563ms systemd-udevd.service
               507ms ebtables.service
               426ms systemd-tmpfiles-setup.service
               402ms xinetd.service
               370ms keepalived.service
               368ms dnsmasq.service
               335ms systemd-tmpfiles-setup-dev.service
               326ms plymouth-start.service
               258ms systemd-logind.service
               248ms apt-daily.service
               245ms lxc-net.service
               243ms hostapd.service
               241ms apt-daily-upgrade.service
               230ms ssh.service
               202ms systemd-udev-trigger.service
               184ms systemd-fsck-root.service
               150ms user@10000.service
               132ms lxc.service
               107ms stunnel4.service
    You can also get around the delay like this.
    I changed the timeout from 5min to 15sec in
    /etc/systemd/system/network-online.target.wants/networking.service
    It goes on to work fine.
    Kind of confirms the above too.

    Since most don't reboot often I think the problem is going undetected. Unless you watch the boot process you wont notice it.

    Don't forget to file a support ticket if you haven't yet.

    Thanks

    PS Don't forget if you apply the hacks above you will lose your support! Do it in a vm or spare hard drive.
    Last edited by donhwyo; 02-03-2019 at 11:44 AM. Reason: Added aditional link

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2