Just in my case, it doesn't actually download something because it cannot connect to any peers. (Thinking/hoping it was a handle leak or something similar where the connections just aren't being closed properly.) 50 global, 15 for new transfers. ![]() Today was a good day: it got 5.66GB downloaded and 2.22GB uploaded before the sockets locked up.Īnd I have explicitly reduced the number of simultaneous connections both globally and per-transfer to try to extend the usable lifespan of each restart. Luckily, there ends up being no active transfer underway by the time it gets here. Interesting I've been essentially required to force-close Transmission when it's entered this state. As if it was actually downloading something, and then trying to pause the torrent so it can close "safely". Yea, takes a little while (few seconds) but then closes. In my case, it appears to lock up (pinwheel) when attempting to quit. Question when in this state, do you find it possible to quit Transmission in a normal way? Following roughly (slightly tweaked launchd plist) the directions from this StackOverflow answer and the linked MacObserver article. I'm investigating increasing the number of file handles, but SIP throws a minor wrench into the works, there. A HUP kill signal or rehash command via that private message window forces it to re-bind. *** An admin has to rehash to reopen the listening port ![]() *** We hit the FD limit, closing listening socket on It alerts me via a private message from *status: It seems similar to / related to an issue I encounter with ZNC, where ZNC notices it's run out of available file handles and closes its listening socket. This happens multiple times per day, but admittedly, I have an extremely large number of active seeds. Port forward is static at my firewall/gateway, not dynamically requested by UPnP/NAT-PMP. I confirm the need by opening up Settings and having it re-evaluate the port forwarding status. Quitting alone hard-locks Transmission force-quitting and restarting reopens the listening socket. Port forwarding stops working after a while Which application of Transmission? I've been notified of a similar issue in the Transmission issue tracker: There seem to be something maybe related to the M1 here. I also tried Nicotine+ on an Intel Mac and it had no problem with closed port after a few hours. I tried Nicotine+ on a Windows machine on the same LAN and no issue with the port getting closed. Port forwarding (with UPnP auto port forwarding or manually) stops working on Mac OS X (apple silicon M1) after a few hours I'm using an Apple M1 Mac Mini and noticed a similar problem with Nicotine+ (but here the port becomes "closed" after a day). ![]() The port and the port is forwarded manually on the router. If I restart Transmission the port is back to "open"… for the next 6 days. After a fews day of running Transmission (usually about 6), the listening port status shows the port as "closed".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |