Discussion in 'Tomato Firmware' started by nsap, Dec 4, 2011.
Does this process simply monitor for the SES/AOSS button to be pushed? Is it safe to kill?
I had the same question this week and found (in /proc/*PID*/fd/) that the "buttons" process also had a handle to /dev/nvram, so I decided it would be to much risk to kill it.
Also this process several times logged someone had pushed the SES button - which is physically not there... So I began to search how to get rid of this process.
The source code ("buttons.c" etc.) turned out that there are some bugs. My nvram always has the two variables "btn_override=" and "btn_reset=", but without values (check by "nvram show|grep btn"). This is not interpreted correctly by "buttons" in a way that GPIO bit 0 was the reset button. But there is a condition at the process initialization where it terminates because it thinks there is nothing to do. This way it is safe to get out and optimal if there is neither a SES nor a reset button on the router.
What to do:
Open a console session (perhaps enable SSH in admin interface prior).
Check the existing values in nvram regarding buttons: "nvram show|grep btn"!
"nvram set btn_override=1"
"nvram set btn_reset=16"
Reboot the device, next time there will be no more "buttons" process.
The value 16 (generally all values that have any bit of 0xffffff70 set) is interpreted as "invalid", so "there is no reset button". The "btn_reset" variable is read only if "btn_override" !=0.