Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #62737 > unrolled thread

Bug#860264: ifquery behaviour

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#860264: ifquery behaviour Vincent McIntyre <vincent.mcintyre@csiro.au> - 2018-12-15 10:00 +0100
    Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown Antoine Beaupre <anarcat@debian.org> - 2019-01-30 03:40 +0100
      Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown Antoine Beaupré <anarcat@debian.org> - 2019-01-30 04:10 +0100

#62737 — Bug#860264: ifquery behaviour

# grep auto /etc/network/interfaces
auto lo
# grep hotplug /etc/network/interfaces
allow-hotplug enp0s31f6

# ifquery --read-environment --list --exclude=lo  # as in unit file
#
# ifquery --read-environment --list --exclude=lo --allow auto
#
# ifquery --read-environment --list --exclude=lo --allow hotplug
enp0s31f6

But if I convert enp0s31f6 to auto
# grep /etc/network/interfaces
auto lo
auto enp0s31f6

# ifquery --read-environment --list --exclude=lo --allow hotplug
#  (as expected)
# ifquery --read-environment --list --exclude=lo --allow auto
enp0s31f6
# ifquery --read-environment --list --exclude=lo
enp0s31f6

So with the interface set to auto, the ifquery in the unit file
picks it up. With the interface set to allow-hotplug, it doesn't.

I think this is part of the puzzle, but there is more to it.
I think that there are some issues arising from how ifupdown
and systemd (fail to) communicate about when exactly the network
interface is fully up and working (particularly in the dhcp case).
If you look at the work that has gone into ifupdown since the
stretch release, it seems like there are some issues there that
have now, hopefully, been resolved.

Kind regards
Vince

[toc] | [next] | [standalone]

#63195 — Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown

[Multipart message — attachments visible in raw view] — view raw

I still need to reproduce this in a normal Debian install, but I have
had similar problems than this with sshfs, in a OSMC (Debian derivative)
install:

https://discourse.osmc.tv/t/how-to-sshfs-tutorial/77852/11

There's an easy workaround for sshfs: the `delay_connect` option delays
network operations until the mountpoint is accessed. It would still be
nice to fix this for sshfs as it will bite novice users pretty badly.

All this leads me to believe this is a bug in systemd, and not NFS. I
wonder if we should reassign this bug to the systemd (or ifupdown?)
package to get more visibility into it (and keep nfs/sshfs as affected).

We'd need an easier way to reproduce this however. Has anyone worked on
getting some virtual machine images up to try and orchestrate a
reproducer for this? That would be ideal but a step-by-step set of
minimal instructions starting from a clean install would be an
acceptable compromise.

Once we have that, we can try to reproduce in buster as well and figure
out if the bug is actually fixed there or not.

Thanks for the bug report!

A.

-- 
Never be deceived that the rich will allow you to vote away their wealth.
                        - Lucy Parsons

[toc] | [prev] | [next] | [standalone]

#63196 — Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown

On 2019-01-29 21:32:24, Gabriel Filion wrote:
> Hi there,
>
> On 2019-01-29 9:26 p.m., Antoine Beaupre wrote:
>> We'd need an easier way to reproduce this however. Has anyone worked on
>> getting some virtual machine images up to try and orchestrate a
>> reproducer for this? That would be ideal but a step-by-step set of
>> minimal instructions starting from a clean install would be an
>> acceptable compromise.
>
> The bug is hard to reproduce since it's a run condition that might not
> happen sometimes.

It's pretty reliable on the vero 4k+, for what that's worth. But it's a
slower ARM machine...

> The simplest way to reproduce is to have an nfs (or maybe sshfs if it's
> possible to reproduce with this) server, then on a buster machine to add
> the nfs mount as a line to the fstab file, then reboot.
>
> when the mount does not work, it is quite apparent: the boot process
> hangs for some time before NFS decides to timeout.

understood. do you think it would be possible to setup a vagrant box
with this somehow?

a

-- 
From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
                        - Winston Smith, 1984

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web