Twonky doesn't save... Should I be worried?

[Pinch]

My unRAID's been running for a while now with no problems, but noticing some odd behaviour in Twonky I need to know if it affects unRAID in any way.

 

Twonky doesn't save any settings at all. I can set everything up, but after a restart I have to do it all over again. This is not a biggie (my trial never runs out ), but I just have to be sure this is a problem isolated to Twonky only, like, it's not some underlying problem waiting to crash the complete system altogether (what do I know! )... It might not even be a bug, but Twonky on my old NAS had no trouble loading saved settings after a restart.

 

 

Oh, a quick question regarding disk management (I know it's the wrong forum, but it's probably an easy answer): if I remove a drive and don't replace it will unRAID rebuild the drive on other disk(s), granted enough free space is available? The wiki doesn't really mention this explicitly...

 

EDIT: Added my syslog (same as attached to reply #4).

[Joe L.]

Oh, a quick question regarding disk management (I know it's the wrong forum, but it's probably an easy answer): if I remove a drive and don't replace it will unRAID rebuild the drive on other disk(s), granted enough free space is available? The wiki doesn't really mention this explicitly...

No, it will not.  If you remove a drive, or un-assign a drive, your array is un-protected and the missing drive is simulated using all the other drives.

 

You can copy the contents of the removed drive elsewhere, but it is entirely a manual process.  Parity protection can only be re-instated by initializing an entirely new configuration and re-calculating all of parity by pressing the "Restore" button (Poorly labeled, as it is actually, a "Set initial configuration" button)

[Pinch]

Thanks for clearing that up (and the quick reply)!

 

You can copy the contents of the removed drive elsewhere, but it is entirely a manual process.

By 'elsewhere' do you mean another disk, another system or both? I'd think writing to the array, while parity is simulating a missing disk, would mess up the parity making it impossible to simulate the drive?

[Joe L.]

Thanks for clearing that up (and the quick reply)!

 

You can copy the contents of the removed drive elsewhere, but it is entirely a manual process.

By 'elsewhere' do you mean another disk, another system or both? I'd think writing to the array, while parity is simulating a missing disk, would mess up the parity making it impossible to simulate the drive?

Nope, you can write to the array even while it is simulating a failed and/or missing disk.  You can even write to the failed/missing disk.  It will work just fine.  It does not mess up parity, in fact it is exactly the same as any other "write" in that the existing parity, and the existing "simulated" read of the data drive are both x-ored with the new data being written and then both updated... Parity for real, and the "simulated" disk ... simulated.

 

So, I meant you can copy the files from the failed disk to any other disk in your array...  You would only need to do this is you did not intend to replace the failed disk and were going to reset the drive configuration to only the remaining drives by using the poorly labeled "restore" button.

[Pinch]

Thanks for clearing that up (and the quick reply)!

 

You can copy the contents of the removed drive elsewhere, but it is entirely a manual process.

By 'elsewhere' do you mean another disk, another system or both? I'd think writing to the array, while parity is simulating a missing disk, would mess up the parity making it impossible to simulate the drive?

Nope, you can write to the array even while it is simulating a failed and/or missing disk.   You can even write to the failed/missing disk.  It will work just fine.  It does not mess up parity, in fact it is exactly the same as any other "write" in that the existing parity, and the existing "simulated" read of the data drive are both x-ored with the new data being written and then both updated... Parity for real, and the "simulated" disk ... simulated.

 

So, I meant you can copy the files from the failed disk to any other disk in your array...  You would only need to do this is you did not intend to replace the failed disk and were going to reset the drive configuration to only the remaining drives by using the poorly labeled "restore" button.

 

Heh, that's quite impressive... don't think I'll ever regret choosing unRAID!

 

Any thoughts on the Twonky problem, whether it could affect unRAID or not?

 

Attached is a syslog (I've edited out the directory names, though ).

 

Btw. just bought a Pro license, eagerly awaiting my key!

[RobJ]

Syslog looks fine, I assume you knew about the very last line indicating the mail command did not run.

 

Any thoughts on the Twonky problem, whether it could affect unRAID or not?

 

unRAID is different than most Linux setups, in that it runs entirely in a RAM disk.  So apps that are installed to this in-memory file system usually don't realize they are saving their settings to memory, which is lost on reboot.  When installing apps in unRAID, you usually have to either install them to a fixed disk location, such as on the Cache drive or the flash drive, or you need a mechanism to copy off the settings file before shutting down, and restoring it when you reinstall the app on the next boot.  I know nothing about Twonky, just trying to offer the usual basic reasons for what you are experiencing.  Perhaps a Twonky user will see this, and indicate what files need to be saved and restored, and how they handle it.

[Joe L.]

I assume you knew about the very last line indicating the mail command did not run.

The "at" command requires a "mail" command to be a true binary executable, as it invokes it directly. It will not send mail if the "mail" command is a shell script, as it is not invoked using a shell interpreter.

 

You can ignore the error.  Basically, all that the "at" command was attempting to mail to you was the fact that it had invoked the cache_dirs program.

 

Joe L.

[Pinch]

That explains everything, thanks RobJ!

 

Either way I've disabled cache_dirs for now, since it didn't work at all...