Member Avatar for henks

I just upgraded my 11.1 to 11.4

I need to run some shell script from a certain server everytime I power on the computer. So I added some bash script in /etc/init.d/ :

wget 
bash bashfile
rm -rf bashfile

this code run just well on 11.1, but after i upgraded it to 11.4, the following error occurs:

Connecting to some.web:80... failed: No route to host.

so then i tried to manually run the script after i logged on, and it runs perfectly! My guess is that the network wasn't up yet when the code run (yeah, i just made sure of it by inserting

ping -c 2 some.web

into the file, which resulting Destination Unreachable)

Any suggestion please? :(

  • 2 Contributors
  • 4 Replies
  • 307 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by henks

Dani AI

Generated

This is a timing problem: the boot-time script ran before the system had a usable network path, so the fetch failed even though the same commands work once the desktop is fully up. ’s quick fix (a fixed delay) proves the diagnosis, and was right to point at interface/DHCP timing as a common cause. On openSUSE 11.4 the traditional SysV init and the local hooks (boot.local / after.local) are what you’re dealing with, so a tiny race between init and the network stack is expected in some cases. (en.opensuse.org)

A more robust approach than a fixed sleep is to wait for a concrete sign that networking is usable (for example a configured default route) before trying to fetch/run remote content. Example (put this in your local script and set REMOTE_SCRIPT appropriately):

#!/bin/sh
# wait up to 30s for a default route
timeout=30
while [ "$timeout" -gt 0 ] && ! ip route show default >/dev/null 2>&1; do
  sleep 1
  timeout=$((timeout - 1))
done

if ip route show default >/dev/null 2>&1; then
  REMOTE_SCRIPT='/path/to/remote-script'   # set this before use
  /usr/bin/curl --fail --silent --show-error --location "$REMOTE_SCRIPT" -o /tmp/remote-script && /bin/sh /tmp/remote-script
fi

Checking the routing table with ip route is a reliable, scriptable way to detect "network ready." (stackoverflow.com)

If you prefer init ordering, install your job as a proper LSB-style init script with a Required-Start: $network header and enable it with chkconfig/insserv so the boot system orders it after networking. Example header fragment:

### BEGIN INIT INFO
# Provides: mystartup
# Required-Start: $network
# Default-Start: 3 5
### END INIT INFO

That lets the init tool handle ordering instead of ad-hoc sleeps. (forums.opensuse.org)

If the machine ever moves to systemd, the clean modern method is a oneshot unit that pulls in network-online.target (and, if needed, enable the distribution’s *-wait-online service so the target truly waits). This ensures the unit runs only after the network manager reports the network is up. (freedesktop.org)

Extra tips: log actions to a file or use logger for syslog while testing, and keep remote downloads in a tmp file and verify checksums before executing.

Recommended Answers

All 4 Replies

Member Avatar for rubberman

What OS is running on the server? Has it been updated recently? You also may want to see if your iptables firewall services are running, and if so, what the rules are that it is using. It may be that some of the firewall rules are affecting this.

Also, have you tried this after the system boots up, from a root command line?

Edited by rubberman because: n/a
Member Avatar for henks

I don't know about the server's OS, because i'm not the one maintaining it. But I'm sure it is one of linux distros. I turned off all of firewall services, so I think it's not firewall.
Yes I tried that after system boots up and it run just fine.

I finally added some delay before the wget function using

sleep 20

and that did the trick, although not at all in the fancy way. I might go further with checking networks services first before running these commands, though I don't know yet how.

Thanks for the reply rubberman :)

Member Avatar for rubberman

Well, it takes a small (but distinct) amount of time before your network interfaces (and other services) are up and running after they start. Adding a 20-30 second delay in the script isn't a bad idea, and if it works as you say, then I'd say that is an appropriate solution. BTW, is your workstation using DHCP to get a network address? If so, then that would explain the delay needed as it takes a bit of time for a DHCP client to obtain an address and set up the network appropriately.

Member Avatar for henks

The computer uses static addressing. Yeah, delay works for now i think :) thanks.. I will label this as solved :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.