christgau / wsdd

A Web Service Discovery host daemon.
MIT License
808 stars 97 forks source link

Error during shutdown #201

Closed kroese closed 3 months ago

kroese commented 3 months ago

Yet another error during shutdown using the latest master code:

Traceback (most recent call last):
  File "/usr/sbin/wsdd", line 1985, in main
    aio_loop.run_forever()                                           File "/usr/lib/python3.11/asyncio/base_events.py", line 608, in run_forever
    self._run_once()
  File "/usr/lib/python3.11/asyncio/base_events.py", line 1936, in _run_once
    handle._run()
  File "/usr/lib/python3.11/asyncio/events.py", line 84, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/sbin/wsdd", line 1749, in sigterm_handler
    sys.exit(0)
SystemExit: 0
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/sbin/wsdd", line 2001, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/sbin/wsdd", line 1991, in main
    nm.cleanup()
  File "/usr/sbin/wsdd", line 1568, in cleanup
    super().cleanup()
  File "/usr/sbin/wsdd", line 1397, in cleanup
    self.teardown()
  File "/usr/sbin/wsdd", line 1381, in teardown
    self.aio_loop.run_until_complete(asyncio.gather(*self.teardown_tasks))
  File "/usr/lib/python3.11/asyncio/base_events.py", line 633, in run_until_complete
    future = tasks.ensure_future(future, loop=self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/tasks.py", line 659, in ensure_future
    return _ensure_future(coro_or_future, loop=loop)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/tasks.py", line 665, in _ensure_future
    raise ValueError('The future belongs to a different loop than 'ValueError: The future belongs to a different loop than the one specified as the loop argument
christgau commented 3 months ago

Any hints to reproduce? Same as in #196?

kroese commented 3 months ago

Yes same pkill -f wsdd command.

The hint to reproduce may be that the network interface specified by --interface most likely did not exist / was not active.

But wsdd should refuse to start or otherwise exit gracefully in that situation, instead of crashing.

christgau commented 3 months ago

But wsdd should refuse to start [if interface does not exists or is not active]

No, it should not. Wsdd is able to handle to handle interface addition/removal and address changes (e.g. due to changed connections/network).

or otherwise exit gracefully in that situation

Yes. I agree.