A plugin to extend the autostart options for docker applications.

 

This plugin will give you the option to explicitly select the order that docker apps will start up in (useful if one app depends upon another to be up and running), and also gives you selectable delays between starts of each app ( to give the first app time to get up and running properly, or to reduce disk thrashing by only trying to load a single app at a time vs loading 10 simultaneously)

 

Each app has a selectable start delay after the previous app in the list starts up (defaults to 5 seconds, but can be set to any value, or no delay at all)

 

Note that any app which this plugin manages will appear on the normal Docker Containers screen as having autostart off

 

You can also combine management of autostart between unRaid itself, and this plugin.

 

Note:  This plugin requires unRaid 6.3.0-rc2+  It will not install under any previous version, and CA will not display this plugin as being available on incompatible unRaid versions

 

Install this plugin via CA ( search for Docker autostart)

Edited August 18, 20196 yr by Squid

Reserved

6.3.0-rc4 installed, icon does not show up settings, but can get to settings via ca-app, settings button for the module

 

 

Thanks

Myk

 

 

No icon for it in settings.  You'll see it in the docker tab

 

Sent from my LG-D852 using Tapatalk

 

 

Note that any app which this plugin manages will appear on the normal Docker Containers screen as having autostart off

 

No they don't. Should we manually set the Autostart value to off for the containers the app is managing?

Unraid ver 6.3.1, app ver 2016.12.17

 

You have to refresh the page.  They are set to not autostart

 

- Added ability to wait for a port to become active before carrying on.  The timeout / delay is how long to wait for the port to come alive.  After that is exceeded, then the system will continue on with starting other apps.

 

- If port is not specified, then operation is as before:  Delay followed by starting

On 2/18/2017 at 9:54 PM, Squid said:

 

- Added ability to wait for a port to become active before carrying on.  The timeout / delay is how long to wait for the port to come alive.  After that is exceeded, then the system will continue on with starting other apps.

 

- If port is not specified, then operation is as before:  Delay followed by starting

Cheers man, that's exactly what was missing.

Cheers man, that's exactly what was missing.

Actually though in further testing it doesn't quite work as docker automatically makes the port available as soon as the port is mapped. Tonight's update changes the detection method and also allows for the port checked to be on a different host

Sent from my LG-D852 using Tapatalk

 

- Updated to properly detect when a port has been opened prior to proceded

- Side benefit is that now the port detection can be from any server (or if you happen to have your docker container arranged such that each has a separate IP) - The plugin will default to what it believes is your local IP address, but I am unable to test in a bonded environment, so confirm the value first.

I have one question in regards this plugin.

 

When you move a docker app over to be delayed it has an IP but has NA in the port section.

 

Does that mean I have to give it the correct port or will it use the default ports?

Edited August 3, 20178 yr by JWMutant

I have one question in regards this plugin.
 
When you move a docker app over to be delayed it has an IP but has NA in the port section.
 
Does that mean I have to give it the correct port or will it use the default ports?

If you don't give it a port to check against then it uses the timer

Sent from my LG-D852 using Tapatalk

Thanks very much for answering me so quickly.

 

One last question on this plugin. Does the timer start from when you start the array or does the timer start once the array has started?

 

Odd question I know but Im going to be running up a pfsense VM and want my times to be right.

After the array is started

Sent from my LG-D852 using Tapatalk

Are the errors anything to worry about? And I assume the time delay is in seconds?

I'll have to look at it.  What version of unRaid?

6.3.5

If you need any log's from me just give me a yell.

1 minute ago, JWMutant said:

6.3.5

If you need any log's from me just give me a yell.

First question though is the array started?  Can't look at the code until late tonight.

Yea array was started. Has been for 3 odd days now, no rush I still need to get a dual NIC before I need the autostart.

On 8/4/2017 at 7:43 AM, JWMutant said:

Are the errors anything to worry about? And I assume the time delay is in seconds?

Error displayed now fixed (appeared if all containers set to managed start).  Time is in seconds.

 

Update available

On 8/3/2017 at 4:31 AM, JWMutant said:

Does that mean I have to give it the correct port or will it use the default ports?

And to clarify the IP / Port setting.

 

Application gets started.

System waits until IP:Port is active.  If it's not active during the time delay, the system carries on with the next app.

 

The IP and Port does not have to be the IP / Port of the application itself.  You can set the IP Port to listen to a completely different server (or anything on the web) before carrying on to the next application.

Can I check I'm setting this up correctly please.  I have a pfSense VM and I'm hoping this will speed up/smooth my start-up times by making dockers wait until the VM is running before trying to start.

 

 

What I'm trying to achieve here is:

1. Don't start beets for 5 mins unless internet is up - does't need net until I use it
2. If internet still not up, wait another 5 mins before starting maria db - doesn't need the net.  Otherwise, start immediately???
3. If internet still not up, wait another 5 mins before starting minos. Otherwise, start immediately???
4. If internet still not up, wait another 5 mins before starting maria db. Otherwise, start immediately???
5. Ditto with sabnzbd
6. After all these potential delays have played out, my unifi docker will come online so my wifi devices can start picking up IPs

Thanks

 

20 minutes ago, DZMM said:

Can I check I'm setting this up correctly please.  I have a pfSense VM and I'm hoping this will speed up/smooth my start-up times by making dockers wait until the VM is running before trying to start.

 

 

What I'm trying to achieve here is:

1. Don't start beets for 5 mins unless internet is up - does't need net until I use it
2. If internet still not up, wait another 5 mins before starting maria db - doesn't need the net.  Otherwise, start immediately???
3. If internet still not up, wait another 5 mins before starting minos. Otherwise, start immediately???
4. If internet still not up, wait another 5 mins before starting maria db. Otherwise, start immediately???
5. Ditto with sabnzbd
6. After all these potential delays have played out, my unifi docker will come online so my wifi devices can start picking up IPs

Thanks

 

Without filing in the port number, how you've got it will result in a strict time delay between containers.  I would guess you need to put in 53 into all of the ports (but leave unify with no port entered)

9 minutes ago, Squid said:

Without filing in the port number, how you've got it will result in a strict time delay between containers.  I would guess you need to put in 53 into all of the ports (but leave unify with no port entered)

thanks - will do.

 

Perfect solution for me as hopefully it will help my pfsense VM start sooner and also stop some of the problems I have with devices trying to do stuff online prematurely.

Just now, DZMM said:

thanks - will do.

 

Perfect solution for me as hopefully it will help my pfsense VM start sooner and also stop some of the problems I have with devices trying to do stuff online prematurely.

unRaid will still try and update the templates for containers at every boot (which will fail of course), which takes some time before the VMs start up.  Many feature reqs about disabling that "feature"