Oh, there was a file like that?.. ^_^
Ooohkay, this has revealed something interesting.
In /etc/default/networking, it says:
# Which interface to wait for.
# If none given, wait for all auto interfaces, or if there are none,
# wait for at least one hotplug interface.
#WAIT_ONLINE_IFACE=
I have two interfaces: "auto lo" and "allow-hotplug eth0". So, in my
case, by default it waits for lo, and then the network is assumed to be
up. (Apparently "if there are none" includes lo, which makes little sense.)
Changing this to "auto eth0" has fixed the smbd problem!
I remember having read somewhere that "allow-hotplug implies auto", so I
usually change eth0 to allow-hotplug without expecting any consequences
of this kind. Turns out that with "allow-hotplug", the system does not
wait for the interface to come up at boot, that's why samba starts
without it.
Changing it back to "auto" fixes this problem, but introduces another
one. For some reason, DHCP address acquisition takes 5 to 8 seconds, so
the downside is adding 8 seconds to the system boot time.
So, to sum it up:
- If you are running a samba server, then either run it on an "auto"
interface, or restart it after configuring a hotplug interface by adding
this line in the interface's definition:
up /bin/systemctl restart smbd.service nmbd.service || true
This actually makes sense. If you reconfigure a hotplug interface, you'd
probably want to restart everything that is supposed to listen on it.
(Come to think about it, why doesn't sshd have this problem?.. Maybe
because it listens on 0.0.0.0 ?.. Specifying 0.0.0.0/0 as an interface
to listen on in smb.conf does not help.)
- Still, it would be nice to fix samba so that it does not try to bind
to nonexistent interfaces (even though it is not even asked to), and
does not output a high-level uninformative error message when it fails
to do that. This would allow us to not worry about IPv6 and not see the
strange red error message at the same time. It could probe those
interfaces if it wants to bind to all of them, but a negative probing
result is expected, and is not a high-level error.
On 15/07/19 16:36, Mathieu Parent wrote:
> Le dim. 14 juil. 2019 à 14:51, Dark Penguin <darkpeng...@yandex.com> a écrit :
>>
>> This issue is still present in Buster.
>>
>> Changing the interface name to its IP address in smb.conf does not make
>> sense because we're talking about a situation when your IP address is
>> managed by DHCP.
>>
>> Tweaking the systemd service files does not help according to the OP,
>> and even if it did, this is not a solution - network-online.target
>> apparently still does not work.
>>
>> Mathieu, is there a bug report with more details about the
>> network-online.target problem? It looks pretty serious since it can
>> potentially break all network-based daemons, and is still not fixed in
>> Buster.
>
> Have you considered tuning /etc/default/networking ?
>
> For example:
> WAIT_ONLINE_METHOD="ifup"
> WAIT_ONLINE_IFACE="enp2s0"
> WAIT_ONLINE_ADDRESS=""
> WAIT_ONLINE_TIMEOUT=300
>
> or:
> WAIT_ONLINE_METHOD="ping"
> WAIT_ONLINE_IFACE=""
> WAIT_ONLINE_ADDRESS="128.31.0.62"
> WAIT_ONLINE_TIMEOUT=300
>
> See also /lib/ifupdown/wait-online.sh
>
> What is the content of /etc/network/interfaces?
>
> Regards
>
--
darkpenguin
