After a little bit of head scratching and a bit of luck I’ve found what is causing my issue. Even though I have the setting Wait for Network enabled the timeout doesn’t appear to be long enough. I have Cisco switches and they take up 60 seconds to initialize. Is there a way to extend the time OSMC waits for the network?
Increase the value of count=60, (for example to 120) save and reboot.
Any systemd services in /etc/systemd/system take precedence over the system supplied ones in /lib/systemd/system, so even if an update updates the original file your custom version will still be in effect.
We’re looking into whether a user defined delay should be a GUI option but haven’t decided whether it should be an adjustable timeout for the wait for network service, or a separate delay independent of network - it depends on the use case as to what is useful. (For example waiting longer for the network to come up doesn’t help if you’re waiting for a remote server to boot not the network itself)
I’ll have a go at making the change to see what works best for me.
To answer your question though, no I don’t turn off my switches. I’m running fully managed Cisco switches, they shutdown the port if there is no physical connection; ie the device at the other end of the cable is switched off, rebooted or the cable is removed. Once a physical connection is detected the port then initializes, this take time.
An alternative method would be to maybe ping the default gateway and wait for a response. At that stage you know the network is up and therefore any external access requirements will have a fighting chance.
Pinging the default gateway is not a general purpose method of testing a network is up - not all networks even have a default gateway, or if they do it may not respond to pings.
connman-wait-for-network.service already handles checking for the network being up by checking connman’s state - and connman has its own methods of checking whether the network is up which vary depending on whether it’s ethernet or wifi, and whether you’re using DHCP of Static addressing.
(For example on DHCP Ethernet it will wait for a valid response from the DHCP server before considering the network to be up - ethernet link level activity alone is not enough)
So we already check everything feasible to see if the network connection is up. That is not enough though if you are for example turning on a MySQL/NFS server at the same time as the Pi - the network may come up quickly but the server could take much longer to boot up and be ready to serve requests, hence for some people they might want a customisable arbitrary delay to allow their server time to boot up.
After digging around further I found the solution to my problem. I needed to enable PortFast on the switch ports that have a RPi connected. So with the delay suggested by DBMandrake and the improved response times from the switch all now well.
Strange that you needed to do any thing at all with your switch configuration - I’ve used my Pi’s on a variety of switches, both consumer and enterprise and never seen any issues like what you described.