My array is taking over 20min to start,is this normal?

normally no.

 

depending on your configuration, yes, it is quite possible.

Edited December 19, 20178 yr by 1812

Most likely is that the server doesn't have an internet connection during boot up and the docker subsystem takes forever to come alive when that happens

3 hours ago, Squid said:

Most likely is that the server doesn't have an internet connection during boot up and the docker subsystem takes forever to come alive when that happens

 

why do we not have a fix for that yet?

1 hour ago, 1812 said:

 

why do we not have a fix for that yet?

Because everybody should have rock solid internet available to their server at all times. It's 2017 don't you know.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(obviously it's a pretty low priority to fix something that doesn't directly effect some of the devs)

1 minute ago, jonathanm said:

Because everybody should have rock solid internet available to their server at all times. It's 2017 don't you know.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

(obviously it's a pretty low priority to fix something that doesn't directly effect some of the devs)

 

It only affects me because I run pfsense in a vm. Like many others. So.... yeah..... otherwise my internet is rock solid.

Just now, 1812 said:

It only affects me because I run pfsense in a vm. Like many others. So.... yeah..... otherwise my internet is rock solid.

My tongue in cheek reply was because I don't believe people who choose to run unraid segmented off from the internet should be punished. It''s been a sore point for a while now, pretty much since Tom said he would never in the foreseeable future require people to connect to the internet to run a fully licensed copy of unraid, but hasn't fixed it so that those who choose to keep it segmented have the same user experience as those who don't.

1 minute ago, jonathanm said:

My tongue in cheek reply was because I don't believe people who choose to run unraid segmented off from the internet should be punished. It''s been a sore point for a while now, pretty much since Tom said he would never in the foreseeable future require people to connect to the internet to run a fully licensed copy of unraid, but hasn't fixed it so that those who choose to keep it segmented have the same user experience as those who don't.

 

o i c

7 minutes ago, 1812 said:

 

It only affects me because I run pfsense in a vm. Like many others. So.... yeah..... otherwise my internet is rock solid.

I've cobbled together a very ugly temp fix here 

it delays the start of docker to allow the pfsense vm to boot faster

@DZMM @1812

 

Stop jerking around with ugly hacks.  Try this instead.

 

Copy the attached file onto the root of the flash drive

 

Edit /boot/config/go and add the following lines before the line that says emhttp, and after the #!/bin/bash

 

cp /boot/dockerupdate.php /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php
chmod +x /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php

You'll have to reboot for it to take effect.

 

This fix checks for connectivity to github prior to attempting to determine if the containers have updates available for them.  (Github is where the repositories are stored)

 

Without this fix, your VM's never start until all of the cumulative timeouts are reached which could be quite a while.  Let me know if this works for you and I'll put in a pull request to LT for the next revision.

 

Note:  Attached file only tested on 6.4.0-rc17b.

 

dockerupdate.php

 

Edited December 19, 20178 yr by Squid

I've had this happen before on unclean shutdowns. I would ssh in and check the mnt directory. My drives would slowly show up one by one. The more drives you have, the longer it would take. It took around 20 mins for me before.

1 minute ago, mgworek said:

I've had this happen before on unclean shutdowns. I would ssh in and check the mnt directory. My drives would slowly show up one by one. The more drives you have, the longer it would take. It took around 20 mins for me before.

This happened routinely with Reiserfs drives, replaying transactions could take AGES. I've not seen the extremely long mount times with XFS, maybe I just haven't hit the right (bad) combination?

1 minute ago, jonathanm said:

This happened routinely with Reiserfs drives, replaying transactions could take AGES. I've not seen the extremely long mount times with XFS, maybe I just haven't hit the right (bad) combination?

 

ah, that makes sense. I never realized that. Until recently all my drives were Reiserfs. I just started replacing them XFS.

2 hours ago, Squid said:

@DZMM @1812

 

Stop jerking around with ugly hacks.  Try this instead.

 

Copy the attached file onto the root of the flash drive

 

Edit /boot/config/go and add the following lines before the line that says emhttp, and after the #!/bin/bash

 

cp /boot/dockerupdate.php /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php
chmod +x /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php

You'll have to reboot for it to take effect.

 

This fix checks for connectivity to github prior to attempting to determine if the containers have updates available for them.  (Github is where the repositories are stored)

 

Without this fix, your VM's never start until all of the cumulative timeouts are reached which could be quite a while.  Let me know if this works for you and I'll put in a pull request to LT for the next revision.

 

Note:  Attached file only tested on 6.4.0-rc17b.

 

dockerupdate.php

 

 

I will try this tomorrow!!!!

13 hours ago, Squid said:

@DZMM @1812

 

Stop jerking around with ugly hacks.  Try this instead.

 

Copy the attached file onto the root of the flash drive

 

Edit /boot/config/go and add the following lines before the line that says emhttp, and after the #!/bin/bash

 

cp /boot/dockerupdate.php /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php
chmod +x /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php

You'll have to reboot for it to take effect.

 

This fix checks for connectivity to github prior to attempting to determine if the containers have updates available for them.  (Github is where the repositories are stored)

 

Without this fix, your VM's never start until all of the cumulative timeouts are reached which could be quite a while.  Let me know if this works for you and I'll put in a pull request to LT for the next revision.

 

Note:  Attached file only tested on 6.4.0-rc17b.

 

dockerupdate.php

 

I can only ugly as I don't know how to code!

 

Will try this later when no-one is using the server

it has a internet connection while array starting

23 hours ago, Squid said:

Most likely is that the server doesn't have an internet connection during boot up and the docker subsystem takes forever to come alive when that happens

 

13 hours ago, Squid said:

@DZMM @1812

 

Stop jerking around with ugly hacks.  Try this instead.

 

Copy the attached file onto the root of the flash drive

 

Edit /boot/config/go and add the following lines before the line that says emhttp, and after the #!/bin/bash

 

cp /boot/dockerupdate.php /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php
chmod +x /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php

You'll have to reboot for it to take effect.

 

This fix checks for connectivity to github prior to attempting to determine if the containers have updates available for them.  (Github is where the repositories are stored)

 

Without this fix, your VM's never start until all of the cumulative timeouts are reached which could be quite a while.  Let me know if this works for you and I'll put in a pull request to LT for the next revision.

 

Note:  Attached file only tested on 6.4.0-rc17b.

 

dockerupdate.php

 

 

Just added this modification (on 6.4.0_rc17b as well) and it booted the vm with no apparent delay, as I have always thought it should. AMAZING!THANK YOU @Squid! Now, we should get @limetech to incorporate this as either default or as a toggle option. ( @AnnabellaRenee87 )

4 minutes ago, 1812 said:

Now, we should get @limetech to incorporate this

I don't see that as a problem.  

@Squid That mod helps so much, Thanks <3

Looks like @limetech has decided to not invoke dockerupdate.php at startup in the next rev of unRaid (which is the changes I originally wanted to make but was unable to since that was part of the proprietary code).

 

If you're applying this patch on rc17b, then make sure to undo the changes you're making to the "go" file when that version comes out.

16 minutes ago, Squid said:

Looks like @limetech has decided to not invoke dockerupdate.php at startup in the next rev of unRaid (which is the changes I originally wanted to make but was unable to since that was part of the proprietary code).

 

If you're applying this patch on rc17b, then make sure to undo the changes you're making to the "go" file when that version comes out.

 

either way i guess. still good news. but thank you again for the fix, albeit now temporary!

@Squid just did a reboot - worked perfectly.  Thank you!

On 2017-12-19 at 4:40 PM, Squid said:

@DZMM @1812

 

Stop jerking around with ugly hacks.  Try this instead.

 

Copy the attached file onto the root of the flash drive

 

Edit /boot/config/go and add the following lines before the line that says emhttp, and after the #!/bin/bash

 

cp /boot/dockerupdate.php /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php
chmod +x /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php

You'll have to reboot for it to take effect.

 

This fix checks for connectivity to github prior to attempting to determine if the containers have updates available for them.  (Github is where the repositories are stored)

 

Without this fix, your VM's never start until all of the cumulative timeouts are reached which could be quite a while.  Let me know if this works for you and I'll put in a pull request to LT for the next revision.

 

Note:  Attached file only tested on 6.4.0-rc17b.

 

dockerupdate.php

 

 

Hi Squid or anyone else,

 

Would this by any chance fix this problem that I am having each time I boot the server.

 

See attached image.

 

 

1 hour ago, Limy said:

 

Hi Squid or anyone else,

 

Would this by any chance fix this problem that I am having each time I boot the server.

 

See attached image.

 

 

Only if you're running pfSense as a VM  Alternatively, your router etc might just be painfully slow to assign an IP address to unRaid

I just recently had this issue when replacing my motherboard on UnRaid. My final solution was to pre clear the drives, then restore from the backup I made before replacing the motherboard. It has been working great since.