Delaying Autostart

You could make a script something like:

#!/bin/sh

sleep 120 /usr/bin/chromium-browser --start-fullscreen \ --start-maximized --kiosk --hide-scrollbars --noerrdialogs \ --disable-default-apps --disable-single-click-autofill \ --disable-translate-new-ux --disable-translate --disable-cache \ --disk-cache-dir=/dev/null --disk-cache-size=1 \ --reduce-security-for-testing --app=http:///127.0.0.1:3030&kiosk

and then put the name of that script to be your autostart. This will delay starting Chromium for 120 seconds when xdg autostarts it.

Theo

Works perfectly

Many thanks

Instead of waiting for some fixed interval, you could add a prior command using wget or something to repeatedly try accessing that URL, say at 5 second intervals or whatever, until it becomes accessible, before allowing the startup to proceed.

For inspiration, I made a script to 'etherwake' a device and wait for it to get ready using wget in combination with the 'timeout' command. I run 'timeout 1 wget <url>' which returns an error if wget does not respond in 1 second, or wget returns an error itself. I use this in a while loop that repeats this until the wget succeeds:

etherwake -D -i ${IFACE} ${MACADDR}

while ! timeout 1 curl --noproxy \* "${URL}" &> /dev/null do echo -n . sleep 1 done

The OP could replace the 'sleep 120' in the other script with this loop.

Why waste a curl call when ping 8.8.8.8 would work with less overhead?

I was going to suggest something similar like that too. It is worth checking what the webserver is giving you - some services give a generic 'please wait while I start up' web page which may not be what you want. Maybe you need to ask for a specific page and count a redirect (to the 'please wait') page as a failure.

The purpose is to test a specific service *on this machine* has started up, not generic internet connectivity.

Theo

Will 'ping 8.8.8.8' return quickly (within 2 seconds) after my device has woken up? No. My device does not respond to 8.8.8.8. You are just testing internet connectivity, not the wakeup of my device.

And why waste a ping call (which is setuid) if a curl call will suffice AND tells if the port is responding to http(s) requests?

In other words: why waste a post when you don't understand the problem?

In my use case this was enough. You can also direct curl output to grep and use that as an indicator of your device's desired state.

Yeah. And curl is not *that* expensive to run. Maybe even less expensive than ping, as it does not have the setuid overhead. But who's counting clock cycles anyway?

-1 for assuming that internet connectivity is the only requirement.

Following up on myself: Okay, ping loads a bit quicker as it's executable is smaller and it loads less libraries, but it still is a setuid binary.

I must admit I still don't understand why you thing the overhead of calling curl is a waste. Both are external programs and we're in a wait loop anyway. Why hurry in between to sleep calls?

In this case curl beats ping, as OP's question was related to a slow staring Grafana server. Ping can't tell if Grafana is running. With curl you can see if a string is in the output.

Say for examplje you're waiting for a specific dasboard to load, with the title "Hootenmany". You could run this slightly modified version:

while ! timeout 1 curl -s ${URL} | grep -qs Hootenanny do echo -n . sleep 1 done

This will loop until curl returns something with the string 'Hootenanny' within 1 second and fail if there's no network, no dns, no route to the Grafana server or while Grafana server is still starting up.

And *that's* what the OP asked.

Accepted.