Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"auto eth0" vs. "allow-hotplug eth0" #145

Open
henfri opened this Issue Jul 22, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@henfri
Copy link

henfri commented Jul 22, 2018

Hello,

when applying changes I made in the Web-Interface, I get an error message:

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; systemctl start 'networking' 2>&1' with exit code '1': Job for networking.service failed because a timeout was exceeded. See "systemctl status networking.service" and "journalctl -xe" for details.

The reason:

Jul 22 22:17:25 homeserver systemd[1]: networking.service: Unit entered failed state.
Jul 22 22:17:25 homeserver systemd[1]: networking.service: Failed with result 'timeout'.

Searching for this problem, I find the recommendation to use
"allow-hotplug eth0" and not "auto eth0"

In my /etc/network/interfaces I have both.
This is automatically generated by OMV.

With this configuration, I also get the timeout when restarting networking maually (rather than it being triggered by the "apply changes" in the webinterface).
When commenting out "auto eth0", I can restart networking without problems.

I think that "auto eth0" hould be removed.

Edit: I use a static IP. Often, the problem is attirbuted to a dhcp timeout. This should not be the problem here.

Regards,
Hendrik

source-directory interfaces.d

The loopback network interface

auto lo
iface lo inet loopback
iface lo inet6 loopback

eth0 network interface

auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.177.3
gateway 192.168.177.1
netmask 255.255.255.0
dns-search fritz.box
iface eth0 inet6 dhcp
pre-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6

@votdev

This comment has been minimized.

Copy link
Collaborator

votdev commented Jul 23, 2018

According to https://manpages.debian.org/stretch/ifupdown/interfaces.5.en.html the 'auto' keyword is still allowed and used e.g. by Ubuntu.

Searching for this problem, I find the recommendation to use "allow-hotplug eth0" and not "auto eth0"

Can you point me to the URL?

@votdev

This comment has been minimized.

Copy link
Collaborator

votdev commented Jul 23, 2018

Remember to add interfaces that you want brought up at boot time to the 'auto' line.

https://wiki.debian.org/NetworkConfiguration#Setting_up_an_Ethernet_Interface

@henfri

This comment has been minimized.

Copy link
Author

henfri commented Jul 24, 2018

Hello Volker,

I am aware 'auto' is still allowed, but for me, removing it seems to help. I do not understand why, and what repercussions it can have (but I from what I found, it should be ok).
For me it is. After reboot the network is properly brought up.

Can you point me to the URL?

https://unix.stackexchange.com/questions/186162/how-to-change-timeout-in-systemctl (very bottom)
and
https://askubuntu.com/questions/837932/boo-networking-service-incredibly-slow-5minutes-ubuntu-16-10/848765#848765

I found more users with this problem:
https://unix.stackexchange.com/questions/390307/startup-debian-9-error-failed-to-start-raise-network-interfaces

Also several OMV Users:
https://forum.openmediavault.org/index.php/Thread/22157-Failed-to-start-Raise-Network-Interface-after-upgrade-from-OMV3-to-OMV4/
#116
https://pastebin.com/jTwbLdY2

Greetings,
Hendrik

@votdev

This comment has been minimized.

Copy link
Collaborator

votdev commented Jul 24, 2018

The problem is that the number of users is really low or going to zero that seem to have your problem. I do not know which side effects it can raise if we remove the 'auto' line. In the most worse case we might break ALL existing systems out there. You will surely understand that i can not do this if the problem only appears on a very very very small number of systems. Safety first.

I opened a feature issue for OMV5 which uses systemd to startup the network. Sadly this will not help you currently, but will prevent this issue on OMV5 systems in future.

@henfri

This comment has been minimized.

Copy link
Author

henfri commented Aug 5, 2018

Hello,

I understand that. Do you have a suggestion for a workaround for me for the time being?
I currently get an error everytime I try to apply changes -although I am not aware that I did change anything network related.

Greetings,
Hendrik

@votdev

This comment has been minimized.

Copy link
Collaborator

votdev commented Aug 6, 2018

The only workarounds are:

  • Manually change /etc/network/interfaces every time
  • Modify the omv-mkconf scripts to your needs. This will make problems if you install an new package, then the files will be overwritten again.
@henfri

This comment has been minimized.

Copy link
Author

henfri commented Aug 11, 2018

Hello Volker,

thanks for your reply.
Changing /etc/network/interfaces everytime does not really help, because still applying the changes fails.

Regarding /usr/sbin/omv-mkconf:
I am familiar with python, but not with the omv-python modules and with what the script is doing.

Can you explain, what you suggest to be changed?

Regards,
Hendrik

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.