OpenWrt Forum Archive

Topic: init.d script appears to have bricked my router.

The content of this topic has been archived on 16 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I have a simple application that I need to run at startup so I wrote a sysV script for it and enabled it with the priority S=65 (this has worked fine for other applications I've need to run at startup). I have confirmed that the application runs perfectly when started from a terminal, but it doesn't work when I include it at this stage in the startup process (I think something affects the file IO that it relies on as far as I can tell).

So I tried starting the script later by increasing the start value to S=100, after a reboot I lost all ability to communicate with the router (doesn't even respond to pings). Is this known behaviour, shouldn't you ever set the start value to over 99? I have read a number of guides and howtos on this area and none of them mention this problem. Does anyone have a suggestion where in the startup process I should run my application to ensure it works, I'm a little worried about experimenting with this now in case I lock myself out of any more routers.

Cheers.

Hi.

Due to the nature of alphabetical (not numerical) sorting, 100 will be the *first* script that is executed. Depending on the commands you have in your script, it might break things badly. You can, however, try to enter failsafe mode, connect with telnet, run mount_root and fix the script.

Regards,
JoW

Not sure how that could happen unless somehow 100 is running ahead of everything else and blocking.  But you still should be able to go into recovery mode and reflash.  However in the future:

Write a run once script:  before you execute any new thing, check to see if it's been run before.  If not, then write a flag in /etc before you start the app and run it.  If the flag in /etc exists, don't run it.  That way, you can run your app once, if it bricks, powercycle, and the next time it won't run.

Add a long delay:  put a sleep 300 in the startup before the app runs.  That gives you time to ssh in to the ap and see what happens when the app runs.

Thanks guys, I guess I just let my guard down because I'd been successful in the past, I'll make sure I'm more careful in future.

Heh.  I'm an epxert at bricking these things; I've learned the hard way.  I've bricked about 3 routers so far; been able to recover all of them via variously painful ways (jtag and such.)

Far easier not to brick them in the first place.  Although the newer routers seem to be more brick proof than the old ones. The trendnet BRP652 is especially nice; if you hose the install it automagically goes into failsafe - which has a web interface!  Nice....

The discussion might have continued from here.