Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hi everybody, I've been meaning to get round to sorting out a script to auto-restart uShare for a while, and today I found this thread where RimBlock supplies one for ffp 0.5 (thanks!).
I only use ffp 0.4 (because I only really need uShare, and that's the fun_plug it was compiled against before), so I thought I'd port the script back. Then I realised I'd always forget to create the recycle file, so decided to try and make it properly automatic. I think I've been successful (I'm doing final testing of my scripts now), so it would have been rude to not sign up and share.
There are two obstacles to clamber over:
1) How to determine if uShare needs a restart automatically, and
2) Everybody hates their disks spinning up unnecessarily.
Solving 1) is quite simple, if you don't mind a simple solution: look at a single directory, and when its size changes, assume uShare needs a restart. The only real problem is if you somehow manage to change things without changing the size of the directory! This will also pick up changes to irrelevant things, so it's better if you have all your streaming media split off if you change other things a lot. Of course, if the du output is unchanged from the last check, it doesn't restart uShare.
2) is harder, I spent ages trying to find commands to query the drive's power state. I failed, so in the end I decided to look at the last 5 lines of the dmesg output; if there's a "HD. stand by now" message, it doesn't scan. If there's a "HD. awake now" - or no message (my dmesg is full of these and nothing else, but I imagine other people with more services will get more) - it runs the check.
In addition, when I added fanspeed control (thanks to whoever wrote the script I based mine on!) it seemed reccommended to copy the script into the ramdisk, so my startup script does that, and step 1) also writes the last-check value into the ramdisk.
Here are the scripts. There is no install, but if you extract the attached .tgz into /mnt/HD_a2/funplug.d (tar -zxf ushare_refresh.tgz -C /mnt/HD_a2/fun_plug.d) it might put the files in the right place. They might need chmod 755'ing, I don't know if the tar has caught the permissions.
Remember that I wrote this for my DNS-323 with firmware 1.05, fonz's fun_plug 0.4 and uShare 1.1a. It is also NOT PROPERLY TESTED yet, it seems to start/stop okay now, but I haven't proved yet that it will restart uShare when it should, and that it won't cause the hard disks to spin up a lot - uShare is still generating its index at the moment!
Last edited by BikNorton (2008-08-03 20:53:32)
Offline
BikNorton wrote:
2) is harder, I spent ages trying to find commands to query the drive's power state.
Did you see http://www.inreto.de/dns323/utils/ ?
dns323-spindown
Prints disk state (ACTIVE/STANDBY/UNKNOWN). Pass a timeout
in minutes one the command line to set a new spindown timer.
Offline
Heh. No - and of course the fanctrl script uses dns323-fan and dns323-temp, I assumed -spindown actually spins the drive down, not check it.
Also, uShare won't actually stay running at the moment, it spends ages pegging the CPU at 100% then disappears. I don't think it's my script, and am checking it out.
Last edited by BikNorton (2008-08-02 19:08:34)
Offline
I've fixed a bug (it never actually restarted uShare! Doh!) and changed it to use dns323-spindown (thanks fonz); updated the attachment in the first post.
My uShare is definitely not working though, with my script not running and manually starting uShare, it still dies after half an hour of hogging the CPU.
Last edited by BikNorton (2008-08-02 20:17:26)
Offline
BikNorton wrote:
Also, uShare won't actually stay running at the moment, it spends ages pegging the CPU at 100% then disappears. I don't think it's my script, and am checking it out.
I had the same problem with ushare. Maybe a bug in uclibc.
Offline
It's only started doing it since I added a few new things to it; part of it seems to be some subs.
Anyway, I've realised that restarting uShare every 10 minutes if, for example, you're ripping some CDs is a bad thing to do!
Edit: I've fixed and updated the tarball in the first post; now it restarts uShare if the sizes match but have different in the past. This might be an issue if your torrent client pre-allocates; uShare might not add the 'corrupt' file to the index.
Last edited by BikNorton (2008-08-03 18:36:57)
Offline
I've just found out that my script can't work; it uses 'du', which the dns323's built-in busybox doesn't have - the only way it works keeps the hard disk spinning. What a waste of time!
Edit: I'm going to change it to use 'df', which won't be as accurate but close enough for me!
Last edited by BikNorton (2008-08-03 19:05:27)
Offline
BikNorton wrote:
Hi everybody, I've been meaning to get round to sorting out a script to auto-restart uShare for a while, and today I found this thread where RimBlock supplies one for ffp 0.5 (thanks!).
NP.
Oh and it should work if you just change the instances in both the files from 'ffp' to 'fun_plug.d' (presuming ffp 0.4 also had a /fun_plug.d link setup like ffp 0.5. I forget) ;-)
It will not address wither of the issues you pinted out though :-).
Cheers
RB
Offline
RimBlock wrote:
Oh and it should work if you just change the instances in both the files from 'ffp' to 'fun_plug.d' (presuming ffp 0.4 also had a /fun_plug.d link setup like ffp 0.5. I forget) ;-)
It was a little more, prefix changed from /mnt/HD_a2/fun_plug.d to /ffp to remove the disk part of the path.
Offline
Right! Yet another version! This one runs from the ramdisk, using changes in the 'disk free space' of (by default) /dev/md0. Unfortunately for now it has to copy dns323-spindown to the ramdisk as well, at 4KB that's quite a lot of ramdisk to use but this way it allows the hard disks to spin down - mine just have. So it's not quite perfect yet, but it's almost there I think.
Last edited by BikNorton (2008-08-03 20:57:48)
Offline
fonz wrote:
RimBlock wrote:
Oh and it should work if you just change the instances in both the files from 'ffp' to 'fun_plug.d' (presuming ffp 0.4 also had a /fun_plug.d link setup like ffp 0.5. I forget) ;-)
It was a little more, prefix changed from /mnt/HD_a2/fun_plug.d to /ffp to remove the disk part of the path.
Ok so easiest solution would be to run;
ln -s /mnt/HD_a2/fund_plug.d /ffp
All of my scripts should work then although compiled programs may not (very likely).
Anyway.... not ny thread and have not wish to hijack.
BikNorton, if you have a copy of your latest code I would be interested to take a look. Using the ramdisk is something I had not thought of.
Cheers
RB
Offline
Sorry, I forgot to say that I updated the tarball in the first post with the newest code. It seems to work, and uShare has magically started staying alive without hogging the CPU, which is weird.
I'm considering rewriting it as a cron job now, it seems a bit daft to have a script running constantly when cron is also running - I need to look into how useful cron is for frequently-run tasks, not just once a day/week.
Offline
BikNorton wrote:
Sorry, I forgot to say that I updated the tarball in the first post with the newest code. It seems to work, and uShare has magically started staying alive without hogging the CPU, which is weird.
I'm considering rewriting it as a cron job now, it seems a bit daft to have a script running constantly when cron is also running - I need to look into how useful cron is for frequently-run tasks, not just once a day/week.
Great, thanks will take a look.
The reason I chose not to go the cron way is that it is pretty static and with a script you can calculate when it should run rather than just set times it will run. I tend to find cron quite inflexible which is why I am looking at the trigger suite to filre scripts based on trigger files with a single check_cycle script running in the background.
RB
Offline