mcdonald
-
Posts
342 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Gallery
Downloads
Events
Blogs
Store
Posts posted by mcdonald
-
-
CentOS/RHEL 5 and other derivatives are using glibc-2.5.
I am looking into building a VM for CentOS 5.5; I expect that to be the hard part, since I think I can easily set up builds/tests using the remote build/test system once I create the image.
-
Seems everything seems to rotate around flashy shiny linuxes like Ubuntu and Fedora.
My intent in keeping up with upgrades is more to obtain fixes for security problems. Although, I'm not tracking specific open-source products to see if upgrades do in fact resolve security issues, and I don't expect to have time to do so. Sometimes upgrading is beneficial for obtaining bug fixes, especially for gcc.
I'm OK with the "don't fix it if it isn't broken" way, but I also consider security vulnerabilities to be evidence of breakage and worth an upgrade.
-
With the Glib 2.11 requirement the UTserver no longer works on server linux distrubutions?
anyway I see it, there is no workaround on my Debian Lenny server edition, since the specific GLIB version is missing.
Release archives are built and unit and system tests are run on Ubuntu 10.10 and Debian Lenny. The Debian Lenny VM I'm using to build has:
# dpkg -l | grep "C Library"
ii libc6 2.7-18lenny6 GNU C Library: Shared libraries
ii libc6-dev 2.7-18lenny6 GNU C Library: Development Libraries and Hea
ii libc6-xen 2.7-18lenny6 GNU C Library: Shared libraries [Xen version
ii locales 2.7-18lenny6 GNU C Library: National Language (locale) da
#Is 2.7 early enough? If it would be useful, I'll see about releasing the Debian Lenny builds as well as the Ubuntu builds for next release (although the Debian Lenny build won't be stress tested this time since I don't have a local machine running Lenny - it is the identical code and revision as is built on Ubuntu). Post if releasing this Debian build would help.
-
Once the latter fix is reviewed and committed, and nightly builds/tests pass, I'll be starting a stress test on the next revision, which I would expect to be released next Monday, March 14.
The fix was reviewed and committed yesterday, the nightly builds/tests succeeded/passed, I started a stress test just now. If everything goes well, next release should be Monday, March 14.
-
My only problem is that some torrents that would normally create a folder in "new downloads" folder does not. And when that torrent is finished it moves the whole "new downloads" folder to the "finish" folder, containing also the half finish downloads. Result is that all torrents downloading fails since the "new downloads" folder with all content is moved to "finish" folder. So here it stops, with "failed" info on all active torrents except the one that just finished. So moving folder back and force re-check is the only option to get things back working when this happens.
An engineer here found the cause of this problem, and fixed it. I was going to start testing today, but I'm still waiting for a code review on a fix for a race condition I discovered last Friday that causes a crash when adding torrents. Once the latter fix is reviewed and committed, and nightly builds/tests pass, I'll be starting a stress test on the next revision, which I would expect to be released next Monday, March 14.
-
@mcdonald
NO. Looks like it is my fault.
My justification: there no any ending slashes in uTorrent config
The program should handle accepting a directory path whether or not it ends with a slash. However, since there is this work around, it is not as high a priority a bug.
-
For FreeBSD:
Adding torrents:
Torrent File: NOT WORKING
Have you tried ensuring that all values you choose for dir_active/dir_completed and other path settings are terminated by a slash?
-
I have "Error ??", without any explanation.
Can I ask about more verbosity in logs? Please...
An engineer here committed changes to add a log entry whenever a torrent changes to an error state. That change won't be in the release I expect to have ready for today, but it will be in the next release.
-
uTorrent created directories with 777 mask, but files with 644... Maybe it should create directories with 755 mask?
utserver creates torrent data files (I think torrent files also) using the umask in effect when utserver is started. utserver creates files not intended to be exposed to non-administrative users (e.g., settings files) with access independent of the umask in effect when utserver is started. I made a note to add this to the documentation.
All directories created by utserver are created with access 777 as you have noticed. If that's important to you, post one or more use cases for being able to vary access to directories created by utserver.
-
I've got µTorrent Server up and working fine on my Debian 5.0 box' date=' but it dies every six hours or so.
...
every time it died it complained of a segfault.
...
Any possible solutions or logs I can hand over to ease debugging?[/quote']
The same problem. When I run it as "./utorrent" in screen session - all works fine. Previous versions works fine too.
I've been running utserver on a Debian Lenny VM since yesterday and no crashes (no torrents either, but one user reported they saw a crash when no torrents were active).
How about if everyone seeing this problem does the following:
1. set the logmask setting in the configuration files to 0xFFFFFFFF
2. set the -logfile option to generate a log file (specify a location large enough to handle a large log file)
3. run utserver (as daemon or not)
4. wait for a crash
5. look at (near the end of) the log file for anything interesting and post it if so
Maybe we will see some common internal activities occurring immediately before the crash.
I will work on a new release so that utserver incorporates any recent fixes in the main code line.
-
If I'm understanding you correctly, there's one thread dedicated to moving just-completed torrent data, and thus the moving of completed data files would never cause fragmentation in and of itself? (apart from what would happen anyway given the current allocation of blocks on the target drive).
Currently there is one thread that performs all the just-completed torrent data file moves, according to the requests in its work queue. So, moves aren't interleaved; one move is performed and completed before the next move is started. No guarantee this implementation won't change, although I don't expect it to change.
Of course, depending on what else you've got running on the computer, you can still have fragmentation. That's why I was mentioning preallocation.
I'd try preallocation of files as a strategy to avoid fragmentation.I used to do this on Windows' date=' as pre-allocation works fine there. It's been different using WINE on Linux, though, as it seems that either the pre-allocation routines are either not translated correctly to the OS layer by the WINE libs, or perhaps not all Linux FSes support pre-allocation?[/quote']
It's possible it may be a deficiency in uTorrent Server. I haven't tested pre-allocation. However, when I tried that option recently, I thought I saw the file size grow immediately rather than later. I need to look at the code and test this more carefully to confirm this.
Is there work going on to make sure that pre-allocation will work correctly with this Linux port? The fact that I haven't been able to make it work in Linux is the sole reason I have a 600 GB RAID0 temp drive
There isn't any work being done on preallocation on Linux. I can put it on my personal to-do list to at least see if it works or not, but I've got assigned tasks that have priority. I'll add a task to the issues list if I find it doesn't work.
-
Do you know if "move threads" are queued or may happen simultaneously? I mean that if one thread is running and moving a file while another download finishes, will the newly finished torrent wait for the other move operation to finish before starting its own move operation (to avoid fragmentation on the target drive)?
A torrent data file move operation is requested for every just-completed torrent that needs it. The requests are queued for the thread that performs these operations. The operations will wait based upon the positions of the associated requests in the queue, but the requests are made immediately and rapidly; making the request won't block the requesting thread.
Right now, a torrent data file move operation is done all at once and not interleaved with other operations. This non-interleaving behavior may change in the future so I would not recommend depending on it. I'd try preallocation of files as a strategy to avoid fragmentation, although preallocation won't help if you are moving files between file systems since the preallocation occurs on the files in the active directory, not the completed directory.
-
If pre-allocation won't work, will we see better behavior when finished files are moved to a different directory on a different drive, i.e. when moving of the files take a long time? Previously, when finished files are being moved to the target directory, the download speed of every other torrent would drop to a practical halt.
I think you will see better behavior because file moves are now done in a separate thread.
-
What are the chances that there's an unofficial / unsupported / hacky way to get HTTPS tracker support (and/or what's the timeline for official support in utserver?)
I don't think there's a target time to support that feature. I've added an item to the issue tracking system, so that people can discuss it at the next planning meeting.
-
I wouldn't want to find out that this suggestion is causing more headaches for µTorrent Server devs.
It's OK with me, although mentioning in any web UI-related bug report that you are using a web UI different from what is distributed with the product would keep me from wasting time testing with the wrong web UI (better yet would be if possible to try with the included web UI before reporting). I won't necessarily test other web UIs, but if somehow a server bug is only reproduceable using another web UI, I'd try it.
µTorrent Server's version has since diverged and implemented things in its own way, but they're not greatly divergent enough for the changelog to be irrelevant.I think developers here are trying to keep the existing HTTP interface the same, adding new actions if new features are needed, although also changing/fixing behavior that we determine to be broken (e.g., the list-dirs action was broken until recently). I'd like to not prevent use of other web UIs.
There are still things that are unimplemented in my version (like the /gui/?action=getversion request used by utserver webui.zip's About dialog), but most of the major elements should be there.Eventually that action will probably be made to work on all releases, but that isn't the highest priority right now.
-
I've just installed the 23090 build and it is showing radically different network behaviour to the 21886 build I had before. In some respects it seems like the uTP is being excessively sensitive and keeps choking off my bandwidth, and turning off uTP made things a lot better. However, I think the culprit is just tcp_rate_control. Setting this to false seems to cure the problem. I don't know if the setting wasn't working in the 21886 build or whether something is broken in the 23090 build, but they are certainly different. Or maybe uTP bandwidth control wasn't working at all in the earlier build?
I'm trying to keep the branch from which uTorrent server closer to the leading edge of development efforts. As a result, the product will benefit from recent features and bug fixes, but some surprises may be introduced; I'd expect the surprises to be related to performance since the unit and system tests test behavior correctness not speed (although the tests will detect excessively long times to accomplish required tasks). I'll be rebranching soon, and that may pick up further work that reduces the sensitivity you are seeing, since I seem to recall some updates in uTP recently. If the next revision doesn't help, post and I'll add a report to our issue tracking system.
-
Thank you for the unicode support!
I hope that means it is working for everyone, especially those using Cyrillic character sets, for which the problem seemed most obvious.
Have a problem with this release (didn't try any previous) - if file in torrent contains cyrillic letters' date=' the file name ([b']on disk! not in webUI) looks like ??????????????.mkv and so on.I don't have this problem.You may be have a problem with fonts!
Previous revisions did have a problem with localization. I haven't heard any reports of localization problems with the latest release; no news can be good news. Sounds like you don't see that problem, which is a good sign.
-
in 23090 please fix labels
IE 9 Beta - dont load web
The product will pick up the fix for labels when I rebranch the code line (probably this week).
I haven't tried IE 9 beta. IE 8 will work on the next release after 23090 so maybe IE 9 will work too; I resolved a Javascript syntax problem that Firefox was OK with but IE would not accept.
-
Ok' date=' now it's obvious: the linux Webui cannot work with SSH port forwardings.
The 23090 version just crashes... the older version starts with it, but corrupts the handshake procedure.
So, can you please fix this issue in the next release? It's a very important feature IMHO. (At least for be, living behind a proxy.)[/quote']
Thanks for the report. I've asked a developer who recently worked on the Socks5 proxy to look at this.
Turns out that developer was working on the UDP proxy, which of course would not affect proxying of the web interface (TCP). I'll see if I can get some time to try to reproduce this.
-
Ok, now it's obvious: the linux Webui cannot work with SSH port forwardings.
The 23090 version just crashes... the older version starts with it, but corrupts the handshake procedure.
So, can you please fix this issue in the next release? It's a very important feature IMHO. (At least for be, living behind a proxy.)
Thanks for the report. I've asked a developer who recently worked on the Socks5 proxy to look at this.
-
Have a problem with this release (didn't try any previous) - if file in torrent contains cyrillic letters, the file name (on disk! not in webUI) looks like ??????????????.mkv and so on.
I think I've discovered what caused that. The latest release actually works worse for those customers using cyrillic character sets, because the improvements in the code fixed one part of the issue but not another. I expect to have a release that resolves this early next week.
-
When exactly does finish_cmd fire? Is it when a torrent is downloaded (but still seeding) or when it is finished (downloaded and stopped)?
At the point the program completes downloading the torrent data files for the torrent. Whether the torrent is seeding or stopped after completion doesn't matter.
If there is to be a move of the data files upon completion, the data files will be moved before the finish_cmd command is executed.
If there is to be a move of the torrent file, the finish_cmd will be executed before the torrent file move if the torrent data files are not to be moved, and the finish_cmd will be executed in a separate thread (not necessarily after the torrent file is moved) if the torrent file is to be moved after completion.
-
The next release, which will go out Tuesday if all goes well, won't have a fix for this.
Whoops - make that Monday.
-
I have a bug from the new alpha, label doesn't work anymore in webui. I choose one label in context menu but nothing append.
This is a problem in multiple products. I based the most recent server release on a more recent branch, which has the advantage of picking up generic bug fixes and optimizations made since the previous branch (which was made about 8 months ago), but has the disadvantage of sharing with other products any not-yet-discovered bugs.
I don't have a system test that tests label handling in the HTTP interface; I added that to my task list just now.
The next release, which will go out Tuesday if all goes well, won't have a fix for this.
µTorrent Server 3.0 alpha build 27079 (for Linux) - x86
in Announcements (Linux)
Posted
I created a CentOS (5.4) VM image, and hooked it into the remote build/test system. I'll review the results of the nightly builds/tests tomorrow morning.