rtorrent

[michael123]

..bubbaRaid looks like nice solution and many people are using it here, but I really need to be up-to-date with the lime OS.

Last betas improved performance, and I also hope Tom will incorporate some decent power management into unRaid suite

 

[flixxx]

..bubbaRaid looks like nice solution and many people are using it here, but I really need to be up-to-date with the lime OS.

Last betas improved performance, and I also hope Tom will incorporate some decent power management into unRaid suite

 

 

Hey Michael, if you're still having problems try the following;

 

open rtorrent regularly and exit it.

 

Look for rtorrent.rc:

 

cd /
find -name rtorrent.rc

 

Wherever it finds it, I would make a copy of it in your boot. This is your rtorrent configuration file. If you don't have one it will either default to one everytime you reboot or it may not work at all under screen.

 

cp [i]wherertorrent.rcis/rtorrent.rc[/i] /boot

 

Next up, you will want to start rtorrent and point to the location of your configuration file.

 

replace:

 

/usr/bin/screen -T linux -dmUS rtorrent /usr/bin/rtorrent

 

with:

 

/usr/bin/screen -dmS rtorrent /usr/bin/rtorrent -n -o import=/boot/rtorrent.rc

 

Get rid of this from your go script:

 

# Make symbolic link of rtorrent.rc
ln -s /boot/rtorrent.rc /root/.rtorrent.rc

 

After the screen, you will need to make a symbolic link. I don;t know why, but .screen gets created in a different folder then when you look for it so add the following code:

 

sleep 5
ln -s /.screen /root/

 

Let me know how all this turns out.

 

[PhoenixNZ]

Hey all, just been reading, and reading, and ... you get the drift.

 

Found Unraid to be just what I'm after.  Set up and all, working sweet.  Tried Bubbaraid for rtorrent, but found private tackers not working (older version of rtorrent).

 

I'd like to setup rtorrent, with rutorrent front end, but I'm a complete noob to Linux, commands and everything,  last thing I learnt was DOS.

 

SO, Big Ask,  can anyone typeout a step-by step instructions for setting up unweb, rtorrent with librarys, and get it to start with rutorrent web interface.

 

I can follow instructions and aren't complete incompetent, but reading so much about all of this, my brain feels abit like noodle soup, everythings swirling around together.

 

So, any help with this would be greatly appreciated.

[michael123]

..bubbaRaid looks like nice solution and many people are using it here, but I really need to be up-to-date with the lime OS.

Last betas improved performance, and I also hope Tom will incorporate some decent power management into unRaid suite

 

 

Hey Michael, if you're still having problems try the following;

 

open rtorrent regularly and exit it.

 

Look for rtorrent.rc:

 

cd /
find -name rtorrent.rc

 

Wherever it finds it, I would make a copy of it in your boot. This is your rtorrent configuration file. If you don't have one it will either default to one everytime you reboot or it may not work at all under screen.

 

cp [i]wherertorrent.rcis/rtorrent.rc[/i] /boot

 

Next up, you will want to start rtorrent and point to the location of your configuration file.

 

replace:

 

/usr/bin/screen -T linux -dmUS rtorrent /usr/bin/rtorrent

 

with:

 

/usr/bin/screen -dmS rtorrent /usr/bin/rtorrent -n -o import=/boot/rtorrent.rc

 

Get rid of this from your go script:

 

# Make symbolic link of rtorrent.rc
ln -s /boot/rtorrent.rc /root/.rtorrent.rc

 

After the screen, you will need to make a symbolic link. I don;t know why, but .screen gets created in a different folder then when you look for it so add the following code:

 

sleep 5
ln -s /.screen /root/

 

Let me know how all this turns out.

 

 

thanks for your time answering me, indeed.

I did manage to setup rtorrent to run manually, though.

But I am not really satisfied to work with screen/telnet interface after getting used to utorrent.

I tried to install web interface, but something crashed inside the web listener every time..

Besides, I thought afterwards that running power-hungry Lime machine for torrent is not wise.

I will likely continue to run rtorrent on my laptop for a while.. and then copy to Lime once finished.

Lime will sleep for most of its time when not used.

[flixxx]

..bubbaRaid looks like nice solution and many people are using it here, but I really need to be up-to-date with the lime OS.

Last betas improved performance, and I also hope Tom will incorporate some decent power management into unRaid suite

 

 

Hey Michael, if you're still having problems try the following;

 

open rtorrent regularly and exit it.

 

Look for rtorrent.rc:

 

cd /
find -name rtorrent.rc

 

Wherever it finds it, I would make a copy of it in your boot. This is your rtorrent configuration file. If you don't have one it will either default to one everytime you reboot or it may not work at all under screen.

 

cp [i]wherertorrent.rcis/rtorrent.rc[/i] /boot

 

Next up, you will want to start rtorrent and point to the location of your configuration file.

 

replace:

 

/usr/bin/screen -T linux -dmUS rtorrent /usr/bin/rtorrent

 

with:

 

/usr/bin/screen -dmS rtorrent /usr/bin/rtorrent -n -o import=/boot/rtorrent.rc

 

Get rid of this from your go script:

 

# Make symbolic link of rtorrent.rc
ln -s /boot/rtorrent.rc /root/.rtorrent.rc

 

After the screen, you will need to make a symbolic link. I don;t know why, but .screen gets created in a different folder then when you look for it so add the following code:

 

sleep 5
ln -s /.screen /root/

 

Let me know how all this turns out.

 

 

thanks for your time answering me, indeed.

I did manage to setup rtorrent to run manually, though.

But I am not really satisfied to work with screen/telnet interface after getting used to utorrent.

I tried to install web interface, but something crashed inside the web listener every time..

Besides, I thought afterwards that running power-hungry Lime machine for torrent is not wise.

I will likely continue to run rtorrent on my laptop for a while.. and then copy to Lime once finished.

Lime will sleep for most of its time when not used.

 

Check out RUTorrent, you will be pleasantly surprised. It's an interface for rtorrent and looks exactly like utorrent.

 

Phoenixz: I will soon write up a tutorial on how to install and configure unraidweb/rtorrent/rutorrent. I can't give an ETA so in the meantime you can experiment.

[PhoenixNZ]

 

Check out RUTorrent, you will be pleasantly surprised. It's an interface for rtorrent and looks exactly like utorrent.

 

Phoenixz: I will soon write up a tutorial on how to install and configure unraidweb/rtorrent/rutorrent. I can't give an ETA so in the meantime you can experiment.

 

Hey flixxx

 

That tutorial would be of great help.

 

I've been trying with bubbaQ's unweb package  http://lime-technology.com/forum/index.php?topic=3354.0  (couldn't get his xp installer to work) use wget to retrieve and install it, even got it to install from the 'go' file, then got the rtorrent file from 'boof''s first post, um, got confused, so thought I'd get the rutorrent files following your message http://lime-technology.com/forum/index.php?topic=4303.msg38089#msg38089.

 

Couldn't extract with tar, chucked up a few errors, so copied to pc, unzipped it, but it into 'wwwdocs' folder.

 

Finally, thought, ok, get bubbaQ's web server to point to /mnt/disk1/wwwdocs/  on port 83.  This should work, yeah, Right!

 

I know I haven't extracted rtorrent as don't know where to put it, or how to start it.

 

So, this much I have tried.  I'm sure I stuffed-up numerous times, and thinking of it, probably extracting rutorrent files on the pc changed the permissions, but I'm a complete noob to linux commands.

 

As I said, I can follow instructions, and I can figure out what they mean and probably do, but getting out of trouble is I caused is my weakness.

 

Any help would be greatly appreciated.

 

PS:  would it be best if I go to the latest beta11 release?  currently on 4.4.2 stable.

 

Cheers 

[BLKMGK]

[quote author=flixxx

 

Check out RUTorrent, you will be pleasantly surprised. It's an interface for rtorrent and looks exactly like utorrent.

 

Phoenixz: I will soon write up a tutorial on how to install and configure unraidweb/rtorrent/rutorrent. I can't give an ETA so in the meantime you can experiment.

 

I look forward to this as well! RUtorrent souonds nice!

[Torquewrench]

I just documented my install of blockcontrol, rtorrent and rutorrent onto my full slackware install unRAID installation and I'll be posting it in the next few days. I agree, ruTorrent is the best web interface to rTorrent I've used so far.

 

Phil/TW

[PhoenixNZ]

Hey Phil/TW

 

Just had to google the definition of 'slackware', that's how much of a noob I am to linux.  It looks like a small linux OS and you've put unraid with it?  is that about it?  or is Unraid booting first and launching 'slackware' linux OS?

 

Sorry to be so green on these topics.

 

Rob

[BRiT]

unRAID is a combination of custom LimeTech software installed on top of a very minimal base Slackware Linux Distribution with some configuration tweaks to the Linux configuration.

 

What power users have done is to take the custom LimeTech software and install it on top of a full Slackware Linux Distribution.

[PhoenixNZ]

unRAID is a combination of custom LimeTech software installed on top of a very minimal base Slackware Linux Distribution with some configuration tweaks to the Linux configuration.

 

What power users have done is to take the custom LimeTech software and install it on top of a full Slackware Linux Distribution.

 

Does this reduce the startup time of unraid? or the advantages out weigh the minor time difference?

 

I'm pretty much just want to set up a NAS box with torrent.  I have an Acer Easystore NAS (Pre WHS) unit already, but had difficulty installing the funplug patch to allow torrent, and with Unraid, I can set up just a simple NAS for torrent downloading, and transfer to my Acer.  Simple is good

[Joe L.]

unRAID is a combination of custom LimeTech software installed on top of a very minimal base Slackware Linux Distribution with some configuration tweaks to the Linux configuration.

 

What power users have done is to take the custom LimeTech software and install it on top of a full Slackware Linux Distribution.

 

Does this reduce the startup time of unraid? or the advantages out weigh the minor time difference?

 

I'm pretty much just want to set up a NAS box with torrent.  I have an Acer Easystore NAS (Pre WHS) unit already, but had difficulty installing the funplug patch to allow torrent, and with Unraid, I can set up just a simple NAS for torrent downloading, and transfer to my Acer.  Simple is good

Stripping the un-needed portions of Slackware is to reduce the size of the resulting distribution, not to reduce start-up time.  There is no "windowing" graphical interface, there are a minimal number of network card drivers, enough to support the most common Gigabit LAN chipsets, and suport for the most common (but not all) IDE and SATA chipsets.  there is no "printing" support, or "mail".  Nor are there any tools or utilities to play music files, and no sound-card drivers.  The only driver that can make a sound is the "beep' driver for the motherboard speaker.  None of the compile utilities and tools are present.

 

The original unRAID was distributed on a 128meg flash drive, and it still fits and can be run from a 128meg flash drive (although I doubt you'll be able to find one that small for sale very easily these days)

 

Since most of the utilities and programs and packages developed to work on the Slackware release of Linux can be added to unRAID, experienced users can extend unRAID as they desire. (many of us have)  Very experienced users can install a full Slackware OS, then overlay it with the "md" driver (multi-disk) from unRAID, then compile and configure a cross between them that has all the missing pieces of full Slackware.  Since most people do not have any need to create a development environment for compiling programs, most do not.

 

unRAID has no built in "torrent" client, but there have been instructions posted on how to add one.    If you had problems adding an add-on patch previously on a different OS, you may find it difficult under unRAID too.    You'll need to read the forum and judge for yourself.  Most people who have created add-ons have made many posts helping others get configured.

 

You can think of unRAID as Slackware 12.2, minus all the graphical interface, minus sound, minus printing capability, minus wireless capability, minus compile utilities, minus perl, minus the "md" (multi-disk RAID) driver, minus the apache web-server, php, and perl.

Then, added to what is left is an alternate "md" driver (unRAID's modified versions of RAID-4) and the proprietary shared file system driver written by lime-technology, and the management interface/web-page, also proprietary to lime-technology.

 

Joe L.

[PhoenixNZ]

@Joe L.

 

Thanks for the info.

 

I thinks for me it would be best to stick with unraid, then add web server, rtorrent and get rutorrent working.  I have read alot of info and as I posted earlier, attempted and failed

 

I have used BubbaQ's addon and this works nicely except for private trackers (as I read here the version in BubbaRaid is older).

 

Hopefully Flixxx or BLKMGK will post a guide soon and I'll be on my way.

 

PS:  it shouldn't matter that i have unraid running on an old 3.2G Hard Drive instead of a Flash Drive?  My MBoard I'm currently using doesn't support boot from FLash.  I had thought about getting a CF Adapter card and using this, but as most people who tinker with computers I have acculimated many small drives not much use for anything now.

[flixxx]

I just posted a tutorial:

 

http://lime-technology.com/forum/index.php?topic=4827.msg44278#msg44278

 

[henris]

Is there any downside letting rtorrent run on the local terminal of the UnRAID server (ie. without screen)? I'm planning to utilise the watch-directories to control adding or removing torrents like I did in the past with Azureus in windows. My local terminal is basicly just sitting there totally unused. I guess the only thing I would be missing was the full remote control of rtorrent. But with proper settings the torrent downloading can be fully automatised and has no need for additional control. I have nothing against installing screen (or even rutorrent) but they just seem unnecessary for what I'm trying to accomplish.

 

Found this page describing the configuration possibilities and they seem sufficient for the job:

http://wiki.archlinux.org/index.php/RTorrent

[prostuff1]

Is there any downside letting rtorrent run on the local terminal of the UnRAID server (ie. without screen)? I'm planning to utilise the watch-directories to control adding or removing torrents like I did in the past with Azureus in windows. My local terminal is basicly just sitting there totally unused. I guess the only thing I would be missing was the full remote control of rtorrent. But with proper settings the torrent downloading can be fully automatised and has no need for additional control. I have nothing against installing screen (or even rutorrent) but they just seem unnecessary for what I'm trying to accomplish.

 

Found this page describing the configuration possibilities and they seem sufficient for the job:

http://wiki.archlinux.org/index.php/RTorrent

 

It is all personal preference.  Most people prefer to have some kind of GUI to look at, and rutorrent seems to be one of the best, if not the best, out there right now.  I also do some port triggering through my NAT router so that I can control rutorrent and rtorrent from anywhere.

[flixxx]

Is there any downside letting rtorrent run on the local terminal of the UnRAID server (ie. without screen)? I'm planning to utilise the watch-directories to control adding or removing torrents like I did in the past with Azureus in windows. My local terminal is basicly just sitting there totally unused. I guess the only thing I would be missing was the full remote control of rtorrent. But with proper settings the torrent downloading can be fully automatised and has no need for additional control. I have nothing against installing screen (or even rutorrent) but they just seem unnecessary for what I'm trying to accomplish.

 

Found this page describing the configuration possibilities and they seem sufficient for the job:

http://wiki.archlinux.org/index.php/RTorrent

 

There is nothing wrong with it persay, it's just that you'll need a screen attached ot it for any changes. You won't be able to start the session via telnet because the moment you close the telnet session it will terminate the program. If the server is next to yourm ain pc and u have a kvm, then by all means go ahead. In my case though my server is tucked away in a crawl space that never gets visited so screen is my best alternative.

[henris]

I reconsidered my position after the fifth time I had to go upstairs to restart the rtorrent client using the local terminal. I followed Flixxx's guide taking only the screen and rtorrent parts:

http://lime-technology.com/forum/index.php?topic=4827.0

 

It's now up and running persistently so I'm quite happy. I however came across the possibility to have the rtorrent run as a "real" daemon:

http://wiki.archlinux.org/index.php/RTorrent#rtorrent_Daemon_with_screen

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

case "$1" in
  start)
    stat_busy "Starting rtorrent"
    su rtorrent -c 'screen -d -m rtorrent' &> /dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      add_daemon rtorrent
      stat_done
    fi
    ;;
  stop)
    stat_busy "Stopping rtorrent"
    killall -w -s 2 /usr/bin/rtorrent &> /dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      rm_daemon rtorrent
      stat_done
    fi
    ;;
  restart)
    $0 stop
    sleep 1
    $0 start
    ;;
  *)
    echo "usage: $0 {start|stop|restart}"
esac
exit 0

 

I started to experiment with the given rc.d script but it was soon evident that the script was not compatible with UnRAID (or Slackware) and making it work was beyond my current skills. Could some of the more skilled users perhaps guide a blind man here?

[flixxx]

I reconsidered my position after the fifth time I had to go upstairs to restart the rtorrent client using the local terminal. I followed Flixxx's guide taking only the screen and rtorrent parts:

http://lime-technology.com/forum/index.php?topic=4827.0

 

It's now up and running persistently so I'm quite happy. I however came across the possibility to have the rtorrent run as a "real" daemon:

http://wiki.archlinux.org/index.php/RTorrent#rtorrent_Daemon_with_screen

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

case "$1" in
  start)
    stat_busy "Starting rtorrent"
    su rtorrent -c 'screen -d -m rtorrent' &> /dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      add_daemon rtorrent
      stat_done
    fi
    ;;
  stop)
    stat_busy "Stopping rtorrent"
    killall -w -s 2 /usr/bin/rtorrent &> /dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      rm_daemon rtorrent
      stat_done
    fi
    ;;
  restart)
    $0 stop
    sleep 1
    $0 start
    ;;
  *)
    echo "usage: $0 {start|stop|restart}"
esac
exit 0

 

I started to experiment with the given rc.d script but it was soon evident that the script was not compatible with UnRAID (or Slackware) and making it work was beyond my current skills. Could some of the more skilled users perhaps guide a blind man here?

 

I believe that would require to customize the kernel to include that script. I'm not sure, but what type of added bonus do you see by having an rtorrent Daemon?

[boof]

It looks to me it's largely doing the same sort of thing flixxx's setup does, the 'daemon' part is just creating an init script to auto start at boot time and be controlled by the service framework in arch linux?

 

No real benefit for unraid as there is no real service or rc structure (beyond the go script!) and, indeed, flixxx's setup is the direct equivalent.

[boof]

Thanks to flixxx's hardwork and with his permission to share, I've updated the first post with a more up to date version of rtorrent and libtorrent which are the most recent fruits of his ongoing quest for unraid and rtorrent perfection 

 

Thanks flixxx!

[henris]

I believe that would require to customize the kernel to include that script. I'm not sure, but what type of added bonus do you see by having an rtorrent Daemon?

I was mostly thinking about a nice and clean way of controlling the daemon through start, stop and restart. But as the rtorrent is gui and not cli based I think it does not benefit anything. For example stop might (I'm not a Linux expert but killall command sounds like forcing an application to shutdown) not shutdown rtorrent cleanly.

 

It looks to me it's largely doing the same sort of thing flixxx's setup does, the 'daemon' part is just creating an init script to auto start at boot time and be controlled by the service framework in arch linux?

 

No real benefit for unraid as there is no real service or rc structure (beyond the go script!) and, indeed, flixxx's setup is the direct equivalent.

I'm really on a thin ice on this one since I'm just entering the linux world but I tried to understand the linux startup script structure (rc.d, inittab etc.). At least on my 4.4.2 system there are proprietary run scripts in the /etc/rc.d directory, one of them is the rc.unRAID itself. They do have the start/stop/restart mechanisms builtin. Am I mixing things here?

[boof]

I was mostly thinking about a nice and clean way of controlling the daemon through start, stop and restart. But as the rtorrent is gui and not cli based I think it does not benefit anything. For example stop might (I'm not a Linux expert but killall command sounds like forcing an application to shutdown) not shutdown rtorrent cleanly.

 

No, I'm not sure it would in all cases. There would be a chance the rtorrent lock file would be left behind and cause problems next start up. Again they're not really daemonising it, all they're doing is running rtorrent in a screen session when starting it and then when stopping it sending it the kill signal.

 

They're not changing rtorrents behaviour in any way and it's just a convenient way to have it integrated with the rest of the system service scripts. It's the same thing flixxx has done although he's taken into account a lock file check.

 

I'm really on a thin ice on this one since I'm just entering the linux world but I tried to understand the linux startup script structure (rc.d, inittab etc.). At least on my 4.4.2 system there are proprietary run scripts in the /etc/rc.d directory, one of them is the rc.unRAID itself. They do have the start/stop/restart mechanisms builtin. Am I mixing things here?

 

I'm on thin ice myself when it comes to the unraid part of this

 

THe problem as I understand it, and hopefully someone will correct me if I'm wrong!, is that all these rc scripts are in the ramdisk image. You *could* explode this, put your rc script into it then repack it. But it's an awful lot of work when unraid gives you the go script interface to start something up. You could start rtorrent up via the go script and then copy a script into the rc directory - it would never help during system boot but would help you at other times.

 

You lose the ability to 'stop' and 'restart' rtorrent but all you're really doing there is sending it a kill command and then re running the original start script.

 

I'm not even 100% sure what shutdown procedure unraid follows when you invoke the shutdown from the web gui. It may skip disabling the rc scripts one by one as it goes as it doesn't expect anything it hasn't put there to exist. I know the approved way to shutdown is via the web gui and not by running shutdown / reboot / poweroff from the console. This may just be so the unraid management daemon can shut the array down cleanly itself but it also suggests a lack of ability to do this as part of the 'normal'  shutdown process.

 

5.0 is being touted as having better hooks into the unraid management system to allow shutdown of third party applications which may change this.

 

Until then I would suggest that yes, you could write your own rc script and inject it into the ramdisk image but it's a hell of a lot of extra work (compared to the go script) just to save you typing killall rtorrent on occasion!

 

I may be showing personal bias here as I don't see why you would want to stop or restart rtorrent itself (unless it's crashed). You can stop / remove running torrents via the console interface or via a web GUI. I've never touched the actual running rtorrent binary after the system has booted.

 

 

[henris]

No, I'm not sure it would in all cases. There would be a chance the rtorrent lock file would be left behind and cause problems next start up. Again they're not really daemonising it, all they're doing is running rtorrent in a screen session when starting it and then when stopping it sending it the kill signal.

 

They're not changing rtorrents behaviour in any way and it's just a convenient way to have it integrated with the rest of the system service scripts. It's the same thing flixxx has done although he's taken into account a lock file check.

Is there any way to externally signal rtorrent to shutdown cleanly (equivalent to pressing ctrl-q on the qui)? If there is, then it would perhaps make it more beneficial to explore this deamonising little further. There are other torrent clients with cli but as this is already nicely packaged for unRAID there is no point looking for others.

 

I'm on thin ice myself when it comes to the unraid part of this

 

THe problem as I understand it, and hopefully someone will correct me if I'm wrong!, is that all these rc scripts are in the ramdisk image. You *could* explode this, put your rc script into it then repack it. But it's an awful lot of work when unraid gives you the go script interface to start something up. You could start rtorrent up via the go script and then copy a script into the rc directory - it would never help during system boot but would help you at other times.

 

You lose the ability to 'stop' and 'restart' rtorrent but all you're really doing there is sending it a kill command and then re running the original start script.

 

I'm not even 100% sure what shutdown procedure unraid follows when you invoke the shutdown from the web gui. It may skip disabling the rc scripts one by one as it goes as it doesn't expect anything it hasn't put there to exist. I know the approved way to shutdown is via the web gui and not by running shutdown / reboot / poweroff from the console. This may just be so the unraid management daemon can shut the array down cleanly itself but it also suggests a lack of ability to do this as part of the 'normal'  shutdown process.

 

5.0 is being touted as having better hooks into the unraid management system to allow shutdown of third party applications which may change this.

 

Until then I would suggest that yes, you could write your own rc script and inject it into the ramdisk image but it's a hell of a lot of extra work (compared to the go script) just to save you typing killall rtorrent on occasion!

 

I may be showing personal bias here as I don't see why you would want to stop or restart rtorrent itself (unless it's crashed). You can stop / remove running torrents via the console interface or via a web GUI. I've never touched the actual running rtorrent binary after the system has booted.

I'm trying to figure out the proper (easy to use and maintain) way of handling all these additional use customisations and especially the ones which are running as a background process. Most of them have their own parameters and specialities (like need for a directory to exist etc.). It would be nice if they all had the same control mechanism which would hide the nasty details. I would like to have my go script as clean as possible with mostly one-liners per service. This can of course be achieved with other means like subscripts but even for those I would like to see some kind of "design pattern". The rc.d start/stop/restart is such a design pattern and thus far I have not seen any downsides to it.

 

I think you are 100% right about the problem with unRAID distro holding the rc.d scripts within the ramdisk image. But I also think the workaround suggested by you (start in go script and copy etc/rc.d for later use) if sufficient for this task.

 

I'll dig into this a bit more and come back if I have success making the rtorrent a true and clean daemon within unRAID. I'm fully aware that the time spent on this particular application is mostly for educational purposes

[boof]

Is there any way to externally signal rtorrent to shutdown cleanly (equivalent to pressing ctrl-q on the qui)? If there is, then it would perhaps make it more beneficial to explore this deamonising little further. There are other torrent clients with cli but as this is already nicely packaged for unRAID there is no point looking for others.

 

It depends how rtorrent handles signals. In theory it should play nice if you kill it with the correct signals. I suspect it's if it crashes or otherwise has a wobble that you run into the lock file problems. A sift through the rtorrent man page / docs might reveal the answer. Theres hopefully a signal it will accept to gracefully shutdown as if you ctrl-q'd it.

 

I'm trying to figure out the proper (easy to use and maintain) way of handling all these additional use customisations and especially the ones which are running as a background process. Most of them have their own parameters and specialities (like need for a directory to exist etc.).

 

The current trend is using the go script to call your own setup script to make sure the environment is nice and then launch the program. I understand it's not what you want and you're correct it's not optimal but it's the path of least resistance.

 

I think alot of people are waiting for 5.0 which promises to have effectively an API into unraid for third party scripts. It should make triggering actions based on unraids behaviour (array stop, array start, reboot etc) much easier and is, in terms of unraid, a better solution that a 'normal' distribution rc script and much better solution than the current go script.

 

However 5.0 isn't actually here yet! 

 

It would be nice if they all had the same control mechanism which would hide the nasty details. I would like to have my go script as clean as possible with mostly one-liners per service. This can of course be achieved with other means like subscripts but even for those I would like to see some kind of "design pattern". The rc.d start/stop/restart is such a design pattern and thus far I have not seen any downsides to it.

 

Except at the moment unraid doesn't really use it

 

If you 'stop' the array via the GUI but have rtorrent running in the background with held open files - it won't ever stop (I believe). unraid doesn't talk or go through the rc scripts to look for things to shut down and rtorrent has no way of knowing unraid is trying to close. This is where the api hooks would come in. One script to start rtorrent (triggered at boot or array start) and another to stop it (triggered by array stop or power off).

 

I think the current usage of unraid and the amount of addon's and background processes the community has tacked on is a long way from what the original design took into account.

 

I think you are 100% right about the problem with unRAID distro holding the rc.d scripts within the ramdisk image. But I also think the workaround suggested by you (start in go script and copy etc/rc.d for later use) if sufficient for this task.

 

I'll dig into this a bit more and come back if I have success making the rtorrent a true and clean daemon within unRAID. I'm fully aware that the time spent on this particular application is mostly for educational purposes

 

 

Always worth saying the current situation may not be the best that could be done - it's just the one people are living with. Always room for improvement so keep us posted!