iputil: finding IP addresses fails on kfreebsd #1918

New Issue

tahoe-lafs · 2013-02-11T22:02:03Z

davidsarah commented

2013-02-11 22:02:03 +00:00

From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700239:

tahoe start fails on kfreebsd:

NevowSite starting on 3456
Starting factory <nevow.appserver.NevowSite instance at 0x1a62fc8>
My pid: 29925
DatagramProtocol starting on 55322
Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x1a73248>
Unhandled Error
#011Traceback (most recent call last):
#011  File "/usr/lib/python2.7/threading.py", line 525, in __bootstrap
#011    self.__bootstrap_inner()
#011  File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
#011    self.run()
#011  File "/usr/lib/python2.7/threading.py", line 505, in run
#011    self.__target(*self.__args, **self.__kwargs)
<exception caught here> ---
#011  File "/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py", line 207, in _worker
#011    result = context.call(ctx, function, *args, **kwargs)
#011  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext
#011    return self.currentContext().callWithContext(ctx, func, *args, **kw)
#011  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext
#011    return func(*args,**kw)
#011  File "/usr/lib/python2.7/dist-packages/allmydata/util/iputil.py", line 214, in _synchronously_find_addresses_via_config
#011    raise UnsupportedPlatformError(sys.platform)
#011allmydata.util.iputil.UnsupportedPlatformError: gnukfreebsd8
Node._startService failed, aborting
[Failure instance: Traceback: <class 'allmydata.util.iputil.UnsupportedPlatformError'>: gnukfreebsd8
/usr/lib/python2.7/threading.py:525:__bootstrap
/usr/lib/python2.7/threading.py:552:__bootstrap_inner
/usr/lib/python2.7/threading.py:505:run
<exception caught here> ---
/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py:207:_worker
/usr/lib/python2.7/dist-packages/twisted/python/context.py:118:callWithContext
/usr/lib/python2.7/dist-packages/twisted/python/context.py:81:callWithContext
/usr/lib/python2.7/dist-packages/allmydata/util/iputil.py:214:_synchronously_find_addresses_via_config
]
calling os.abort()
calling os.abort()

The following patch fixes the issue:

--- tahoe-lafs-1.9.2.orig/src/allmydata/util/iputil.py
+++ tahoe-lafs-1.9.2/src/allmydata/util/iputil.py
@@ -161,6 +161,7 @@
     "netbsd4": "bsd",
     "netbsd5": "bsd",
     "netbsd6": "bsd",
+    "gnukfreebsd8": "bsd",
     "sunos5": "sunos",
     "cygwin": "cygwin",
     }

From <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700239>: `tahoe start` fails on kfreebsd: ``` NevowSite starting on 3456 Starting factory <nevow.appserver.NevowSite instance at 0x1a62fc8> My pid: 29925 DatagramProtocol starting on 55322 Starting protocol <twisted.internet.protocol.DatagramProtocol instance at 0x1a73248> Unhandled Error #011Traceback (most recent call last): #011 File "/usr/lib/python2.7/threading.py", line 525, in __bootstrap #011 self.__bootstrap_inner() #011 File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner #011 self.run() #011 File "/usr/lib/python2.7/threading.py", line 505, in run #011 self.__target(*self.__args, **self.__kwargs) <exception caught here> --- #011 File "/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py", line 207, in _worker #011 result = context.call(ctx, function, *args, **kwargs) #011 File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext #011 return self.currentContext().callWithContext(ctx, func, *args, **kw) #011 File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext #011 return func(*args,**kw) #011 File "/usr/lib/python2.7/dist-packages/allmydata/util/iputil.py", line 214, in _synchronously_find_addresses_via_config #011 raise UnsupportedPlatformError(sys.platform) #011allmydata.util.iputil.UnsupportedPlatformError: gnukfreebsd8 Node._startService failed, aborting [Failure instance: Traceback: <class 'allmydata.util.iputil.UnsupportedPlatformError'>: gnukfreebsd8 /usr/lib/python2.7/threading.py:525:__bootstrap /usr/lib/python2.7/threading.py:552:__bootstrap_inner /usr/lib/python2.7/threading.py:505:run <exception caught here> --- /usr/lib/python2.7/dist-packages/twisted/python/threadpool.py:207:_worker /usr/lib/python2.7/dist-packages/twisted/python/context.py:118:callWithContext /usr/lib/python2.7/dist-packages/twisted/python/context.py:81:callWithContext /usr/lib/python2.7/dist-packages/allmydata/util/iputil.py:214:_synchronously_find_addresses_via_config ] calling os.abort() calling os.abort() ``` The following patch fixes the issue: ``` --- tahoe-lafs-1.9.2.orig/src/allmydata/util/iputil.py +++ tahoe-lafs-1.9.2/src/allmydata/util/iputil.py @@ -161,6 +161,7 @@ "netbsd4": "bsd", "netbsd5": "bsd", "netbsd6": "bsd", + "gnukfreebsd8": "bsd", "sunos5": "sunos", "cygwin": "cygwin", } ```

tahoe-lafs added the

labels 2013-02-11 22:02:03 +00:00

tahoe-lafs added this to the undecided milestone 2013-02-11 22:02:03 +00:00

davidsarah commented

2013-02-11 22:07:48 +00:00

We're far too picky about recognizing the operating system in order to decide which command to use to find IP addresses. In practice, we could just try a couple of common syntaxes that would work for all Unices that are currently supported, and be very likely to work for others. Then we'd only need to distinguish between Windows and everything else.

zooko commented

2013-02-13 19:16:02 +00:00

Replying to davidsarah:

We're far too picky about recognizing the operating system in order to decide which command to use to find IP addresses. In practice, we could just try a couple of common syntaxes that would work for all Unices that are currently supported, and be very likely to work for others. Then we'd only need to distinguish between Windows and everything else.

That sounds like a reasonable approach, davidsarah. On the other hand, it feels kind of icky to be attempting to execute programs on every computer which aren't even part of that operating system. I used to have some code to do that sort of thing in Tahoe-LAFS and Brian pushed back on it.

I guess I'm +0 on it, now.

I mean, the current situation is that Tahoe-LAFS fails to start up on a new operating system until someone adds a 1-line patch like this one. Maybe that's okay for now?

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1918#issuecomment-90954): > We're far too picky about recognizing the operating system in order to decide which command to use to find IP addresses. In practice, we could just try a couple of common syntaxes that would work for all Unices that are currently supported, and be very likely to work for others. Then we'd only need to distinguish between Windows and everything else. That sounds like a reasonable approach, davidsarah. On the other hand, it feels kind of icky to be attempting to execute programs on every computer which aren't even part of that operating system. I used to have some code to do that sort of thing in Tahoe-LAFS and Brian pushed back on it. I guess I'm +0 on it, now. I mean, the current situation is that Tahoe-LAFS fails to start up on a new operating system until someone adds a 1-line patch like this one. Maybe that's okay for now?

zooko commented

2013-05-27 17:29:12 +00:00

See #1988

gdt commented

2013-06-13 11:22:38 +00:00

I am -1 on running a list of commands that are not known to be correct, particularly at runtime. That leads to unreliable behavior, especially if someone has one of the other commands in their PATH.

This is pointing out that the configure/build process needs to have a reliable way to determine how to do various OS things, and that's something autoconf has done for years. It does require writing a feature test, but that seems to be the price of reasonably reliably figuring out what to do.

Also, just because there's a program called "ifconfig" doesn't mean it will necessarily do what you want.

I am -1 on running a list of commands that are not known to be correct, particularly at runtime. That leads to unreliable behavior, especially if someone has one of the other commands in their PATH. This is pointing out that the configure/build process needs to have a reliable way to determine how to do various OS things, and that's something autoconf has done for years. It does require writing a feature test, but that seems to be the price of reasonably reliably figuring out what to do. Also, just because there's a program called "ifconfig" doesn't mean it will necessarily do what you want.

daira commented

2013-06-14 23:50:05 +00:00

Oops, I accidentally committed the patch for this while committing the reviewed fix for #1717. Sorry :-(

daira commented

2013-06-14 23:56:20 +00:00

Replying to gdt:

This is pointing out that the configure/build process needs to have a reliable way to determine how to do various OS things, and that's something autoconf has done for years.

autoconf works by trying various things and seeing which appear to work. There's not very much difference apart from doing it at install time vs run time.

Replying to [gdt](/tahoe-lafs/trac-2024-07-25/issues/1918#issuecomment-90957): > This is pointing out that the configure/build process needs to have a reliable way to determine how to do various OS things, and that's something autoconf has done for years. autoconf works by trying various things and seeing which appear to work. There's not very much difference apart from doing it at install time vs run time.

daira commented

2013-06-14 23:57:22 +00:00

Replying to [daira]comment:7:

autoconf works by trying various things and seeing which appear to work. There's not very much difference apart from doing it at install time vs run time.

And of course, we're certainly not going to add a dependency on autoconf or anything similarly complicated.

Replying to [daira]comment:7: > autoconf works by trying various things and seeing which appear to work. There's not very much difference apart from doing it at install time vs run time. And of course, we're certainly not going to add a dependency on autoconf or anything similarly complicated.

Daira Hopwood <david-sarah@jacaranda.org> commented

2013-06-25 18:15:57 +00:00

In /tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6:

iputil.py: add tests for recent changes. refs #1381, #1988, #982, #1064, #1536, #1935, #898, #1707, #1918

Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org>

In [/tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6](/tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6): ``` iputil.py: add tests for recent changes. refs #1381, #1988, #982, #1064, #1536, #1935, #898, #1707, #1918 Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org> ```

daira commented

2013-06-27 01:50:21 +00:00

iputil on trunk no longer distinguishes between Unix variants, which fixes this bug.

tahoe-lafs added the

fixed

label 2013-06-27 01:50:21 +00:00

tahoe-lafs modified the milestone from undecided to 1.11.0

2013-06-27 01:50:21 +00:00

daira closed this issue

2013-06-27 01:50:21 +00:00

Sign in to join this conversation.