All - I have this problem also although I'm finding that the shares are there initially, and they disappear suddenly (latest examples, whilst watching a movie which obviously stopped it!).

 

The underlying data is there. A re-boot brings them back but this seems to reoccur.

 

Sys log attached (note - I tried restarting SMB and AFP services which will be in the log).

 

I checked the flash drive under /config/shares and the .cfg files for each share were missing also - but reappear upon reboot (although they don't reappear by just stopping and re-starting the array).

 

I also have the rsync daemon running and the last two occurrences maybe linked to a backup that another NAS initiated. I am going to test that theory and will report back here. I have been using this for a year or so so a little sceptical but you never know..

 

I notice memory usage is high,  although perhaps normal given low swap usage??

 

rocs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

r  b  swpd  free  buff  cache  si  so    bi    bo  in  cs us sy id wa

1  4  4536  92964 129220 3520216    0    1  938  842 1555 2225 20 29 20 31

            total      used      free    shared    buffers    cached

Mem:      8049044    7956080      92964          0    129220    3520216

-/+ buffers/cache:    4306644    3742400

Swap:      2047996      4536    2043460

root@unRAID:~#

 

 

Thanks,

 

Alex.

syslog-20121119-133626.txt.zip

Just to update in case anyone else has this issue.

 

I've disabled a regular rsync backup I run every night and this issue has not reoccured so at this point it appears to be (weirdly) related to that..

 

Alex.

I think I know what is going on... Shares dissapearing is the result of the SMBDeamon getting terminated...

 

Since the issue does not reappear after you have disabled another process on the server it is likely that the SMBDaemon got killed off by linux due to a lack of memory.

 

Check out this thread:

 

http://lime-technology.com/forum/index.php?topic=22971.msg203371#msg203371

 

 

Thanks - I think you are probably right although this has only been an issue since rc8a (or at least between rc5 and rc8a).

 

I wonder if increasing my swap file might help - it did appear to release the memory at a later stage I think, i.e. after the rsync job is complete?

 

All my apps are installed on the cache drive so none are running out of /tmp

 

Alex.

Where your apps are running from does not matter. A swap file will help unless the issue is lack of low memory.

Just to update in case anyone else has this issue.

 

I've disabled a regular rsync backup I run every night and this issue has not reoccured so at this point it appears to be (weirdly) related to that..

 

Alex.

The amount of memory that rsync needs can depend on how it shares the information on the files / folders being synced.  For example if you use either of the --delete-before or --delete-after options then rsync will build a complete list of files before any transfers take place.  If there are large numbers of files that can be an issue.  At the rsync "master" it will report "building file lists" or similar.  I had this problem.    After some reading around I changed to a simple --delete option and now rsync reports that it's using incremental file lists and I find that the memory usage is very much lower.

 

Of course, this might not be your problem, but perhaps it's worth a look.

Thanks - doing an rsync backup between a synology NAS and my unRAID box - not that much control on the syno end.

 

It does seem to be an RC8a issue as I had no issue with the same plugins and rsync on rc5...?

 

A shame, hopefully a solution will present itself!

 

Thanks again,

 

Alex

 

RC8a might use a bit more memory making it appear more sooner... If you use the oom_adj / oom_score parameters you will prevent the smbd getting killed, I have run without any issue for more then a month now..

Thanks - I'll have a look.

 

I hear what you are saying re: rc8a, but on the basis it NEVER appeared before (i.e. in 6 months of almost continual running) I'm a little skeptical.

 

I have updated the sabnzbd, sick beard and couchpotato now I think of it (at the same time as the rc8a upgrade) - possible they have introduced some memory leaks or other bugs, I should down grade perhaps!

 

A;ex

There are several setting that make sabnzbd a bit more friendly with memory.. you could try those.. you could also give sabnzbd a very likely-to-get-killed oom_score.. That way you will loose sabnzbd whenever there are memory issues, but you can easily restart it..

All - this is still happening and I'm positive it's not memory related - my shares just disappeared mid film having restarted my server 10 minutes ago with plenty of low memory available.

 

I love unRAID and the helpfulness of this forum but I'm starting to think of alternatives - the one thing a media server has to be is available and unRAID seems to be less reliable than a WIndows platform when running any plugins!!!

 

Any ideas anyone?

 

Thanks,

 

Alex.

I love unRAID and the helpfulness of this forum but I'm starting to think of alternatives - the one thing a media server has to be is available and unRAID seems to be less reliable than a WIndows platform when running any plugins!!!

 

Any ideas anyone?

It's not unraid's fault. I'm currently running 4.7 with 18TB of protected space, Sickbeard, Sabnzb, Couchpotato1, Virtualbox with 2 running VM's, and a slew of other less important stuff, my uptime right now is 127 days, and I see no reason I can't continue to run without rebooting until a disk dies or I lose power for longer than the batteries in my backup will last.

 

You need to disable all your plugins and add back one at a time until you find the culprit. One or more of your plugins is probably causing the issue. Once you figure out exactly which plugin is the problem, then you can troubleshoot from there.

HI - I know it's possibly not the core unRAID config - although it was fine till rc8a, however it still seems nuts that plugins and other packages bring the whole array down - i.e. not running in protected memory.

 

Because it's not a frequent issue, removing one plugin at a time essentially can mean many months without the full functionality - read no media server in my case which is where it fails the other half test!!

 

I'm contemplating moving sabnzbd, sick beard etc off the server onto my macmini so I can set the array to sleep given the macmini used such little power...perhaps that's the best approach! Unfortunately I still need a windows VM for my surveillance and a few other functions.

 

Any ideas on how to better identify the issue would be great though!

 

Thanks,

 

Alex

Have you made the OOM adjustments ?  I am pretty confident they will help.. I would also advise making an OOM adjustment that makes SBNZBD a very likely candidate to get killed... It is using the most memory but is also very active (and because of that activity it is less likely to get killed..

I did indeed, bizarely it caused it to crash even quicker (which confused me a little).

 

I set smb and emhttp as per your instructions.

 

Alex.

Well... OOM is triggered when there is a lack of memory, IF OOM is your issue you can easily see in your syslog, if you see OOM messages then processes are killed off because of lack of memory. And if that happens both SMBD and EMHTTP are very likely to be the ones sacrificed.

 

If you do not see OOM errors then something else is going  on and these settings will do nothing (they will also not do anything negative by the way).

 

Issue is that the OOM adjustments do not take away the problem of you running out of memory... That still happens and an activity WILL get sacrificed, only it will not be emhhtp and/or smbd. Possibly in your case an even more core process got sacrificed causing a bigger issue.

 

Best thing to do is help your system in making the correct choice. Whenever an out of memory event occurs you want it to NOT kill of emhttp and smbd, you probably also have it not kill the telnetd. Nice ones to to have killed off in sucn an instance are sabnzbd, couchpotato and sickbeard. All are not core to the system AND (more importantly) can also be easily restarted.

 

With a little bit of scripting you could even have an hourly cron job that would check on sabnzb, couchpotato and sickbeard still running, and if not restarting them after X time. Out of memory mostly only occurs for short periods of time so with such a way of working you would probably not even notice an issue any more..

Indeed - suspect you are right. Easiest option might be to run SABznbd on my Mac Mini - pretty confident it's the memory eater!! Besides, then I can sleep my unRAID server and downloads aren't affected.

 

Having said that, rsync running causes the same issue - so much so I can't utilise the cache disk function as it brings down the array (i.e. unrecoverable crash).

 

Tom has responded and I've sent him my syslog. Will see what he can turn up before I throw my toys out the pram!!

 

Thanks again - Alex

How are you invoking rsync?  Some rsync options can use large amounts of memory if you have many files involved.  The --delete-after and --delete-before options have bitten me in the past.  Other options that do not require rsync to maintain a list of all files in the transaction (such as --delete) will use much less.

I'll be honest all - I think I'm done with unRAID.

 

It seems I can't have a reliable array and use plugins and that just isn't good enough. I have emailed Tom, and apart from a reply about duplicate items which he said isn't the cause I have heard nothing. I appreciate he is a busy man but let's be honest - I paid a licence fee (and it isn't too small), in most worlds that means more than a simple reliance on forums for support.

 

I hear lots of others say they have a reliable setup but it seems my setup can only go for a maximum of 13 days without the whole array falling over. I re-started it this morning after a similar result and an hour later it has fallen over.

 

Is it me, or (and please let's be honest and objective) - is it just me or is unRAID just fundamentally unstable when using plugins?

 

I'm not quite ditching it yet - but I'm going to play around with FlexRAID and see how we go all though I worry it's also 'manpower' limited. I mean no offence to Tom, quite the opposite - unRAID is impressive, but he appears to be making the classic start-up error of growing too fast and not being able to support his product or release at an acceptable rate. My opinion of course and you are all free to disagree. As a hobby setup it's great but as a reliable professional platform, it still has some way to go - I hope it get's there!

 

Excuse my frustration!

 

Thanks,

 

Alex

As asked before: does your syslog(s) show oom errors after loosing your shares or not ?

 

Does uour system remain stable with no plugins and rsync jobs ?

 

Are you invoking rsync "memory friendly" ?

Not that I can see (I passed my syslog onto Tom - he couldn't come up with anything - or at least hasn't to date).

 

I've disabled the rsync and I'm not running with my cache drive as that crashes the array also.

 

I can't try completely without any plugins (plex in my case), as my household needs it - at least not for the time period to be sure it isn't re-occuring which is up to two weeks.

 

Moving Couhpotato and Sickbeard off to my Mac so will remove those plugins permanently shortly.

 

Thanks,

 

Alex

Small effort to check your syslog yourself I would think, but ofcourse you are free to wait for Tom.  Remember though he delivers and supports unraid, not the plugins, so for basic unraid support first action would be to see if it works without any plugins

 

Good luck with your troubleshooting.

Thanks - I've already had a look and run a tail, nothing obvious.