uT 25376 x64 problems & feedback - startup, file persistence & logging

[linut]

After a couple of days using the µTorrent Linux Server I've come across a few niggles and have a bit of feedback.

Debian Wheezy/testing, 64-bit

utorrent-server-3.0-debian-25376.x64.tar.gz

utorrent-webui.2011070211494928.zip

'Installed' in this hierarchy: http://pastebin.com/raw.php?i=VEJv0LG3

Starting and stopping the utserver process

Even when employing the -daemon argument, utserver outputs a status message to the terminal which interferes with any start/stop script being used:

root@quantum:~# /etc/init.d/utserver start
Starting µTorrent server: utserverserver started - using locale en_GB.UTF-8
.
root@quantum:~# /etc/init.d/utserver stop
Stopping µTorrent server: utserverserver exited with 0
.
root@quantum:~#

Would you consider omitting these messages by default and adding a -verbose argument for users who explicitly want them directed to stdout? The locale message can, after all, be found in the log file and the exit status by querying $? at the terminal.

Resuming torrents after utserver shutdown or restart

Strange behaviour and broken functionality appears to be evident whenever one attempts to resume existing torrents in the queue. Note that I have dir_active = dir_torrent_files in utserver.conf.

On using 'Add Torrent from URL' in the WebUI, the .torrent gets downloaded to dir_active and renamed giving a .utt file. If the utserver process is stopped and restarted then all .utt files in dir_active are deleted while any partially downloaded files remain. This has the effect of breaking all torrents in the queue and is reflected in the logfile by, for example, "Error: <NULL> - Can't open .torrent file: /home/share/incoming/torrents/000029ac-0001.utt" and in the WebUI as shown in the following images,

http://i53.tinypic.com/f55e7o.png (downloading)

http://i51.tinypic.com/210c1nd.png (stopped)

http://i53.tinypic.com/bg4cue.png (following utserver restart)

Conversely, using 'Add Torrent' in the WebUI to load NewVisionV1.zip.torrent (from here) is accompanied by an entry of "uT HTTP torrent add of '/home/share/incoming/torrents/00002a74-0001.utt' succeeded" in the log file, however, neither the .torrent or .utt is found in dir_active or dir_torrent_files. When the torrent was stopped and the utserver process restarted an entry of "Error: <NULL> - Can't open .torrent file: /home/share/incoming/torrents/00002a74-0001.utt" is made in the log file and reflected in the WebUI as depicted in these screenshots,

http://i54.tinypic.com/15rnzgl.png (stopped)

http://i55.tinypic.com/jpu3yw.png (following utserver restart)

I'd like to understand why utserver bothers to rename .torrent files to .utt and why it doesn't let them persist through process restarts which would hopefully avoid it spitting the proverbial dummy and breaking the queue when subsequently launched?

Log file and logging behaviour

The utserver process creates a new log file when launched. I would like to suggest that it appends to an existing file, if present.

The log timestamps are, for myself at least, not intuitive. Please adjust them to reflect the system time in a manner similar to the syslog with a format based upon the user's locale? I also feel the problem of pinpointing an error or message is further exacerbated by utserver tracking uptime, and cycling over a 24-hour period, rather than system time.

Finally, I wonder if it would prove more useful for utserver to use a small bitmask to log errors and increasingly higher bitmasks for warnings, bittorrent protocol, WebUI and networking packets. Per the included documentation I'm currently testing with 0x3FFF (17) to log 'error' yet this fills the log file with frequent "Send Have <piece>" and "Got Have <piece>" messages which don't seem relevant if one is interested in only recording the worst issues.

Of course much appreciation for the work on the µTorrent Linux Server.

[mcdonald]

Starting and stopping the utserver process

Even when employing the -daemon argument, utserver outputs a status message to the terminal which interferes with any start/stop script being used:

root@quantum:~# /etc/init.d/utserver start
Starting µTorrent server: utserverserver started - using locale en_GB.UTF-8
.
root@quantum:~# /etc/init.d/utserver stop
Stopping µTorrent server: utserverserver exited with 0
.
root@quantum:~#

Would you consider omitting these messages by default and adding a -verbose argument for users who explicitly want them directed to stdout? The locale message can, after all, be found in the log file and the exit status by querying $? at the terminal.

The locale message is also generated when running utserver -usage, which exits immediately after generating the usage message; I'll start suggesting that to users. The default stdout message at the start that announces the locale being used has been very useful a number of times in resolving locale-related issues. I could drop these, though.

Resuming torrents after utserver shutdown or restart

Strange behaviour and broken functionality appears to be evident whenever one attempts to resume existing torrents in the queue. Note that I have dir_active = dir_torrent_files in utserver.conf.

On using 'Add Torrent from URL' in the WebUI, the .torrent gets downloaded to dir_active and renamed giving a .utt file. If the utserver process is stopped and restarted then all .utt files in dir_active are deleted while any partially downloaded files remain. This has the effect of breaking all torrents in the queue and is reflected in the logfile by, for example, "Error: <NULL> - Can't open .torrent file: /home/share/incoming/torrents/000029ac-0001.utt" and in the WebUI as shown in the following images,

http://i53.tinypic.com/f55e7o.png (downloading)

http://i51.tinypic.com/210c1nd.png (stopped)

http://i53.tinypic.com/bg4cue.png (following utserver restart)

Conversely, using 'Add Torrent' in the WebUI to load NewVisionV1.zip.torrent (from here) is accompanied by an entry of "uT HTTP torrent add of '/home/share/incoming/torrents/00002a74-0001.utt' succeeded" in the log file, however, neither the .torrent or .utt is found in dir_active or dir_torrent_files. When the torrent was stopped and the utserver process restarted an entry of "Error: <NULL> - Can't open .torrent file: /home/share/incoming/torrents/00002a74-0001.utt" is made in the log file and reflected in the WebUI as depicted in these screenshots,

http://i54.tinypic.com/15rnzgl.png (stopped)

http://i55.tinypic.com/jpu3yw.png (following utserver restart)

I'd like to understand why utserver bothers to rename .torrent files to .utt and why it doesn't let them persist through process restarts which would hopefully avoid it spitting the proverbial dummy and breaking the queue when subsequently launched?

Are you also defining dir_temp_files as the same directory as dir_active and dir_torrent_files? That's a way that the .utt files would be deleted upon startup. Otherwise, I don't see why this would occur. I'll wait for your reply to this before investigating further.

Log file and logging behaviour

The utserver process creates a new log file when launched. I would like to suggest that it appends to an existing file, if present.

The log timestamps are, for myself at least, not intuitive. Please adjust them to reflect the system time in a manner similar to the syslog with a format based upon the user's locale? I also feel the problem of pinpointing an error or message is further exacerbated by utserver tracking uptime, and cycling over a 24-hour period, rather than system time.

I'll add that to the change request list.

Finally, I wonder if it would prove more useful for utserver to use a small bitmask to log errors and increasingly higher bitmasks for warnings, bittorrent protocol, WebUI and networking packets. Per the included documentation I'm currently testing with 0x3FFF (17) to log 'error' yet this fills the log file with frequent "Send Have <piece>" and "Got Have <piece>" messages which don't seem relevant if one is interested in only recording the worst issues.

It would be useful to report severity as a code and have log messages be filterable by severity. This would need to happen in all products and as a result probably won't happen in the short term.

[linut]

mcdonald,

Thanks for your prompt and receptive response.

Are you also defining dir_temp_files as the same directory as dir_active and dir_torrent_files? That's a way that the .utt files would be deleted upon startup. Otherwise, I don't see why this would occur. I'll wait for your reply to this before investigating further.

Yes. I don't have dir_temp_files defined in utserver.conf and so this has presumably defaulted to match dir_active. In my case, therefore, I use the one directory for dir_active, dir_temp_files and dir_torrent_files and a second directory for dir_completed. Both do exist as subdirectories of an exported Samba share although the former is restricted by use of the 'veto files' variable in smb.conf.

It looks like my problem is possibly that I don't have sufficient understanding of the difference between dir_temp_files and dir_torrent_files after reading the included documentation. It is made clear that "using a separate directory just for temporary files allows for deleting the files in this directory on boot and/or periodically." but I was left confused by utserver logging error messages which indicated it could not open a torrent's .utt file when it is apparently already programmed to delete them.

In an attempt to gain a better understanding I adjusted these variables in utserver.conf to read,

dir_active: /home/share/incoming/torrents

dir_completed: /home/share/incoming/complete

dir_temp_files: /home/share/incoming/torrents/temp

dir_torrent_files: /home/share/incoming/torrents

and restarted utserver with deleted .dat files. Things now appear to work fine; a .torrent file is now found to persist in dir_torrent_files (and a .utt can be seen in the temp subdirectory when a torrent is added via the WebUI using 'Add Torrent from URL' but not when added by 'Add Torrent') whereas this was not the case when dir_temp_files was undefined - in fact .torrent files were never seen.

Okay, so I've found the 'solution' and I'm sorry to have put it in such a long winded way. What I had expected and hoped, however, was that I could have gotten away without creating this third directory which is only going to hold transient files. Why a .torrent and its corresponding .utt cannot exist in the same directory without breaking utserver functionality I do not understand.

[mcdonald]

I don't have dir_temp_files defined in utserver.conf and so this has presumably defaulted to match dir_active.

Yes, that is the product's behavior in that case: dir_active also being the temporary file directory as the result of defining dir_active and not dir_temp_files.

In my case, therefore, I use the one directory for dir_active, dir_temp_files and dir_torrent_files and a second directory for dir_completed. Both do exist as subdirectories of an exported Samba share although the former is restricted by use of the 'veto files' variable in smb.conf.

I wouldn't think having these directories participating in Samba sharing is necessarily a problem. However, if you aren't the only consumer of the shared directories, I'd limit the sharing to the completed directory or define a program to be run upon completion (see the finish_cmd configuration file setting) to copy the files to a directory being read-only shared by Samba. Also, I would not want to set up utserver to be using any remotely mounted drives for these directories. You may already know this, but I'm trying to ensure these details aren't overlooked in order to save our time resolving your issue.

It looks like my problem is possibly that I don't have sufficient understanding of the difference between dir_temp_files and dir_torrent_files after reading the included documentation. It is made clear that "using a separate directory just for temporary files allows for deleting the files in this directory on boot and/or periodically." but I was left confused by utserver logging error messages which indicated it could not open a torrent's .utt file when it is apparently already programmed to delete them.

I'm still looking into that. Maybe defining dir_autoload as that directory could cause this problem. However, dir_autoload is designed to be disabled if there isn't an explicit definition for it. Theoretically, you could supply the same value for dir_autoload as you supply for dir_torrent_files, but the program is supposed to disallow autoloads in that case so that torrent files for active torrents aren't renamed or deleted.

In an attempt to gain a better understanding I adjusted these variables in utserver.conf to read,

dir_active: /home/share/incoming/torrents

dir_completed: /home/share/incoming/complete

dir_temp_files: /home/share/incoming/torrents/temp

dir_torrent_files: /home/share/incoming/torrents

and restarted utserver with deleted .dat files.

That's how I would have set up the configuration file, were I to decide I wanted to define dir_active, except I would have expected that I would not need to delete the *.dat files since all those directories are read from the configuration file at every startup.

Things now appear to work fine; a .torrent file is now found to persist in dir_torrent_files (and a .utt can be seen in the temp subdirectory when a torrent is added via the WebUI using 'Add Torrent from URL' but not when added by 'Add Torrent') whereas this was not the case when dir_temp_files was undefined - in fact .torrent files were never seen.

Okay, so I've found the 'solution' and I'm sorry to have put it in such a long winded way. What I had expected and hoped, however, was that I could have gotten away without creating this third directory which is only going to hold transient files. Why a .torrent and its corresponding .utt cannot exist in the same directory without breaking utserver functionality I do not understand.

I don't understand why the files can't be in the same directory; I probably won't have time to investigate this any time soon, since a workaround exists.