From web-site: Version 1.34 Released! Posted by John Clay on 17/09/08 Reproducible: Always Steps to Reproduce: Expected Results: Bump?
Created attachment 166013 [details] transmission 1.34 ebuild Transmission 1.34
This ebuild is a direct copy of the 1.33 ebuild, renamed for 1.34. Works fine on my (non-gtk) installation.
Well, on my xfce4 box it's randomly crashes then I switch to other viewport... I'll trace it later...
Uh... It was something with my xfs partition... Works fine now...
Created attachment 167840 [details] New init.d script Part 1 of 4 of the ebuild changes.
Created attachment 167842 [details] New conf.d file needed by init script. Part 2 of 4.
Created attachment 167844 [details] Updated changelog. Part 3 of 4.
Created attachment 167846 [details] New ebuild with added features and corrections. Part 4 of 4.
The above 4 files make a better Transmission installation, as shown in the Changelog: * Fixes the reported bug about transmission being left to run as root. Now by default it runs as nobody and saves its configuration and downloads under /var/transmission (changeable in the parameters). * Changes the init.d script allowing to use just about all the options transmission can use, but using a separate conf.d/transmission file. * The configuration file has documentation to help the user.
Created attachment 168106 [details] Corrected (my own) init.d script. Corrected a mistake that caused the script to erroneously set the -M option (port mapping enabled).
Created attachment 168222 [details] Another correction to init.d script. Added early exit on daemon start failure (and correct status).
@r.berber Do you have taken the suggestions for Gentoo from their wiki [1] into account? [1] http://trac.transmissionbt.com/wiki/Headless%20Transmisison#NotesonGentoo
Yes, I wrote those notes. I also keep them in sync with what I submit here. I've had help from transmission users and developers through their forum.
Can I ask why it depends always on glib, also if USE="-gtk -libnotify"? I tried with version 1.33 to compile under ucilibc without glib (removing dependency from ebuild) and it seems to work.. (obviously just -daemon and -cli) Now I'll try this version.
@ Edoardo Liverani : I see your point but it's not only gtk depending on glibc, looking at the ldd output from any of the 3 headless programs you can see they use libresolv.so which is brought from sys-libs/glibc-2.6.1 or similar (other version). You must be pulling your own libresolv from uclibc (I don't know what the ucilibc you mention is). So, if uclibc does have libresolv, what you really want is to add a USE option to include a dependency on uclibc (and exclude gtk, glibc, whatever)... or better yet, use your toolchain and replace/exclude whatever you need to. I'm not doing embedded (yet), so you are welcome to modify the ebuild and ChangeLog.
(In reply to comment #15) > You must be pulling your own libresolv from uclibc (I don't know what the > ucilibc you mention is). So, if uclibc does have libresolv, what you really uclibc doesn't really have libresolv, it has just a stub, empty, just a link warning really.
..and so 1.40 was released. Any news on when/if 1.34 is going in or is compnerd going for inclusion of 1.40? And what is holding the other changes?
(In reply to comment #14) > Can I ask why it depends always on glib, also if USE="-gtk -libnotify"? > I tried with version 1.33 to compile under ucilibc without glib (removing > dependency from ebuild) and it seems to work.. (obviously just -daemon and > -cli) > Now I'll try this version. I was wrong, it is as you say and it has been corrected on the ebuild I attached today to the version 1.40 thread.
Created attachment 172806 [details] Changed glib dependency as sub-dependency of gtk. Changes: - dev-libs/glib dependency only checked when USE gtk requested. - libnotify dependency only checked when USE gtk requested. - added check for curl built with openssl or gnutls.
Created attachment 172889 [details] Updated ebuild with tf-b4rt-support
I use torrentflux-b4rt which needs a patched transmissioncli to be able to use it. I thought it would be nice to have this working out of the box so I added this to René Barbers latest ebuild. Pretty simple, if USE-flag tf-b4rt is set the patch is applied. You would need the patch placed in the files-directory of the ebuild, available through SVN: svn checkout svn://svn.berlios.de/tf-b4rt/branches/clients/transmission/transmission-1.34
(In reply to comment #21) > I use torrentflux-b4rt which needs a patched transmissioncli to be able to use > it. You might want to update also the file for version 1.40, which is here: https://bugs.gentoo.org/show_bug.cgi?id=246557 And probably next week the one for version 1.41 (which is in beta now).
(In reply to comment #22) > > You might want to update also the file for version 1.40, which is here: > > https://bugs.gentoo.org/show_bug.cgi?id=246557 > > And probably next week the one for version 1.41 (which is in beta now). I did update it for 1.40 for personal testing, but since I had such horrible performance with both 1.34 and 1.40 I am now running 1.22. The problem I had was slow d/l speeds which seems to be affecting torrents with many seeders, there some discussion on the transmissionb4rt-forums about this. I tried a patched nigthly-build a week or so ago but it had the same problem. As 1.41 comes out I'll be happy to try it and provide an (updated) ebuild since I'd rather run the newer versions with functions like blocklists and such.
*** Bug 250807 has been marked as a duplicate of this bug. ***
*** Bug 246557 has been marked as a duplicate of this bug. ***
Created attachment 175356 [details] Version 1.40 bump: Changelog, config file, init script, and ebuild file. The files from the now marked as duplicate bug report.
Transmission 1.42 Released
Created attachment 176396 [details] Version 1.42 bump: ebuild, ChangeLog, and conf.d and init.d files. Version bump with slight changes to configuration and startup script to adapt to changes in the syntax used with the whitelists (formerly ACL lists).
(In reply to comment #29) > Created an attachment (id=176396) [edit] > Version 1.42 bump: ebuild, ChangeLog, and conf.d and init.d files. > > Version bump with slight changes to configuration and startup script to adapt > to changes in the syntax used with the whitelists (formerly ACL lists). > Are the conf.d and init.d files based on those given at http://trac.transmissionbt.com/wiki/HeadlessUsageGentoo ? It mentions there were errors in the older init.d script that came with transmission.
(In reply to comment #30) > Are the conf.d and init.d files based on those given at > http://trac.transmissionbt.com/wiki/HeadlessUsageGentoo ? I already answered that on comment #13. > It mentions there were errors in the older init.d script that came with > transmission. The init.d script currently shipping with Gentoo has several error, for one, it doesn't stop the daemon.
(In reply to comment #31) > (In reply to comment #30) > > Are the conf.d and init.d files based on those given at > > http://trac.transmissionbt.com/wiki/HeadlessUsageGentoo ? > > I already answered that on comment #13. > Oops, apologies for not reading the thread. Thanks for writing and posting the ebuild and files.
*** Bug 252992 has been marked as a duplicate of this bug. ***
Please, don't submit binary attachments. They 're useless when you work in bugzie's interface.
I have reported proper ebuild patch and there is a small bugfix patch too. https://bugs.gentoo.org/show_bug.cgi?id=252992
I refuse to look at the attachements using "application/octet-stream", and thus I didn't include them in CVS with 1.42 bump. If you want them included, attach as plain/text and with description.
Created attachment 177022 [details] Version 1.42 bump: ebuild file. Same file as before.
Created attachment 177024 [details] Version 1.42 bump: init.d file. Ditto.
Created attachment 177026 [details] Version 1.42 bump: conf.d file. Ditto.
Created attachment 177028 [details] Version 1.42 bump: ChangeLog file. Ditto.
FYI, I've added 1.42 to Portage today. It's quite different from the ebuild you posted here, but don't worry about it. May want to take a look at the modifications.. sync in an hour or so.
Comment on attachment 177022 [details] Version 1.42 bump: ebuild file. Patch against up to date transmission ebuild in Portage is preferred over so we can see easily what's changed. But in this case, if we are just adding doinitd/doconfd you could just comment on the bug instead of attaching this..
(In reply to comment #41) > FYI, I've added 1.42 to Portage today. It's quite different from the ebuild you > posted here, but don't worry about it. May want to take a look at the > modifications.. sync in an hour or so. You're using the init.d script that doesn't work, did you read the thread? comment #9 is important, also #21 and #23 which imply you shouldn't skip version 1.34.
When you are working on the ebuild: add dev-util/intltool to the dependencies. Transmission configure requires it and breaks when it is not present. Thanks! Fitzgerald.
(In reply to comment #41) > FYI, I've added 1.42 to Portage today. It's quite different from the ebuild you > posted here, but don't worry about it. May want to take a look at the > modifications.. sync in an hour or so. > New /etc/init.d/transmission-daemon script from Portage doesn't work for me: #/etc/init.d/trasmission-daemon start * Caching service dependencies ... [ ok ] * Stopping transmission-daemon ... [ ok ] * Starting transmission-daemon ... Transmission 1.42 (7495) http://www.transmissionbt.com/ A fast and easy BitTorrent client Transmission 1.42 (7495) http://www.transmissionbt.com/ A fast and easy BitTorrent client transmission-daemon is a headless Transmission session that can be controlled via transmission-remote or Clutch. Usage: transmission-daemon [options] Options: -h --help Display this help page and exit -a --allowed <list> Allowed IP addresses. (Default: 127.0.0.1) -b --blocklist E ....
Created attachment 183452 [details, diff] Version 1.52 bump: ebuild patch A new stable release of Transmission, version 1.51, was made. This is the difference btw. my ebuild and the one currently distributed. As before, it needs 2 more files which I'll attach after this one.
Created attachment 183453 [details] init.d script A completely different init.d script from the one currently distributed. This one takes parameters from /etc/conf.d/transmission, which by default run the daemon as user nobody, and store everything (configuration and downloads) under /var/transmission.
Created attachment 183455 [details] Parameters file This file is "optional use", the before attached init.d script has all the "defaults" (of course as defined by me ;-), on the other hand, once the daemon has been run once it can read the last used parameters from the settings.json file (in the config directory)... I just like to start the daemon with known parameters. BTW this file and the last one are only meant to work with version 1.5x, there were changes in the options for the daemon, and also in the -remote tool, which I'm using.
One last comment about my init.d script: there is a new, shorter and cleaner script on the Transmission Wiki, I don't know who made it but it looks good. The 2 scripts are different, mine goes for configuring everything, the cleaner script just assumes you created a transmission user, and the parameters are not even mentioned (the settings.json parameters are used).
René Berber: your script fails to stop the daemon.
(In reply to comment #50) > René Berber: your script fails to stop the daemon. > My experience is that the daemon does stop after some time (from 30 to 45 seconds), the script does show the [!!] and you have to use "zap" to reset the state. I think it is a bug with start-stop-daemon, since I'm using the retry and timeout parameters, but I haven't done any debugging.
reply to comment #51) > My experience is that the daemon does stop after some time (from 30 to 45 > seconds), the script does show the [!!] and you have to use "zap" to reset the > state. > > I think it is a bug with start-stop-daemon, since I'm using the retry and > timeout parameters, but I haven't done any debugging. > I think the problem is that currently start-stop deamon have problems knowing what transmission-daemon is up to and therefore suspects that tranmission is not shutting down as it should. For me I got it working by having transmission-daemon running in forground and having star-stop-daemon creating a "fake" pidfile for it and then use that for stopping the service.
(In reply to comment #52) > > I think the problem is that currently start-stop deamon have problems knowing > what transmission-daemon is up to and therefore suspects that tranmission is > not shutting down as it should. > For me I got it working by having transmission-daemon running in forground and > having star-stop-daemon creating a "fake" pidfile for it and then use that for > stopping the service. Yes, I know. Start-stop-daemon doesn't follow the forked daemon, your solution is good and its the same used in the Transmission Wiki's script I mentioned. On the other hand, by using --name start-stop-daemon does send the kill to the daemon, but the daemon takes very long to shut down, that's just the way it works. The real problem (with the way I do it) is that the retry/timeout part is not working as it should, the stop returns much more quickly than the times I specified... I haven't figured out why. Conclusion: your solution is the currently best way to do it. I wonder where is all the daemon's output going, since running it in the foreground is the "debug mode" for this little beast... perhaps we should add a log to the recipe and capture the output there (since the daemon lacks any logging anyway).
I get no [!!] when stopping it. I get [ ok ] it just doesn't actually stop not even after a minute or more. It just keeps on going and going like the energizer bunny. :|
(In reply to comment #54) > I get no [!!] when stopping it. I get [ ok ] it just doesn't actually stop not > even after a minute or more. It just keeps on going and going like the > energizer bunny. :| Did you installed it first, then tried to stop it? Then I know what is happening, its a side effect of using --name, when you install w/o stopping the daemon first the entry in /var/proc changes name to "transmission-daemon (deleted)" so start-stop-daemon will not find it by name. In that case, what I do is use a "killall transmission-daemon". I been trying to work out a better solution for the script, that's why I used --exec and --name together but obviously it doesn't work... a simple solution is just using the real pid obtained using pidof or pgrep. Something like: --- /usr/local/portage/net-p2p/transmission/files/transmission-1.5x 2009-02-27 18:43:18.000000000 -0600 +++ transmission-1.5x 2009-03-02 17:57:45.000000000 -0600 @@ -7,6 +7,7 @@ NAME=transmission-daemon DAEMON=$(which $NAME) +PID=/var/run/$NAME declare -a OPTIONS OPTIONS+=" -a ${TR_ACL:=127.0.0.1}" @@ -80,8 +81,10 @@ stop() { ebegin "Stopping transmission daemon" + pidof $NAME > $PID start-stop-daemon --stop --quiet --retry=TERM/45/QUIT/15 \ - --exec $DAEMON --name $NAME + --pidfile $PID + && rm $PID eend $RETVAL }
Patched it and: /etc/init.d/transmission: line 87: syntax error near unexpected token `&&' /etc/init.d/transmission: line 87: ` && rm $PID' [ ok ] /etc/init.d/transmission: line 87: syntax error near unexpected token `&&' /etc/init.d/transmission: line 87: ` && rm $PID'
Sorry, the "&&" should be at the end of the line above : --- transmission.orig 2009-02-28 01:24:41.000000000 -0600 +++ transmission 2009-03-03 11:27:06.000000000 -0600 @@ -7,6 +7,7 @@ NAME=transmission-daemon DAEMON=$(which $NAME) +PID=/var/run/$NAME declare -a OPTIONS OPTIONS+=" -a ${TR_ACL:=127.0.0.1}" @@ -80,8 +81,9 @@ stop() { ebegin "Stopping transmission daemon" - start-stop-daemon --stop --quiet --retry=TERM/45/QUIT/15 \ - --exec $DAEMON --name $NAME + pidof $NAME > $PID + start-stop-daemon --stop --quiet --retry TERM/45/QUIT/15 \ + --pidfile $PID && rm $PID eend $RETVAL } I also changed the stop line, I think the way I was using retry (with an equals instead of a space) is the cause of start-stop-daemon not waiting for the daemon to end.
Now it does stop and everything, except for this little bit: * Stopping transmission daemon... rm: cannot remove `/var/run/transmission-daemon': No such file or directo [ ok ]
(In reply to comment #58) > Now it does stop and everything, except for this little bit: > > * Stopping transmission daemon... > > rm: cannot remove `/var/run/transmission-daemon': No such file or directo [ ok > ] Weird, lets change that part to 'rm -f $PID'. Thanks for the feedback. I'll upload a corrected script.
Created attachment 183965 [details] init.d script Corrected init.d script.
New script no longer works: * Stopping transmission daemon... /etc/init.d/transmission: line 84: $PID: ambiguous redirect start-stop-daemon: option '--pidfile' requires an argument Usage: start-stop-daemon [options] The old one except for that cannot remove line did the job.
Created attachment 184188 [details] init.d script Sorry (again), this time is _really_ a corrected script.
Yup- thanks for your efforts. This one finally works wonderfully. :)
The new init.d and conf.d have been incorporated into funtoo: http://github.com/funtoo/portage/commit/9474acdc730b29e83e6e0ec1def3010cddf37b67 Thanks for the fixes! -Daniel
Here at least they stopped working with 1.52 and 1.60.
(In reply to comment #65) > Here at least they stopped working with 1.52 and 1.60. Could you be more explicit? I haven't seen a problem in those versions, other than the (minor) bugs in Transmission itself, and that the init.d script should either wait more for transmission to stop or use a KILL (unnecessary since T takes a long time to stop because it writes the state for each torrent so the time is variable and it stops eventually).
The settings in the conf.d files are not used anymore for some reason. I had to edit the script itself to make it work. Also it seems the -B and -b for enabling/disabling the blocklist should be reversed.
(In reply to comment #67) > The settings in the conf.d files are not used anymore for some reason. I had to > edit the script itself to make it work. Also it seems the -B and -b for > enabling/disabling the blocklist should be reversed. Thanks for your reply. Let's try to sort this out: - conf.d files?? it should be only one file, not files, it is sourced by the init.d script so nothing really special is going on here, just keep the correct name: transmission; - Blocklist, I don't know if you intended it on your message but you put the inverse order -B is disable, -b enable; that's what the the init.d script does, disable if the option is undefined or set to "no"; I've seen something like you describe with encryption, I have it in the options as tolerated but the daemon is often running with it as required; I'm not sure what is happening here, haven't really checked. There are other, new options in the latest release of Transmission, a watchdir for the daemon for instance, I've added them to my installation but I don't know if it is interesting to publish them here anymore, since now Gentoo seems to update its own portage distribution in pace with T releases (my guess is that if there are users that want to add options to the daemon they are either modifying settings.json or the init.d script itself for things like running the daemon using a user different than root).
"files" was a typo- sorry. And I did not consider the order to associate the -b/Bs with enable,disable. I saw their usage from transmission-daemon --help. It seemed your script was doing the opposite of enabling the blocklist with TR_BLOCK" = "yes". Perhaps the only setting it got from the conf.d/transmission file ? Beyond that it didnt use the user I set there, the download dir or anything else. And even with -b it did not actually block anything (checked) but I guess thats a transmission bug.
I would love to commit a working init script for 1.61 which is going stable now for security bug, but I don't really use the daemon myself and to be honest, I haven't got myself time to learn openrc -style init scripts properly. :-( Let's just say more simple it is, more easily i'd commit it. For now.
(In reply to comment #70) > I would love to commit a working init script for 1.61 which is going stable now > for security bug, but I don't really use the daemon myself and to be honest, I > haven't got myself time to learn openrc -style init scripts properly. :-( > > Let's just say more simple it is, more easily i'd commit it. For now. Version 1.61 appears to have a big bug on the Web client, 2 reports of it not allowing to add any torrent... so I would recommend not to upgrade for now. The init.d script posted here is complex because it adds a lot of enhancements: separates options from script (using /etc/conf.d/transmission), runs the daemon as nobody by default or user specified in options, puts configuration, work files, and downloads in /var/transmission/... by default, also configurable. The reason for all that stuff is in fact to make it easier on the regular user, by doing a complete sane installation, and the power-user who can tweak all the parameters/settings in one place.
(In reply to comment #71) > The init.d script posted here is complex because it adds a lot of enhancements: ssuominen could elaborate on this a bit more, but my guess is that the script is fairly unreadable and thus maintainable for someone who did not write the beast itself. I started a rewrite of your init script a while ago which was much more readable, and have no objections in sharing that. Functionality is based on available options as mentioned in 'transmission-daemon --help', being v1.61 as of today (so no missing features). I'll put it up here when it's finished (which should today or tomorrow).
Created attachment 191072 [details] transmission.initd for v1.61 My version of the init.d script. This version: - supports all commandline switches from v1.61 - is openrc compliant - supports running the daemon as a regular user - removes setting speed limits in conf.d file (you can configure this in the webinterface, and settings made there would 'mysteriously disappear' after a restart) - has hopefully a syntax that every moderate bash user can understand. @ssuominen: could you share your view on this (both the init script, and the way it should look like)?
Created attachment 191075 [details] transmission.confd for v1.61
I wanted some readability for maintainbility, don't get me wrong, I do appericiate all the work you have put into this. I've committed the last ones added here into 1.61-r1, tested them quickly and seems to work here (but no complex testing done). Thanks again guys. +*transmission-1.61-r1 (12 May 2009) + + 12 May 2009; Samuli Suominen <ssuominen@gentoo.org> + +transmission-1.61-r1.ebuild, +files/transmission-daemon.confd, + +files/transmission-daemon.initd: + New init.d and conf.d files wrt #238260, thanks to Tom Hendrikx, René + Berber, Sergey Dryabzhinsky and many others.
(In reply to comment #73) > Created an attachment (id=191072) [edit] > transmission.initd for v1.61 > > My version of the init.d script. This version: > - supports all commandline switches from v1.61 > - is openrc compliant > - supports running the daemon as a regular user > - removes setting speed limits in conf.d file (you can configure this in the > webinterface, and settings made there would 'mysteriously disappear' after a > restart) > - has hopefully a syntax that every moderate bash user can understand. Nice job, just a few comments : All options that use a directory should be written as: if [ -d "${watch_dir}" ]; then watch_dir_opt="--watch-dir ${watch_dir}" fi This makes sure the directory is there, probably print a warning if its not (not empty string and not a dir). Also it won't work without more quoting if one of the directories has one or more spaces (yeah I know, who uses spaces?). The hack of running the daemon in foreground so that --make-pidfile works might affect performance... I haven't measured, I just went around that. Finally there is one option that can't be set with the daemon parameters or on the Web client, peer exchange, no other choice than to call transmission-remote somewhere. And just to remind you: 1.61 doesn't play nice adding new torrents with the Web client... I'm not upgrading.
Would it be possible to get future enchancement as patch to the ones that are in Portage now? I'll check this bug again tomorrow (going sleeping) but it might be best to open a new bug for future changes and mark this as milestone. :-)
@ssuominen: great and thanks! @r.berber: - extra checks: I can add extra checks but they do not print any extra warnings, so without creating an extensive error checking mechanism in the init script (which is again unmaintainable) no points are gained here. Since you are correct about the lack of feedback about configuration errors, I've adapted the script to redirect it's output to a logfile, which can be reviewed for errors. - running the daemon in the fg is the way to go with s-s-d when a daemon does not behave like a regular daemon (i.e. write pidfiles, logfiles, etc). I don't care about performance, we all want a working init script here, so I've focused on that. Please bug upstream when you want a binary with *real* daemon features :) - peer-exchange setting: I'm no real power user so I'm not aware of this feature, but it seems that when setting this option on startup is a valid thing to do, you could ask upstream to add it as a startup switch. The hack with calling transmission-remote is way too fragile for an init script, imho. Also, real power users know how to set these things manually. @all: since I don't use even half of the options provided by the script myself, some more testing would be nice. The latest version with som bugfixes, and addition of logfile feature is in a new bug as requested: #269655.
i was looking for a way to get transmission-daemon running as something other than root and just looking at the conf.d file, one gets the impression that's only possible by using openrc. below is URL to a custom init script that uses start-stop-daemon --chuid, i put that in and it works. worthy suggestion for ebuild improvement? http://forum.transmissionbt.com/viewtopic.php?f=1&t=6017
(In reply to comment #79) > i was looking for a way to get transmission-daemon running as something other > than root and just looking at the conf.d file, one gets the impression that's > only possible by using openrc. > > below is URL to a custom init script that uses start-stop-daemon --chuid, i put > that in and it works. worthy suggestion for ebuild improvement? > > http://forum.transmissionbt.com/viewtopic.php?f=1&t=6017 Its already done. If you want to specify another user, just edit the conf.d file and restart. Be aware that the user that runs the daemon also owns the files, so when you change users also check directory and file permissions and change them if needed. I see that the last conf.d file on this thread is not the one I submitted, which I think was better documented. Just look at the last line of the file, it has a runas_user option.
thanks for the info, i have transmission 1.72 installed which has this in conf.d: # Run daemon as another user (username or username:groupname) # (Note: works only on systems with sys-apps/openrc, leave unset otherwise) #runas_user= and code in init.d behaves accordingly. there is a chance this is a rollover from an older version i had (1.3x), the attachments here are different (start-stop-daemon --user). sorry for the confusion.
(In reply to comment #81) > thanks for the info, i have transmission 1.72 installed which has this in > conf.d: > > # Run daemon as another user (username or username:groupname) > # (Note: works only on systems with sys-apps/openrc, leave unset otherwise) > #runas_user= I don't know what the comment about openrc means, it seems wrong to me since I don't have openrc and changing the user has worked fine for a long time (with a lot of different versions); besides the real point is: start-stop-daemon is stock Gentoo and supports changing the user, nothing else is needed. > and code in init.d behaves accordingly. there is a chance this is a rollover > from an older version i had (1.3x), the attachments here are different > (start-stop-daemon --user). sorry for the confusion. If you mean your current script doesn't work as intended you can change it, try the one from Tom Hendrikx (which I don't use) or mine with the corresponding conf.d file.
hi again guys, my init script is not able to reliably stop transmission-daemon (1.72). stop() { ebegin "Stopping transmission daemon" start-stop-daemon --stop --quiet --retry TERM/45/QUIT/15 \ --pidfile ${pidfile} eend $? } looking at the operation, it definitely doesn't wait 45 or 15 seconds. rather it returns in about 3-5 seconds displaying [!!]. then after a while transmission-daemon goes down, so i'm guessing the signal gets sent. i would obviously much rather have the script wait until transmission-daemon is gone from the process list before returning. looking at comment #52+, it would appear this should be solved, but it just doesn't work here.
i have 1.75 and can report issues similar to kraav's
