• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About hjuirty

  • Rank
  1. For the zombie processes issues, I'd like to give you as complete a bug report as I can come up with in the hopes that you can reproduce it. My version of utorrent server: root@heloise:/home/utorrent/utserver# ./utserver -usage server started - using locale en_US.UTF-8 300B (25053) 2011-03-08 00:11:48 +0000 (Tue, 08 Mar 2011) my script to start utserver: UTHOME=/home/utorrent/utserver exec su utserver -c "$UTHOME/utserver -configfile $UTHOME/utserver.conf -settingspath $UTHOME/config -logfile $UTHOME/logs/ut.log -daemon" my server directory layout: http://pastebin.com/B7Y01JHE Linux version (debian 6.0.3 32-bit with 256MB of RAM) and ps listing showing zombie processes: http://pastebin.com/JfauX26m here the server has only been running for 24 minutes. All the zombie notify.sh processes are times that I got a notification from the server but chose not to send it out via e-mail. The zombie sendmail is because I exec sendmail instead of running it in a sub-process (an attempt to try to get around the zombie process issue that didn't do me any good). My utserver.conf: http://pastebin.com/fH1bghB4 The state_cmd in that file is not the one the server actually runs. Although state_cmd is supposed to be on the list of things that settings.dat picks up, it doesn't in my case The actual command is the same as the one in the .conf file but with less arguments: The relevant bits copy and pasted from settings.dat: :state_cmd81:/home/utorrent/notify.sh bug_workaround "N%N" "S%S" "M%M" "K%K" "F%F" "D%D" "P%P" Notification shell script: http://pastebin.com/deVVdven Other relevant facts: My utserver is running inside a 32-bit VM on my 64-bit linux box, since you recommended 32-bit linux for now (and it worked well for me since I ran uTorrent for windows the same way). I would be happy to give you the VM if it would help. It's a kvm VM and is ~2GB. The VM stores all its data on the host server via a samba share (the /fdrive that the conf file refers to is that share). Again, that's the way my windows uTorrent worked so I just carried it over to utserver. I think that's about it for my actual bug report. Now for my opinions :-) 1) I love utserver the way it is (other than this bug, of course), with possibly an updated webui and core for RSS support. It's fast, uses less memory and is more reliable than my windows version (which may be due to a bad VM). I've never had it crash, although I do restart it every couple of days due to the zombie process issue. 2) I believe a workable quick solution for this issue would be to add something like this: #include <sys/types.h> #include <sys/wait.h> while( waitpid( -1, NULL, WNOHANG ) > 0 ); (or, more clearly): int childPid = 0; do { childPid = waitpid( -1, NULL, WNOHANG ); } while( childPid > 0 ); right above where you call fork() or system() or however you call the state_cmd. This isn't ideal - you'd still be leaving one zombie process around. But under normal circumstances (if the children finish fast enough) you'd leave at most one, which would be a huge improvement over what I'm seeing right now. Again, thank you very much for making uTorrent server. It's siomplified my bittorrent life a great deal over having to restart my windows VM all the time (or deal with the hassle of trying to rebuild it).