The plugin manager has a detection for when a download fails, there can be multiple reasons for a download to fail, ranging from the local side being off-line to the remote side being off-line and everything in between. Unfortunately that can't be determined from the simple message "network failure".

 

My SAS drive is displaying the temperature again. Thank you!

I'm not getting SMART reports from one of my disks, though it does respond to smartctl from the command line. There's nothing out of the ordinary about it - it's a SATA SSD connected to the motherboard, as is another one that does give SMART reports. I've started a new thread with more information and diagnostics.

2 hours ago, Squid said:

It actually should've returned a bunch of errors / warnings with the network down.  But it didn't which means that:

• At the time, FCP did manage to successfully ping github.com
• It did manage to download one particular file from github.com to check for blacklisted apps being installed. https://raw.githubusercontent.com/Squidly271/Community-Applications-Moderators/master/Moderation.json
• You don't have docker enabled
• It failed to download http://tools.linuxserver.io/unraid-docker-templates.json   (this is the cause of the error actually logged)  This is the first thing that happens when FCP runs, and downloading the moderation.json file happens immediately after.  (But your syslog shows the network came alive in the middle of FCP running anyways - which means that my entire analysis of why this one single error happened and not the others was a complete waste of my time.  Not the first time I've lost a half hour of my life though   )

   

I always thought that this was a bug though in the plugin system (which has never been reported in black & white for LT to see, as it's showed up in many syslogs, and I don't *think* that they were all 6.4), as I thought that the plugin system was supposed to save on the flash drive all downloads from a .plg   Perhaps because it isn't a txz it's not saving it.

 

 

I have seen FCP errors that say that I need to check my DNS settings.

 

I have docker enabled.

 

Sorry you wasted your time.

 

I believe the issue is that the network is not ready at times and messes things up with FCP and the Dynamix temperature plugin.  Not sure if the issue is with LT or the way the plugins work.

1 minute ago, dlandon said:

Sorry you wasted your time.

Just wanted to figure out why only the one error appeared and not all of them, and didn't catch in the syslog the reason why.  Don't worry about it - it was fun.

2 minutes ago, dlandon said:

I have seen FCP errors that say that I need to check my DNS settings.

 

That would be when all of the errors happened (ie: network wasn't fully running until after FCP did its thing at array start)

3 minutes ago, dlandon said:

I believe the issue is that the network is not ready at times

I think what we need is a setting somewhere that waits for the network to be up and running properly before installing plugins or starting the array (with an appropriate timeout)

15 hours ago, Dephcon said:

 

+1

 

We include all the 1G and faster network drivers available in the kernel, as well as select number of 100Mbit drivers (like Intel).  If you find what kernel version theose drivers were added, I can tell you if unRAID support it.

Hi I'm still on unraid 6.3.5 and I want to change to unraid 6.4.0 -rc14, but I have no idea how. I thought, that I just had to change a few files on my usb drive, but that's obviously not the case.

 

7 minutes ago, Leuchtekulli said:

Hi I'm still on unraid 6.3.5 and I want to change to unraid 6.4.0 -rc14, but I have no idea how. I thought, that I just had to change a few files on my usb drive, but that's obviously not the case.

 

 

 

1 hour ago, Squid said:

Just wanted to figure out why only the one error appeared and not all of them, and didn't catch in the syslog the reason why.  Don't worry about it - it was fun.

That would be when all of the errors happened (ie: network wasn't fully running until after FCP did its thing at array start)

I think what we need is a setting somewhere that waits for the network to be up and running properly before installing plugins or starting the array (with an appropriate timeout)

I put together a quick plugin named 'a.network.wait' that will run before other plugins.  It checks at 1 second intervals and waits for the network to come up before other plugins can run.  On my test server the wait time was logged at 4 seconds.

 

It seems like LT should wait until the network is alive before trying to install plugins.  I believe the thinking up until now was that it was not important because installed plugins have already downloaded the things they need and installed them on the flash.  That no longer seems to be the case.

2 minutes ago, BRiT said:

 

 

thx

45 minutes ago, dlandon said:

I put together a quick plugin named 'a.network.wait' that will run before other plugins.  It checks at 1 second intervals and waits for the network to come up before other plugins can run.  On my test server the wait time was logged at 4 seconds.

You need to name it "A.network.wait.plg"

 

The installation order is alphabetical, but not natural alphabetical.  (IE: NerdPack plugin installs before all others due to the capital N while every other plugin starts with lowercase).  Haven't installed it, but you should also make sure there's a timeout if the network never comes up where it will carry on regardless)

Edited November 24, 20178 yr by Squid

1 minute ago, Squid said:

You need to name it "A.network.wait.plg"

 

The installation order is alphabetical, but not natural alphabetical.  (IE: NerdPack plugin installs before all others due to the capital N while every other plugin starts with lowercase).  Haven't installed it, but you should also make sure there's a timeout if the network never comes up where it will carry on regardless)

It's a plugin I don't intend to make public.  I just did it to do a little testing.

52 minutes ago, dlandon said:

It's a plugin I don't intend to make public.  I just did it to do a little testing.

 

Initialization of the network stack starts early in the boot process and there shouldn't be a need to add any extra delay before installation of plugins is started, since this is at the very end of the boot process.

 

One external aspect which may come into play is how fast the DHCP server (if used) can provide an IP address to unRAID. Under normal operation this is quick enough to let unRAID have an IP address before communication activities start.

 

Ps. the upgrade plugin "unRAIDServer.plg" does have a network check code to ensure the network is present before actual upgrading starts.

30 minutes ago, bonienl said:

 

Initialization of the network stack starts early in the boot process and there shouldn't be a need to add any extra delay before installation of plugins is started, since this is at the very end of the boot process.

 

One external aspect which may come into play is how fast the DHCP server (if used) can provide an IP address to unRAID. Under normal operation this is quick enough to let unRAID have an IP address before communication activities start.

 

Ps. the upgrade plugin "unRAIDServer.plg" does have a network check code to ensure the network is present before actual upgrading starts.

I understand and theoretically you are right.  In my case though, I have to wait for the network for about 4 seconds:

Nov 24 14:09:24 BackupServer ntpd[1609]: Listening on routing socket on fd #23 for interface updates
Nov 24 14:09:24 BackupServer crond[1625]: /usr/sbin/crond 4.5 dillon's cron daemon, started with loglevel notice
Nov 24 14:09:24 BackupServer acpid: starting up with netlink and the input layer
Nov 24 14:09:24 BackupServer acpid: 1 rule loaded
Nov 24 14:09:24 BackupServer acpid: waiting for events: event logging is off
Nov 24 14:09:24 BackupServer root: Installing user plugins
Nov 24 14:09:24 BackupServer root: plugin: installing: /boot/config/plugins/a.network.wait.plg
Nov 24 14:09:24 BackupServer root: plugin: running: anonymous
Nov 24 14:09:24 BackupServer root: plugin: running: anonymous
Nov 24 14:09:24 BackupServer root: plugin: running: anonymous
Nov 24 14:09:27 BackupServer dhcpcd[1550]: br0: leased 192.168.1.4 for 86400 seconds
Nov 24 14:09:27 BackupServer dhcpcd[1550]: br0: adding route to 192.168.1.0/24
Nov 24 14:09:27 BackupServer dhcpcd[1550]: br0: adding default route via 192.168.1.1
Nov 24 14:09:28 BackupServer a.network.wait: Network took 4 seconds to come up

 

I honestly think the plugin manager should check for network connectivity whenever a plugin is installed.  Minor amount of code, but would prevent plugin installation failures due to network connectivity issues that can be difficult to discern - the plugin just fails.  The Dynamix temperature plugin has been failing to install on boot for me for a long time.  With my quick fix, it no longer fails.  Others have reported this also.  It is not just me that is having the problem.

10 minutes ago, dlandon said:

I honestly think the plugin manager should check for network connectivity whenever a plugin is installed.

 

If you make that a feature request then it will stay visible.

 

Just now, bonienl said:

 

If you make that a feature request then it will stay visible.

 

I'm on it.

I have been having an issue with one of my Shares that has a space "arche backup". Upon every reboot a new share will get created called "arche". I delete the new share "arche" and it goes away until I reboot. This has been happening with all the 6.4 betas and I think the 6.3 series as well. I believe it has to due with the VM Manager settings. I had " Default VM storage path:",  "Default ISO storage path:", and "Default Windows VirtIO driver ISO (optional):" all set do different subfolders under "/mnt/user/arche backup/". I just changed all three to "/mnt/user/" and the "arche" folder no longer gets created upon a reboot.

3 hours ago, archedraft said:

I have been having an issue with one of my Shares that has a space "arche backup". Upon every reboot a new share will get created called "arche". I delete the new share "arche" and it goes away until I reboot. This has been happening with all the 6.4 betas and I think the 6.3 series as well. I believe it has to due with the VM Manager settings. I had " Default VM storage path:",  "Default ISO storage path:", and "Default Windows VirtIO driver ISO (optional):" all set do different subfolders under "/mnt/user/arche backup/". I just changed all three to "/mnt/user/" and the "arche" folder no longer gets created upon a reboot.

I reported the same thing during 6.4rc9f.  Obviously it got missed on the todo list though

 

https://forums.lime-technology.com/topic/60516-64rc9f-creating-wrong-shares-for-vm-system-if-spaces-in-path/

 

I reported the same thing during 6.4rc9f.  Obviously it got missed on the todo list though

 

https://forums.lime-technology.com/topic/60516-64rc9f-creating-wrong-shares-for-vm-system-if-spaces-in-path/

 

 

Thanks, I’m glad I finally know what the culprit is! Drove me crazy for the longest time but with my limited time and the fact that I only ever reboot the server to get the latest update, I just dealt with deleting the new share.

On 11/23/2017 at 3:09 PM, zoggy said:

Tom, does unraid have drivers for the aquantia 5g/10g cards?

https://www.anandtech.com/show/12067/aquantia-to-sell-its-5g-and-10g-network-cards-for-59-and-69-on-black-friday

This card by asus uses the same controller as that 10G card which I have in my system.

https://www.anandtech.com/show/11598/asus-launches-xgc100c-10-gbe-adapter-aquantia-aqc107-99

It works fine however jumbo frames is broken until unraid gets kernel 4.14. Not a big deal. 

Jumbo Frames shouldn’t be implemented unless you 400% know what you’re doing.


Sent from my iPhone using Tapatalk

@dlandon just out of interest, is your NIC/Switch setup for RSTP? 

3 hours ago, miniwalks said:

@dlandon just out of interest, is your NIC/Switch setup for RSTP? 

It must be because I have some hard wired cameras using RTSP.

It must be because I have some hard wired cameras using RTSP.

 

I think you’re not talking about the same thing :-)

RTSP = Real Time Streaming Protocol

RSTP = Rapid Spanning Tree Protocol

 

 

unRAID 6.4rc14

38 minutes ago, tstor said:

 

I think you’re not talking about the same thing :-)

RTSP = Real Time Streaming Protocol

RSTP = Rapid Spanning Tree Protocol

 

 

unRAID 6.4rc14

Sorry.  Yes it is on.  I don't know anything about it.  Does it need to be  on?