Bug#816076: wicd-daemon: upgrade reconfigures static ethernet interface, and kills ssh sessions.
On 7 March 2016 at 04:16, Axel Beckert <abe@debian.org> wrote:
> Hi Andrew,
>
> Andrew Vaughan wrote:
>> My home server is a headless box, administered from a vnc session tunnelled
>> over ssh. It has no wifi adaptor, just a single ethernet port that is
>> statically configured via /etc/network/interfaces.
>
> So why are you using wicd at all? I don't see why you need wicd in
> such a setup.
>
Wicd was automatically installed because lxde recommends wicd |
network-manager-gnome.
Yes, I could just remove wicd, but that would be working around what I
view as buggy behaviour in wicd-daemon. If relatively common
meta-packages like lxde are going to pull in services like wicd-daemon
via recommends, then those services must behave sanely if the user
never touches their config.
Network-manager-gnome is also installed because gnome-core recommends
it. I wonder whether we have races between them?
>> This behaviour is wrong on so many levels.
>>
>> 1. A package upgrade should never bring down an existing in-use interface
>> without asking the user/admin first.
>
> I agree here mostly. It's though only a real issue if the interface
> doesn't come up again with the same IP afterwards.
>
Even if it comes up with the same ip address it is a potential data loss bug.
eg a ssh user has unsaved work in some console application, when the
connection is lost. There is no easy way to reconnect to the console
application. This may result in data loss.
>> Wicd-daemon should not assume that just because it is installed it
>> owns all the network interfaces.
>
> I disagree here. In Debian, it's common that NetworkManager and
> similar tools manage those interfaces from /etc/network/interfaces
> which are not listed (or maybe also those which are on "auto").
Nowhere in the package description does wicd say that it will attempt
to automatically maintain an active internet connection without any
prior user/admin interaction/config.
In principle, I don't have a problem with it trying to automatically
configure interfaces that have no existing config. But if I were to
run a virtualisation script that adds a virtual interface, then starts
a virtual machine, is wicd going to see the new interface and try to
configure that, and hence race the the startup of the virtual machine?
If I plugin a usb wireless adaptor is it going to blindly attempt to
connect to any available wifi network, even if no wifi network has
ever been configured on this device? If the user were to attempt to
use network-manager gnome to change an existing wifi connection, are
the 2 going to fight over which one gets to configure the
wifi-adapter?
But regardless, if it hasn't been explicitly given permission to
change network configs, then it should respect the existing config of
any interfaces that are up before it starts, or that the user or admin
configures using other tools, including whilst it is running.
Certainly installing/reinstalling/upgrading wicd-daemon shouldn't
touch any network configuration that was made with other tools,
without the admin or user having done something to give wicd
permission to manage network config.
On a related note (the following typed manually from memory, so only
approximate)
ifdown eth0
do something for 30 sec (like edit /etc/network/interfaces ....)
ifup eth0
error: file in use. can't bring up eth0
ifdown eth0
error: eth0 not up
Not sure whether that was network-manager or wicd that brought eth0
up, but it could be an head-scratching time for an admin who had never
noticed that they were installed. And it should have better
integration with ifup/down, so that both tools are on the same page as
to what the interface status is and preferably what the interface
status is supposed to be.
>
>> I have been through basically the same problems with network-manager in the
>> past. Issues like this are why so many people are hostile to that package.
>
> Indeed. That's why I'm using wicd, too. It was though worse with
> NetworkManager back then since usually, the network interface stayed
> down afterwards. That got fixed in the meanwhile, though, IIRC.
>
I remember un-installing network-manager a few times, only for
dependencies to try to pull it back in.
Andrew
Reply to: