Error: Task was destroyed but it is pending!

[kroese]

When trying to shutdown wsdd gracefully, by using:

pkill -f wsdd

which sends the SIGTERM signal, I get:

asyncio ERROR(pid 588): Task was destroyed but it is pending!
task: <Task pending name='Task-2' coro=<WSDUDPMessageHandler.schedule_datagram() running at /usr/sbin/wsdd:477> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[gather.<locals>._done_callback() at /usr/lib/python3.11/asyncio/tasks.py:764]>

Shouldnt wsdd be able to shutdown itself cleanly in this case without printing any errors?

[christgau]

Shouldnt wsdd be able to shutdown itself cleanly in this case without printing any errors?

Yes. Do you see received termination/interrupt signal, tearing down wsdd's output before the error message is printed?

[kroese]

No?

[christgau]

No?

Sorry, you have to provide -v to the command line arguments.

Besides that: Which OS are you using?

[kroese]

I am using it with this Docker container ( https://github.com/dockur/windows ), so the OS is Debian Trixie.

Because wsdd has no daemonize command line argument, I send it to the background in shell using & (see https://github.com/dockur/windows/blob/master/src/samba.sh). And then I trap the SIGTERM signal and use pkill ( https://github.com/dockur/windows/blob/master/src/power.sh ) to close it.

It may be possible that it receives a double SIGTERM signal, because Bash automaticly forwards the signal to children even though I trap it, and this second signal causes the unclean shutdown? I will add this -v flag and see if that provides some more info to what is happening.

[kroese]

I could not reproduce it every time, but I managed to do it:

2024-02-11 10:28:54,881:wsdd INFO(pid 177): received termination/interrupt signal, tearing down
2024-02-11 10:28:54,881:wsdd INFO(pid 177): shutting down gracefully...                                                               
2024-02-11 10:28:54,881:wsdd INFO(pid 177): scheduling Bye message via dockerbridge to ('239.255.255.250', 3702)
❯ ERROR: Forcefully terminating Windows, reason: 130...
qemu-system-x86_64: terminating on signal 15 from pid 7 (bash)
2024-02-11 10:28:55,892:wsdd INFO(pid 177): received termination/interrupt signal, tearing down
2024-02-11 10:28:55,905:asyncio ERROR(pid 177): Task was destroyed but it is pending!
task: <Task pending name='Task-2' coro=<WSDUDPMessageHandler.schedule_datagram() running at /usr/sbin/wsdd:477> wait_for=<Future pending cb=[Task.task_wakeup()]> cb=[gather.<locals>._done_callback() at /usr/lib/python3.11/asyncio/tasks.py:764]>

So the problem only seems to occur when wsdd receives a second SIGTERM signal before it was done shutting down.

Ideally it should just ignore the second SIGTERM if it is already busy shutting down.

[christgau]

Ok, I see. I am able to reproduce the issue with an older version by sending SIGTERM twice. However, with the latest release, i.e. v0.7.1. the error does not show up. I would suggest to update to the recent version, if possible.

[kroese]

I am using v0.7.0 as that is the one included in Debian Trixie, but if you say it is solved in v0.7.1 then I will see if I can use that one, thanks!

[JedMeister]

@kroese - It'd be awesome if you could open a Debian bug - noting the issue and also noting that the current version fixes it. Hopefully then the maintainer will upload a new version!

As you point out the version in Trixie (and also Bookworm & Sid) is v0.7.0 and the most recent upload to Debian was Oct 2022 (I assume when v0.7.0 was the latest?)

If you do open a bug, I suggest including a link to this issue (so you will only need to give a basic outline).

Having said that, if you aren't running Debian anywhere, then reporting bugs to Debian can be a bit of a PITA. Depending on how the container is set up, you may be able to do it within the container, but that too can be a PITA.

If you do report, please post back with the bug ID, or better still a link to it. If you don't within the next few days to a week, I'll try to circle back and report it myself.

TBH though, it appears that the maintainer may be AWOL. He doesn't appear to have been active since he did the v0.7.0 upload and there is an outstanding MR (Merge Request) (GitLab equivalent to GitHub Pull Request) that has been sitting there for about a year. So if the maintainer doesn't respond within a reasonable timeframe, I might even have a go at updating it myself. (Not something I'm experienced at but something I've been meaning to wrap my head around and this would potentially be a good opportunity).

[kroese]

@JedMeister I just added an extra line to the Dockerfile:

ADD https://raw.githubusercontent.com/christgau/wsdd/master/src/wsdd.py /usr/sbin/wsdd

which overwrites /usr/sbin/wsdd with the latest version from this repo. So that fixes the issue until the Debian package is updated. Would be nice if you became the new maintainer so that workarounds like these are not needed anymore.

[JedMeister]

Ok @kroese - no worries.

FWIW I'm neither directly involved with wsdd nor Debian. I'm just a random wsdd (and Debian) user, who sticks his nose in here every now and again...

As Debian user, I'm always happy to see bugs reported to Debian (and ideally fixed ASAP). IMO it's also good if the latest version of software is in Debian testing. That way the newer version should make it into testing and will at least be a newer version in the next Debian stable release (if it doesn't, then the same old version will be there next stable release). It's probably not such an issue right now - as there won't be a new stable release any time soon, but better is better! :grin: