Thx,
Janos

the http://wd.mirmana.com/ site is down. :-((( Can anyone let me have the content (S90transmission, trans_watchdog)? I just managed to get NTFS support for my added 2 TB, but managed to loose all my scripts and settings by not properly backing up before the firmware upgrade… Ouch.
Also, I am just curious, what would be the "canon" way of running transmission? An Optware install does not provide init.d scripts (nor a clear description of what one needs to do). If one of us is enthusiastic enough, it would be great to create a wiki page there (at transmissionbt.com) with a full howto (latest version is 2.11 by now).

Cheers,
Janos

This watchdog wasn't meant as a serious project and I wrote it for myself in the 1st place.
I can recommend Examdiff to load your current version and the new version and look at the code to see what I've done with it…..

I didn't add any main features and all work I've done had to do with portability, sanity checks and bug fixes……..

You can also take a look at the new mkdvd, mvmovie and S90transmission where I also changed some code…

In mvmovie I try to detect TV-series and put them in a proper directory…..

I'm considering to change all variables with some prefix and just save these variables instead of this "intelligent" way.

Edit: I guess I'll have to wait, it seems the server that file is on is down..

Edit2: server came back, and I got it, no change, but, I think it may have something to do with bash.

Edit3: Seems my config file got set back to defaults, but, it wasn't complaining about not finding the correct directories… I think I have it fixed now.

Edit4: it seems bash from ipkg doesn't play well with trans_watchdog, I removed it, and now the script seems to be running better, and no more <defunct>

Maybe it can be done with the optware cron

I had to run another eventlogger to surpress these messages (syslog-ng).
I can't give you an exact howto as I did this a year ago and had to do some research before..

In /etc/inittab you have to disable the normal syslogd
#::respawn:/sbin/syslogd -s 400 -n -m 0
#::shutdown:/usr/bin/killall syslogd

and install with ipkg install syslog-ng a new one in optware…
I have this config for it:
cat /opt/etc/syslog-ng/syslog-ng.conf

# # Syslog-ng example configuration for for NSLU2 Unslung 3.x # # Copyright (c) 1999 anonymous # Copyright (c) 1999 Balazs Scheidler # $Id: syslog-ng.conf 5159 2007-01-12 20:37:44Z fcarolo $ # # Syslog-ng configuration file, compatible with default Debian syslogd # installation. # options { long_hostnames(off); sync(0); }; source src { pipe("/proc/kmsg");unix-stream("/dev/log"); internal(); }; source net { udp(); }; destination authlog { file("/var/log/auth.log"); }; destination syslog { file("/var/log/syslog"); }; destination cron { file("/var/log/cron.log"); }; destination daemon { file("/var/log/daemon.log"); }; destination kern { file("/var/log/kern.log"); }; destination lpr { file("/var/log/lpr.log"); }; destination user { file("/var/log/user.log"); }; destination uucp { file("/var/log/uucp.log"); }; destination ppp { file("/var/log/ppp.log"); }; destination mail { file("/var/log/mail.log"); }; destination mailinfo { file("/var/log/mail.info"); }; destination mailwarn { file("/var/log/mail.warn"); }; destination mailerr { file("/var/log/mail.err"); }; destination newscrit { file("/var/log/news/news.crit"); }; destination newserr { file("/var/log/news/news.err"); }; destination newsnotice { file("/var/log/news/news.notice"); }; destination debug { file("/var/log/debug"); }; destination messages { file("/var/log/messages"); }; filter f_auth { facility(auth); }; filter f_authpriv { facility(auth, authpriv); }; #filter f_syslog { not facility(authpriv, mail, cron, user); }; filter f_cron { facility(cron) and not match("run-parts"); }; filter f_daemon { facility(daemon); }; filter f_kern { facility(kern); }; filter f_lpr { facility(lpr); }; filter f_mail { facility(mail); }; filter f_user { facility(user); }; #filter f_uucp { facility(cron); }; #filter f_ppp { facility(local2); }; filter f_news { facility(news); }; #filter f_debug { not facility(auth, authpriv, news, mail); }; filter f_messages { not facility(auth, authpriv, mail, news, cron) and not program(syslog-ng); }; filter f_emergency { level(emerg); }; filter f_info { level(info); }; filter f_notice { level(notice); }; filter f_warn { level(warn); }; filter f_crit { level(crit); }; filter f_err { level(err); }; log { source(src); filter(f_authpriv); destination(authlog); }; log { source(src); filter(f_messages); destination(messages); }; #log { source(src); filter(f_syslog); destination(syslog); }; log { source(src); filter(f_cron); destination(cron); }; #log { source(src); filter(f_daemon); destination(daemon); }; #log { source(src); filter(f_kern); destination(kern); }; #log { source(src); filter(f_lpr); destination(lpr); }; log { source(src); filter(f_mail); destination(mail); }; #log { source(src); filter(f_user); destination(user); }; #log { source(src); filter(f_uucp); destination(uucp); }; log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); }; log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); }; log { source(src); filter(f_mail); filter(f_err); destination(mailerr); }; log { source(src); filter(f_news); filter(f_crit); destination(newscrit); }; log { source(src); filter(f_news); filter(f_err); destination(newserr); }; log { source(src); filter(f_news); filter(f_notice); destination(newsnotice); }; #log { source(src); filter(f_debug); destination(debug); }; #log { source(src); filter(f_ppp); destination(ppp); };

getting a lot of this error, and still some of

May 17 07:35:07 MediaServe user.notice root: /usr/bin/trans_watchdog already running… this one will stop

when it's downloading… also, any idea how to suppress

May 17 07:37:01 MediaServe cron.notice crond[3010]: USER root pid 18466 cmd /usr/bin/trans_watchdog

I know it's running every minute as it should, so, I don't think it's necessary to fill messages up with these, is there some switch for cron that will prevent it from being logged?

Although I'm not sure if it really helps in any way.
I guess it doesn't hurt to block some IP's

I've seen some mails from, for instance Sony, claiming someone was downloading content of their copyrighted material. I doubt if such a blocklist prevents this, but hopefully it makes it less likely….

No torrents downloading, but about 27 seeding, and

May 14 22:19:02 MediaServe user.notice root: /usr/bin/trans_watchdog already running… this one will stop

has not shown up once in the last few hours, so, i would say you have definitely improved it, as it was happening all the time (almost every 5-10 minutes) before, even with 1 or 2 seeding torrents and no downloading torrents.

and, since I set a limit on global peers (-gpr) I have not had one single freeze, and the CPU/MEM usage has greatly reduced.

May 14 22:19:02 MediaServe user.notice root: /usr/bin/trans_watchdog already running… this one will stop

although, it seems to happen a bit less.

Edit: make that a lot less…

Made some more changes.
It executes transmission-remote less than before and doesn't continue when it left in an error-state.
This error-state is probably the reason why torrents are unwantedly removed…

In time I will look to transmissioncli

I hope thinks have settled down now (did do a lot of moving)

http://linux.die.net/man/1/transmissioncli

I see that you can specify a script to run on finish

-f, —finish script
Specifies a shell script to be executed upon successful download.

plus, some of the same settings you currently do with transmission-remote, I wonder if it would be useful to do some of the symlink stuff in this finish script, instead of your main script…

Edit: I just updated and now get this

May 14 07:02:01 MediaServe cron.notice crond[3010]: USER root pid 9161 cmd /usr/bin/trans_watchdog
May 14 07:02:02 MediaServe user.notice transmission: SOURCE directory /shares/internal/PUBLIC/Torrent/source does NOT exist, script will exit
May 14 07:03:01 MediaServe cron.notice crond[3010]: USER root pid 9190 cmd /usr/bin/trans_watchdog
May 14 07:03:02 MediaServe user.notice transmission: SOURCE directory /shares/internal/PUBLIC/Torrent/source does NOT exist, script will exit

It's not reading my config file, guess, but, I can't see any reason why. :(

Edit2: ran it from the CLI, maybe this is why:

/opt/etc/trans_watchdog.conf: line 34: unexpected EOF while looking for matching ‘’'
/opt/etc/trans_watchdog.conf: line 40: syntax error: unexpected end of file

but, I don't see any ' missing….

A DD-WRT router on which I was running the script as well behaved quite different and had to write some workarounds for that as well…

The program "transmission-remote" ran too often inside the script which slowed it down. Because writing this script is an evolutionary process it's quite normal to introduce these inefficiencies…

I hope you're having more success with the script now.

I will now change the code.
Hang on…

now, new business (I still haven't gotten the latest, yet, but, I'm sure this will still be an issue) This is actually old business, I just never bothered to say anything before, every so often, it seems the script takes more than a minute to finish, or something.

May 13 12:54:01 MediaServe cron.notice crond[3010]: USER root pid 12430 cmd /usr/bin/trans_watchdog
May 13 12:55:01 MediaServe cron.notice crond[3010]: USER root pid 12529 cmd /usr/bin/trans_watchdog
May 13 12:55:07 MediaServe user.notice transmission: /usr/bin/trans_watchdog already running… this one will stop
May 13 12:56:02 MediaServe cron.notice crond[3010]: USER root pid 12648 cmd /usr/bin/trans_watchdog

like so. I have run it from the CLI many times, and it never takes more than a few seconds to complete, any idea what could be happening?

Edit: Also, is this supposed to be broken up like this? (I know nano will do this if you are editing a long line, and it is very infuriating)

(I had to add this line to allow it to indent properly in this codebox) echo "From: <${MAILFROM}> To: <${MAILTO}> Subject: ${IP}: ${TORRENTNAME} torrent finished " > ${TMPINFO} cat ${INFO} >> ${TMPINFO}

If transmission is bringing your worldbook down, you have to blame transmission itself, really.

I do hope you can run the modified script now.
Please tell me what you like to have changed so you don't need to edit it.

I also have to take care the script doesn't take up too many resources itself.
Especially the first bit shouldn't take too much as it runs every minute…

Because I need both values (handling and downloading), I added an extra line for HANDLING a bit further in the script.
That part only runs every 5 minutes and not every minute.

When the script fills in the value for ${Downloading} (or ${Handling}) it stays the same for the rest of the code, which means this:

 do NEW_NAME=`echo "$TORRENTNAME" | sed -e 's/\x1b\[[0-9]\{1,2\}\(;[0-9]\{1,2\}\)$ if [ ! "${TORRENTNAME}" == "${NEW_NAME}" ] ; then mv "${TORRENTNAME}" "${NEW_NAME}" _logger "I renamed Torrent: ${TORRENTNAME} to ${NEW_NAME}" TORRENTNAME="${NEW_NAME}" fi if [ ${DOWNLOADING} -lt ${MAX_SIMULTANEOUS} ]; then $TRANSREMOTE -a "${TORRENTNAME}" >/dev/null if [ "${?}" -eq "0" ] ; then _logger "Added the Torrent: ${TORRENTNAME} to transmission" # rm -f "${TORRENTNAME}" mv "${TORRENTNAME}" "${TORRENTNAME}.transmission" fi fi else debug "Did not add ${TORRENTNAME}, because the limit of ${MAX_SIMULTANEOUS}$ fi done

Edit: OK, I see that later in the script it shuts down transmission if there are no active files, which is why it needs all active files, and not just the downloading files, so, I added (I haven't downloaded the new script, yet) HANDLING=your original line and left DOWNLOADING=my line and use DOWNLOADING to figure out whether or not to add a new download (with the let "DOWNLOADING++" I mentioned inside the do loop) and changed the name of the other ones to HANDLING, so, it works as you expected. I also think that setting -gpr as I mentioned earlier is really helping, I'm downloading more than one torrent without it freezing, whereas, it was freezing with just one download going before. so, maybe that should be added as another option in the conf, with either 0 or -1 as unlimited.

Edit2: Of course, HANDLING should be increased when you add a new one as well.

Edit: http://linux.softpedia.com/progChangelog/Transmission-Changelog-4856.html <-1.60 added a watch directory natively, and some other changes were added in other revisions that might be useful in your script, such as seed ratio limiting natively.

May 13 07:02:01 MediaServe user.notice transmission: Removed symbolic link Name.Of.File.avi because it was removed from transmission

it wasn't, I just shutdown transmission using the K10 script. what is even stranger is I had already removed the watchdog script from crontabs before this, meaning it was still run somehow…

And, yes, it is about reporting, it is about reporting to a part of the script later how many downloads are currently running, so it can either do nothing, or add another, before, it was reporting all files, not just the ones downloading.

And, yes, it was removing seeding tasks before I touched the script.

As far as making changes in /etc/trans_watchdog.conf or /opt/etc/trans_watchdog.conf, there is no way to change what I changed there.

and, yes, I installed all of the dependencies.

The ENTIRE reason I was editing the script is because it was freezing up with the unmodified script.

May 13 07:01:54 MediaServe user.warn kernel: transmission-da: page allocation failure. order:1, mode:0x20 May 13 07:01:54 MediaServe user.warn kernel: Mem-info: May 13 07:01:54 MediaServe user.warn kernel: DMA per-cpu: May 13 07:01:54 MediaServe user.warn kernel: cpu 0 hot: high 6, batch 1 used:5 May 13 07:01:54 MediaServe user.warn kernel: cpu 0 cold: high 2, batch 1 used:1 May 13 07:01:54 MediaServe user.warn kernel: DMA32 per-cpu: empty May 13 07:01:54 MediaServe user.warn kernel: Normal per-cpu: empty May 13 07:01:54 MediaServe user.warn kernel: HighMem per-cpu: empty May 13 07:01:54 MediaServe user.warn kernel: Free pages: 1016kB (0kB HighMem) May 13 07:01:54 MediaServe user.warn kernel: Active:3435 inactive:1053 dirty:93 writeback:0 unstable:0 free:254 slab:2329 mapped:3303 pagetables:95 May 13 07:01:54 MediaServe user.warn kernel: DMA free:1016kB min:724kB low:904kB high:1084kB active:13740kB inactive:4212kB present:32768kB pages_scanned:0 all_unreclaimable? no May 13 07:01:54 MediaServe user.warn kernel: lowmem_reserve[]: 0 0 0 0 May 13 07:01:54 MediaServe user.warn kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no May 13 07:01:54 MediaServe user.warn kernel: lowmem_reserve[]: 0 0 0 0 May 13 07:01:54 MediaServe user.warn kernel: Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no May 13 07:01:54 MediaServe user.warn kernel: lowmem_reserve[]: 0 0 0 0 May 13 07:01:54 MediaServe user.warn kernel: HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no May 13 07:01:54 MediaServe user.warn kernel: lowmem_reserve[]: 0 0 0 0 May 13 07:01:54 MediaServe user.warn kernel: DMA: 220*4kB 1*8kB 0*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB = 1016kB May 13 07:01:54 MediaServe user.warn kernel: DMA32: empty May 13 07:01:54 MediaServe user.warn kernel: Normal: empty May 13 07:01:54 MediaServe user.warn kernel: HighMem: empty May 13 07:01:54 MediaServe user.warn kernel: Swap cache: add 6546, delete 5328, find 1360/2056, race 0+0 May 13 07:01:54 MediaServe user.warn kernel: Free swap = 94692kB May 13 07:01:54 MediaServe user.warn kernel: Total swap = 104312kB May 13 07:01:54 MediaServe user.warn kernel: Free swap: 94692kB May 13 07:01:54 MediaServe user.warn kernel: 8192 pages of RAM May 13 07:01:54 MediaServe user.warn kernel: 400 free pages May 13 07:01:54 MediaServe user.warn kernel: 691 reserved pages May 13 07:01:54 MediaServe user.warn kernel: 2329 slab pages May 13 07:01:54 MediaServe user.warn kernel: 2917 pages shared May 13 07:01:54 MediaServe user.warn kernel: 1218 pages swap cached

transmission-remote -l 2>/dev/null | grep -v "ETA " |grep -v "^Sum:" | wc -l

If anything is wrong there, it's only the poor choice of naming the variable "DOWNLOADING"
I changed it to "HANDLING"… This doesn't effect the behaviour.

HANDLING=`${TRANSREMOTE} -l 2>/dev/null | grep -v "ETA " | grep -v "^Sum:" | wc -l`

I see now why the 2 is there, it's not a typo… :) but, I added | grep -v "Done " after | grep -v "ETA " and it looks like it properly reports the correct number now.

It's not about reporting at all.
The program should be running as a cronjob and its output is not that important (more for debugging)

I'm still noticing a lot of torrents getting removed before they should be, might be related to the freezes, and having to unplug it and start it up again, but, it's rather annoying, and killing my ratio…

Please run the unmodified script and tell me if it's still doing it.

If you want to change parameters, you should do this in /etc/trans_watchdog.conf or /opt/etc/trans_watchdog.conf
Also check if you installed findutils and other programs in optware (mentioned in header)

 transmission-remote -l 2>/dev/null | grep -v "ETA " |grep -v "^Sum:" | wc -l

to return number of downloads, I see two things wrong, first (and very minor, makes no real difference) that 2 must be a typo, second, it counts all torrents as downloading, even if they are actually done and are only seeding… I think it would be better to check the Done column instead, and ignore any that are 100%, or ignore ones in the ETA column that say Done….

Edit: I see now why the 2 is there, it's not a typo… :) but, I added | grep -v "Done " after | grep -v "ETA " and it looks like it properly reports the correct number now.

Edit2: Maybe another check could be done to limit the number of seeding/idle torrents as well.

Edit3: I'll tell you what, though, if the MB is going to keep locking up, I might scrap this whole thing and either go back to running utorrent on my PC and set the download directories to the MB, or find an old computer to install Linux on (in fact, I already have an iMac I installed Ubuntu on, and don't really use….) and install transmission and this script on there, making any modifications I need to for it to run.

Please update your scripts and manually clean up the work directory and target directory… !

I'll update and check out the new script when I get a chance.

please test

I will however incorporate the code with MAX_SIMULTANEOUS….

MAX_SIMULTANEOUS is implemented (please test)

I have added QUIT_TRANSMISSION_WHEN_INACTIVE, but it will probably turn transmission on and off all the time…. (quick and dirty implementation)
Have to think of a procedure to prevent that.

upgraded.

I was looking at another script that works similar to yours, and saw a few things you might consider adding, such as

1. how many torrents should be downloading at the same time
2. recommended to keep this at 1, since mbwe does have so little memory and so slow cpu

MAX_SIMULTANEOUS=1

and

1. whether or not to quit transmission, if there are no torrents in the queue.
2. if quit, it will be restarted when something is found in the watch directory
3. if you're planning on adding torrents also by other means (with clutch, for example)
4. than using the watch directory, set this to 0

QUIT_TRANSMISSION_WHEN_INACTIVE=1

How was your transmission behaving in that situation?

BTW…. You should try an ipkg update / ipkg upgrade…. A lot has been updated and transmission_1.52-1 is one of them.

Edit: remove a mistaken conclusion….

Can you give some feedback on how my script in general can be implemented now and how it's running?

Edit: dos2unix seems to have done it, thanks.

You can also enclose it between double quotes..
But why the preference for these strange characters?

If nothing helps you should delete the config file and afterwards edit it with vi to modify the parameters….

the SOURCE directory is actually /shares/internal/JUNK/Torrent_Temp/!!!AutoGetTorrents (I also tried /shares/internal/JUNK/Torrent_Temp/\!\!\!AutoGetTorrents) seems to be getting cut off for some reason.

The other errors are from lines 132 and 134 as the error points out, but, I don't know what the problem is.

SOURCE
WORK
TARGET

I guess you're not using the structure

/source
/work
/target

RUN_AFTER_MOVE was not working somehow (although I'm not sure about that) so I deleted it.

FILE_AGE is not a config-var but is calculated
RATIO is not a config-var but is calculated

SOURCE=
WORK=
TARGET=
RUN_AFTER_MOVE=
FILE_AGE=1
RATIO=1

They are all in the script, and I may be misunderstanding the last 2, but, the first three are critical for me…

I didn't really get any wiser googling for a best practice for my config-file, so I "invented" my own way of doing it.

As I wrote it, I can still introduce new variables without getting an error.
If things really don't work as expected one can still kill the config file which is written to /etc/trans_watchdog.conf or /opt/etc/trans_watchdog.conf (or optionally another file using "-c" trans_watchdog -c /opt/etc/trans_watchdog.conf)

I had some problems with the array-variable which couldn't be handled like any other variable as it turned out….
But everything is working now!!

Edit: Oh, wait, that's in the part of the script that runs every 5 minutes, guess I need to wait to see…

Edit: Yes, it did work, eventually.

I was just wondering, if I remove a file from the webif of transmission, will trans_watchdog remove the sym link for it on the next run?

I guess I'll try that now…

Edit: looking through the script, I see you have already thought of that :)

I used to be a fulltime programmer (self-taught) and I just recently started doing shell-scripts.

As an example..
The code using "top" to determine if a process is busy can't be found on the net and is my own "invention".
AFAIK it gives more reliable info than other examples that are doing the same thing…

I wanted to do a full cleanup of the code, but it just isn't as rewarding as new features.
Now the script is getting more and more ugly…..

Hang on for an update….