NOTE before you read further : I couldn't solve or understand why this occurred so finally I stopped using rc.local and instead used a custom Initscript (check thread below) which as a secondary indirect method satisfied my usecase:
So, now I am asking this question not for my usecase need which is already satisfied by the secondary solution in above thread, but instead for understanding purpose/learning the reason and its fix and whether this is a bug in the implementation/executon of rc.local by OpenWrt.
.......................................................................
Background explanation of issue starts here:
1st try:
I disabled stock openwrt led initscript so that it doesn't interfere with power LED in switching it off during below execution, then I specified the below code in rc.local:
echo 0 > /sys/class/leds/green:lan/brightness
echo 0 > /sys/class/leds/green:wan/brightness
echo 0 > /sys/class/leds/green:wlan-2/brightness
echo 0 > /sys/class/leds/green:wlan-5/brightness
echo 0 > /sys/class/leds/green:power/brightness
1st outcome :
4 out of all 5 LEDs turn off on routor reboot but not the power LED.
2nd try:
I just added another line to check if this works:
echo 0 > /sys/class/leds/green:lan/brightness
echo 0 > /sys/class/leds/green:wan/brightness
echo 0 > /sys/class/leds/green:wlan-2/brightness
echo 0 > /sys/class/leds/green:wlan-5/brightness
echo 0 > /sys/class/leds/green:power/brightness
echo none > /sys/class/leds/green:power/trigger
2nd outcome:
(same as 1st outcome)
Till now, I tried everthing but coudn't resolve it. Any help is appreciated
No, I didn't, and I respectfully also don't know which UCI commands you are referring to, but I believe UCI permanently (by permanent I mean, writes data on flash instead of being volatile to reboot) changes/overrides the user settings, which I don't want
It flashes the boot Led during boot up and sets the running Led to solid once boot has finished.
In your case, using rc.local, you are trying to alter the state of the power Led during boot up. That will work until the boot is finished and then the Led is set to solid, negating any action you took with it since the boot and running Leds are the same.
Sorry, but I didn't understand any of this and don't know about DTS file, so can you elaborate please ?
Yes, this is the observed behaviour in my case with the device I own, except that the power led does not turn off during boot process but blinks as you said and then after boot completion glows continuously instead off turning off according to supplied command.
But then during the same boot process how is Initscript able to do the same task, but not rc.local ? As executions of Initscripts also are part of the boot process :
O, this one!? Yes it works since long back already but I am searching to solve this rc.local issue specifically to learn and fix it, so the priority of me opening this thread is only rc.local issue as I have already explored all alternative tricks and methods but thanks for helping me
I interpreted this : Both Initscripts and rc.local are parts of boot process and according to what I interpreted from @Dairyman both will not work until the boot process is unfinished, so why does Initscript also not work? It should also not work, right ?
They aren't. The Initscript is controlled by a cron job (ie. a timer) which is run at set times after the router is up and running. rc.local is run at some point during, but not at the end, of booting up. This is a major difference.
The DTS file is a file that contains all the information about the router that the build system needs to create the firmware. It has things like which GPIO control which Leds, the amount of flash memory and how this memory is partitioned and much more.
Builtin to OpenWrt is a feature that allows a specified Led to blink during bootup and one which will make a Led go solid at the end of boot. These don't have to be the same Led but usually are. In your case the power Led is set to blink during boot and go solid at the end.
You can make changes to the power Led behavior during boot by using rc.local but OpenWrt will still set it to solid when boot is over. Any changes you want to make to this Led have to be done after boot is finished. This is what your Initscript is doing. as it runs after boot is finished.
Thanks for explaining about DTS file, it was needed.
O, so this is the actual backend working. This explains quite a lot. So, in essence I can conclude that rc.local will never work the way I want for power LED. Right ?
So, as an alternative resolve can I know the location of the code in my firmware where I can make a change to modify this behaviour a/c to my need :
Actually I was initially testing this in rc.local and all LEDs worked except power LED, which I then finally left and used Initscript instead as final solution :
But when I became curious and wanted to understand the reason and find a fix, I asked my query here and just mentioned the issue caused of following commands not having effect in rc.local :
Also, as far as I remember, after careful testing I learnt that stock Openwrt's led Initscript when kept Enabled didn't allow all 5 LEDs to turn off by rc.local. So when I disabled led Initscript, 4 out of 5 LEDs were turned off by rc.local but power LED is still left on. But since I disabled the led Initscript, I also added a command to start the Initscript led if not between 9PM and 3AM which is as follows :
After executing the commands in /etc/rc.local, another script is called:
# set leds to normal state
. /etc/diag.sh
It sets the state of the status_led (power LED) to solid green (booting is complete) and overwrites your setting. You can comment out this line (for testing purposes only) and most likely the power LED will turn off.
/etc/init.d/done has a START value of 95, while your init script has a value of 97, which means it runs later.
Thanks.
I am not experienced, there are other people who deeply understand systems and better suit this like @pavelgl and others.
I know it seems easy for using cronjob but its good until I am not touching the routor or not having a power shortage (manually rebooting it or a power failure after it turns off it LEDs a/c to cronjob or else LEDs will turn on even after the time set in cronjob for turning off LEDs after reboot)
Enlightening! First I tried START value of 97, then 96, then 95 and Initscript was working until now. Shifted to START value of 94 and Initscript stopped working, just as you explained
Commented out the . /etc/diag.sh, and power LED turned off even with rc.local commands. You are genius. You again solved the reason for this issue too in the end.
Thank you. I am grateful
And this is why on putting stock led Initscript to Disabled state, 4 out of 5 LEDs turned off using rc.local.
Also, when I was testing (Disabling) done Initscript I had already kept Disabled the led Initscript so that it does not interfere, thats why the outcome
When I commented out . /etc/diag.sh, all happened the same way like the fast blinking then the slow blinking. Only difference was after blinking stopped, instead of continuous on state of power LED, it turned off fully which i loved
Now, deriving from this, if the diag.sh is not concerned with anything other than LEDs then can I leave it commented out if it isn't dangerous to the system in any other way ? Or do I need to do some other modifications ?
Because I would prefer rc.local over Initscript because its more comfortable/easier to set commands through LUCI web login's rc.local on any operating system's web browser instead of using SCP protocol using some SCP client to modify Initscript in the firmware / directory of routor and be concerned about the pos2unix conversions during modification of scripts also
Now when I am looking at both @Dairyman 's and @pavelgl 's statement, I think @Dairyman was trying to mean the same as @pavelgl but didn't go in full detail so i didn't understand at that time but now its seems same because led-boot = &led_internet; led-running = &led_internet; referred by @Dairyman is present in the diag.sh script referred by @pavelgl :
