I would separate the tftp use cases then: *) Binding to an ip address. This would raise the question, when should tftp daemon be started and how. The necessary hook would be: Event "TFT_IP is available" -> start tftp daemon. This is as far as I know not part of init systems and the Tftp package is missing the hooks (if-up.d and/or whatever equivalent in NM). Otherwise how would the init system or network manager know when the specific ip that tftp needs is available - what if this cable is not plugged, how long should it wait before all interfaces are available (and possibly configured by DHCP)?.
*) Listening on any network. this should`nt be affected by any service like NM and whatever interfaces are available or configured. This should be the default, and so far the default configuration tries to archive that and fails (for whatever reason). This to me is a bug in tftp or the configuration, both related to this package. Id also appreciate if you explain the difference between 0.0.0.0:69 and :69 as address option, and what 0.0.0.0 means for IPv6 - a link to the documentation would suffice. Can you setup a VM with a fresh Jessie GNOME 3 installation, I dont know about the setup you use but as I said I want some easy steps that work on plain systems most people are familiar with. Kind Regards, Norbert 2015-05-22 13:35 GMT+02:00 Ron <r...@debian.org>: > On Fri, May 22, 2015 at 11:15:00AM +0200, Norbert Lange wrote: >> Hi Ron >> >> 2015-05-22 2:08 GMT+02:00 Ron <r...@debian.org>: >> > >> > From a sample space of two, Networkmanager appears to be emerging as >> > the common culprit ... >> >> Quite possibly its Networkmanager fault, but its strange that only >> tftp-hpa is affected. > > It's not only tftp-hpa that would get burned by this. Any network > using service that needs to resolve or use an address would fail in > exactly the same way if started before your network is up. And lots > of them do. This isn't a new problem, you're just lucky that it's > the only thing that you are seeing it on. > >> I also use fixed ip/dns via the gnome gui (what exactly the gui >> affects and how NM is hooked into it is unclear to me). > > Which is probably a big part of the problem here. The getaddrinfo(3) > call is failing because your network is not yet configured, and anything > which calls that (which means just about everything with IPv6 support > that is even half sane) would fail in the same way that this does if > started at the same point in your boot sequence. As would anything > that tries to bind to a specific address before the interface it is > assigned to is up. > >> At home I have two systems where I killed NM and used the interfaces >> config file, exactly because this thing caused me alot trouble already > > You could do a lot worse than do the same on this system too then :) > >> And I am far from the only one with the problem, I found this report >> from another sites. >> And Ubuntu has this issue too: >> https://bugs.launchpad.net/ubuntu/+source/tftp-hpa/+bug/972845 > > "Upstart in broken boot dependency shocker. film@11" > > The fix suggested there is more correct though, since it tried to > address the broken boot dependency, not hack around it by exploiting > an implementation detail of the tftpd configuration which will only > "work" for some users. > >> I can did out more references from my browser cache when I`m back at >> work next week > > "me too" references aren't really helpful here. The problem isn't a > mystery and the solution to it isn't a popularity contest. Unless > the broken boot dependency is fixed in NM, this problem will still > exist. Changing the default config so that it doesn't effect *you* > as a side-effect won't make it go away for other people who need a > different config. > > > I've left this bug open here because the question of whether the old > default (which has been what it is for much longer than I've been > maintaining this package) should be changed is an open one worth some > further thought -- but what we change it to if we do doesn't really > depend on "will this be broken with NM" because until NM is fixed it > will *always* be broken with some/most valid tftpd configurations > (and it won't be the only thing that is). The answer to that needs > to depend purely on "what is sane/safe for a default tftpd install". > > We can note there are workarounds with varying degrees of ugly that > may work for some people in some circumstances, but we really can't > "fix" NM from here - that needs to happen in NM itself. > > Cheers, > Ron > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
