"SimpleFeatures" Plugin - Version 1.0.11

[jkm9000]

I'm having the same problem. Happened while doing a drive rebuild too All the drive lights are still going and nothing in the syslog so I think it's still doing the rebuild.

 

These are the plugins I have installed:

 

simpleFeatures.active.streams-1.0.5-noarch-1.plg*

simpleFeatures.activity.monitor-1.0.5-noarch-1.plg*

simpleFeatures.core.webGUI-1.0.5-noarch-1.plg*

simpleFeatures.disk.health-1.0.5-noarch-1.plg*

simpleFeatures.email.notify-1.0.5-noarch-1.plg*

simpleFeatures.log.viewer-1.0.5-noarch-1.plg*

simpleFeatures.system.info-1.0.5-noarch-1.plg*

simpleFeatures.system.stats-1.0.5-noarch-1.plg*

 

telnet localhost 80 hangs as well, so not a browser issue.

 

Is there any logs I can look at / provide before I reboot?

 

I'm finding that the GUI just randomly stops responding since installing the new SF. Any suggestions where I should start looking to find out why?

 

whiteatom

Looks like I am suffering from this now as well.

[bonienl]

When "telnet 80" doesn't work, it means the emhttp process is killed.

 

Are you running your system with 6GB or more of memory?

 

Downgrade to 2GB or 4GB and retest.

 

Problems have been reported to unRAID being unstable with larger memory sizes.

 

[theone]

When "telnet 80" doesn't work, it means the emhttp process is killed.

 

Are you running your system with 6GB or more of memory?

 

Downgrade to 2GB or 4GB and retest.

 

Problems have been reported to unRAID being unstable with larger memory sizes.

 

I am having emhttp issues as well. See here:

http://lime-technology.com/forum/index.php?topic=23274.msg205583#msg205583

 

As mentioned I have uninstalled the SimpleFeatures CORE plugin and since then (>5 days) I have had no WEBUI crashes.

http://lime-technology.com/forum/index.php?topic=23274.msg211818#msg211818

 

I am running with 4GB memory.

[bonienl]

When "telnet 80" doesn't work, it means the emhttp process is killed.

 

Are you running your system with 6GB or more of memory?

 

Downgrade to 2GB or 4GB and retest.

 

Problems have been reported to unRAID being unstable with larger memory sizes.

 

I am having emhttp issues as well. See here:

http://lime-technology.com/forum/index.php?topic=23274.msg205583#msg205583

 

As mentioned I have uninstalled the SimpleFeatures CORE plugin and since then (>5 days) I have had no WEBUI crashes.

http://lime-technology.com/forum/index.php?topic=23274.msg211818#msg211818

 

I am running with 4GB memory.

Besides the SF core plugin, do you or did you have other SF plugins running as well ?

 

I can't reproduce this issue... That is I have my system running with all SF plugins installed and it is stable for weeks.

 

[theone]

Besides the SF core plugin, do you or did you have other SF plugins running as well ?

 

I can't reproduce this issue... That is I have my system running with all SF plugins installed and it is stable for weeks.

 

Yes I have almost all installed except:

cache_dirs

dns_server

s3_sleep

 

and as stated, for debugging purpose, disabled:

core_webGUI

[Helmonder]

Search for oom_adj and opm_score on the forum, that will solve the emhttp getting killed.

[theone]

Search for oom_adj and opm_score on the forum, that will solve the emhttp getting killed.

 

I did it already a while back (for smdb ad emhttp as suggested) - it didn't help.

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

 

There are no notifications on the syslog that anything is being killed...

 

 

[bonienl]

Besides the SF core plugin, do you or did you have other SF plugins running as well ?

 

I can't reproduce this issue... That is I have my system running with all SF plugins installed and it is stable for weeks.

 

Yes I have almost all installed except:

cache_dirs

dns_server

s3_sleep

 

and as stated, for debugging purpose, disabled:

core_webGUI

The other plugins rely on the core plugin to store their settings and some other shared modules.

 

I recommend you disable these plugins as well since proper operation can't be garanteed.

 

And then again it puzzles me why the core plugin may cause unstability...

 

[bonienl]

The "web server" plugin installs a newer version of PHP, this impacts emhttp too.

 

You may want to test without this plugin installed...

 

[theone]

I will give it a few more days/weeks without the CORE plugin to make sure everything is stable. I will then install the CORE plugin again and see if the WEBGUI crashes.

 

WEBSERVER doesn't seem to be running - seems I cannot enable it without the CORE plugin installed... Interesting.

I will try try re-enable the CORE plugin but disable the WEBSERVER pluginin a few days.

 

Does anyone else have the emhttp WEBGUI not responding and also has WEBSERVER plugin enabled?

 

If I disable the WEBSERVER does the PHP return to original version?

[speeding_ant]

Hmmm, I've seen servers with over 2 months of up-time on version 1.0.5 with no leaks. I understand the email notifications plugin will log quite a bit, and the stats plugin could potentially allocate around 20MB to memory (monthly rotation). However, this won't cause memory issues with machines that meet the minimum spec for unRAID...  The current PHP libraries included in the web server plugin are compiled from the stable release - I've run this plugin for 2 months without issue so far.

 

For the users that are affected, are you running plugins other than SimpleFeatures? As Boneinl said, there have been issues regarding servers with more than 4Gb of RAM also.

 

Cheers 

 

 

P.S.  I'm so sorry I've been as quiet as Limetech  on the forums. I'll make it up to you all, I promise!

[theone]

I have in addition to SimpleFeatures: utorrent, virtualbox, plex, and a few others.

The problem is I can't turn them off for several days to debug this - they are in use daily by the family - and the problem appear every few days.

I can probably run with the minimum utorrent and virtualbox.

 

 

[speeding_ant]

Can I please suggest keeping a close eye on the memory usage with the SimpleFeatures Activity monitor (yep, I plugged it). Sort by Real Mem, check out what's using the most.

 

If that's not possible, I'm happy to make a script and give you some instructions on how to log memory usage.

 

See screenshot 

[theone]

I am not sure it is a memory problem.

I have swap file installed. Memory usage is usually well below 50%.

emhttp is still running when it is not accessible - it doesn't get killer.

 

[int13h]

In unmenu, the main page can show the progress of a preclear. Is this available somewhere in simplefeatures? Couldn't find it.

It is not available in the current version 1.0.5.

 

I have created a new "preclear disk" plugin which works together with the latest version of SimpleFeatures (not released yet).

 

This plugin adds the possibility to do a preclear operation using the GUI on any of the disks which are not part of the array (unassigned disks are optionally displayed in the next SF version).

 

Progress of the preclear operation is shown in real-time in the GUI and runs in the background of the server. This eliminates the need of having a telnet session open for the duration of the preclear. One can leave the preclear page or even close the browser and return later to the preclear page to see and further follow the current state.

 

The plugin acts as a front-end to the (modified) "preclear_disk" script, courtesy of Joe L.

 

To make things work I needed to add 2 more optional switches to the command line of preclear_disk, which allow for auto-answering and output redirection.

 

It is written in such a way that multiple (new) disks can be precleared simultaneously, provided you have enough memory to do so.

 

Glad to know that. I will have to add a new disk in a few weeks, I hope it will be released soon

[trurl]

I can't reproduce this issue... That is I have my system running with all SF plugins installed and it is stable for weeks.

Just as another data point I have 4GB RAM and I am running all SF plugins as well as several of Influencer's UNPLUGGED, CrashPlan, DropBox, Hamachi, probably others and I am also stable. The only time recently I have crashed the webGUI was trying to preclear a 3TB drive but JoeL suggested some changes from the default buffer sizes on the preclear script and everything has been fine since.

 

I also have swap file, oom_adj fix, and samba update running, mostly because I could understand how to do them and they weren't much trouble. Don't know if these helped any.

[theone]

trurl,

 

Do you have the SF webserver enabled/running? If yes then for what purpose?

[jkm9000]

Sorry I should have been more clear, emhttp was still running and port 80 would connect. Issuing a GET / command would return nothing and eventually the connection dropped. Furthermore there was nothing unusual in the syslog... I had been doing a drive rebuild and had a syslog tail running the whole time as well as a display hooked up to see any errors that might show up there.

 

Yes, I have 16 GB of RAM but I have had that for around a year and a half and the system has been rock solid. So if others have problems with more memory it has not impacted me and I run several add-ons.

 

Only 2 things have changed recently.

1 Upgraded unraid from rc4 to rc8 and

2. Upgraded simpleFeatures to v 1.0.5.

 

I have seen other people having issues since upgrading sF to 1.0.5 so that seems the likely candidate to me as I'm not seeing reports of this happening with rc8 (perhaps I've missed). My post drive rebuild parity check is nearing completion so I will be able to reboot with the older sF and see if that helps.

 

When "telnet 80" doesn't work, it means the emhttp process is killed.

 

Are you running your system with 6GB or more of memory?

 

Downgrade to 2GB or 4GB and retest.

 

Problems have been reported to unRAID being unstable with larger memory sizes.

 

I am having emhttp issues as well. See here:

http://lime-technology.com/forum/index.php?topic=23274.msg205583#msg205583

 

As mentioned I have uninstalled the SimpleFeatures CORE plugin and since then (>5 days) I have had no WEBUI crashes.

http://lime-technology.com/forum/index.php?topic=23274.msg211818#msg211818

 

I am running with 4GB memory.

[trurl]

trurl,

 

Do you have the SF webserver enabled/running? If yes then for what purpose?

I do but right now it's just for tinkering with. Only a simple page of bookmarks on it at the moment.

[bonienl]

I will give it a few more days/weeks without the CORE plugin to make sure everything is stable. I will then install the CORE plugin again and see if the WEBGUI crashes.

 

WEBSERVER doesn't seem to be running - seems I cannot enable it without the CORE plugin installed... Interesting.

I will try try re-enable the CORE plugin but disable the WEBSERVER pluginin a few days.

 

Does anyone else have the emhttp WEBGUI not responding and also has WEBSERVER plugin enabled?

 

If I disable the WEBSERVER does the PHP return to original version?

 

As explained earlier: do not run additional packages without the core webGUI plugin installed. There are dependencies, specifically when it comes to updating and applying settings.

 

When you say "disable" I presume you remove the associated plg file from /boot/config/plugins and reboot your system.

 

The above procedure ensures PHP to revert back to the one supplied with unRAID (PHP version 5.2).

 

[bonienl]

Another note: if you have been upgrading from a SF version before 1.0.5 then also make sure there are no "left-overs" in the go file.

 

Previous version would install a startup line for "cache_dirs" and "s3_sleep" in your go file. Have these removed if present.

 

[speeding_ant]

I am not sure it is a memory problem.

I have swap file installed. Memory usage is usually well below 50%.

emhttp is still running when it is not accessible - it doesn't get killer.

 

There might be another service aggressively taking over port 80. When this happens again, try running this command: lsof -i | grep 80

 

I'm dubious that it's SimpleFeatures causing an issue. Even if there is a configuration issue with the web server plugin, it doesn't ever start before emhttp, therefore lighttpd conflicts with the port and never starts. None of the other services are heavy weight, with the worst of memory leaks you'd be using 50MB tops over a few months.

 

I hope we find the source of this problem either way.

[optiman]

Another note: if you have been upgrading from a SF version before 1.0.5 then also make sure there are no "left-overs" in the go file.

 

Previous version would install a startup line for "cache_dirs" and "s3_sleep" in your go file. Have these removed if present.

 

 

In looking at my GO file, I now only have the following lines, which I think are put there by SF current version;

 

# Start the Management Utility

/usr/local/sbin/emhttp &

sed -i '/Scheduled Parity Check/d' /var/spool/cron/crontabs/root

sed -i '/cron=\"\"/d' /var/spool/cron/crontabs/root

 

Can you confirm these should be there?

 

[Benni-chan]

afaik, the current version doesn't change the go file. at least i don't have any entries in the go file, that could have come from SF.

 

the only lines you need are

# Start the Management Utility
/usr/local/sbin/emhttp &

(the first one could be removed to, since it's a comment.

[bonienl]

In looking at my GO file, I now only have the following lines, which I think are put there by SF current version;

 

# Start the Management Utility

/usr/local/sbin/emhttp &

sed -i '/Scheduled Parity Check/d' /var/spool/cron/crontabs/root

sed -i '/cron=\"\"/d' /var/spool/cron/crontabs/root

 

Can you confirm these should be there?

 

The current version of SF - based on the new plugin system - does not write anything to the 'go' file anymore. Nor did the old version produce the entries above.

 

In short these entries are not coming from any SF version !