I'm quite convinced that it's the u-d-m that's keeping connections open to the
server and causing the slow s-i shutdowns. I run htop while running my test
suite, filter on `ubuntu-download-manager` and I can see the 3-4 processes for
u-d-m (I'm presuming they're actually threads).
If while in the s-i shutdown code, I list the open files for each of the
processes, I can see IPv4 type open fds which are the connections to the
server. I can't close those from htop, but if I actually kill the process
(and let dbus activation restart it later), then the s-i shutdown code returns
immediately.
I'm quite convinced that it's the u-d-m that's keeping connections open to the download- manager` and I can see the 3-4 processes for
server and causing the slow s-i shutdowns. I run htop while running my test
suite, filter on `ubuntu-
u-d-m (I'm presuming they're actually threads).
If while in the s-i shutdown code, I list the open files for each of the
processes, I can see IPv4 type open fds which are the connections to the
server. I can't close those from htop, but if I actually kill the process
(and let dbus activation restart it later), then the s-i shutdown code returns
immediately.