Le 08/02/2022 à 01:45, aitor a écrit :
Hi Didier,
On 7/2/22 19:21, Didier Kryn wrote:
If you
remove the "allow-hotplug" and "auto" stanzas, ifup -a will just do
nothing, hence no wait. Therefore the solution is to install ifplugd or
netplug, configure it, and eliminate the "allow-hotplug" stanzas from
/etc/network/interfaces.
I've found a workaround replacing in the init script:
if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
then
log_action_end_msg $?
else
log_action_end_msg $?
fi
with this:
if [ $(runlevel) != "unknown" ] || ! [ -z $(grep '^id:1:initdefault:$'
/etc/inittab) ]; then
if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
then
log_action_end_msg $?
else
log_action_end_msg $?
fi
fi
which means: "skip these lines if the boot process still has not switched to
the default runlevel,
unless it is single user". The following script located in /etc/boot.d:
#!/bin/sh -e
#
# networking-restart
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
if test -x /etc/init.d/networking ; then
service networking restart
fi
will restart the service and from this moment, both "auto <device>" and "allow-hotplug
<device>" will take effect.
This way, the delay will occur only in the case of a single user default
runlevel, which is often not the case.
IIUC this means that network startup is deferred. Does it mean
starting ntp, ssh and/or web services before the network is available?
Doesn't this method defeat the whole purpose of the dependencies
inserted as comments in the headers of the RC scripts? I ask this
because I'm not sure of my understanding of the whole mechanism.
Wouldn't it be cleaner to change the priorities?
Clearly there is a wrong assignment of priorities in the startup:
there is no reason that the login prompt and all the applications which
do not depend on the network have to wait until the network startup
times out. AFAIU your method is a workaround for this misconfiguration.
But the timeout is still there before you can use the network, while in
most cases, it should not. And, if you haven't a server like ifupdown or
netplug, you're going to need to restart networking everytime you
plug/unplug your Ethernet cable.
The ifupdown API, driven by the configuration of
/etc/network/interfaces is well suited for static network configuration;
it offers a lot of possibilities to the admin, eg bonding. The addition
of the stanza "inet dhcp" has made it usable with dynamic network
configuration, and the addition of the stanza "allow-hotplug" in
replacement of "auto" has made it usable with hotplug network interfaces
such as USB-Ethernet or USB-WIFI adapters.
But this does not respond to the cases where one or more
interfaces are not *always* connected, in particular the case of laptops
which have one single connection to the network, *alternatively* through
Wifi and through Ethernet. In this case, the connection is done through
Ethernet when the Ethernet cable is connected and through Wifi otherwise
and it is a nonsense to try to bring eth0 up when the Ethernet cable is
not plugged in. Instead, eth0 must be brought respectively up and down
when the cable is connected and disconnected, and, simultaneously wlan0
must be brought down and up.
I don't know any stanza of the interfaces file which might achieve
that because there is no feature such as the detection of the Ethernet
carrier in ifupdown - ifupdown is not a server. This functionality can
be provided by ifplugd, and AFAIK by netplug. These two servers detect
changes in the presence of the Ethernet carrier and make use of the
ifupdown API to bring the interfaces up and down. In this situation,
stanzas like "auto" and "allow-hotplug" are nothing but nuisances.
It would be very nice if the installer could provide a dialog to
configure this, but it does not look like an easy job. Maybe the user
could be directed to some documentation.
-- Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
