So we’ve recently happened across an issue whereby we need to display state to a user. Back in the olden days, you used to be able to do an :led command but not so for ages now. The issue I have is that, if you wish to toggle an LED in a blink, that’s a
set type=on
and
set type=off
, both of which result in two flash block writes as it updates the config!
If I wanted a heartbeat (we’ve had a lot of failing power supplies recently and HB would be really useful!) i’d burn through my flash endurance in a couple of weeks.
So, more broadly, a way of toggling an LED without making state permanent would be great, but selfishly for me can I have a
You really have to explain to me what’s the point of making it flash when the power supply works…
Simply if it’s on it’s on, if it’s off it’s off…
It’s not that it takes that much.
And then eventually get them to send an email.
Is there anyone who stares at the LED all day if it flashes?
The way the power supplies have been failing ensure that the supply becomes sufficiently noisy to cause the unit to lock up. The LEDs remain lit, but the processor is stopped. Changing the PSU clears the fault and returns the unit to service. Cycling the bad PSU brings power and some ethernet LEDs back and it might get a bit through boot, but then it crashes again.
Long story short, we can enter a state where the unit appears on but is hard crashed and the watchdog isn’t cycling it.
I do not know what device you write about,
just set the led that blink with ethernet traffic and netwatch every 1 second one internal address, it blink the led at least every second, without using the flash.
Other comment
If the processor is locked, what do you think is going to toggle the led status ?
Not the processor…
Isn’t it best to use another device to check for responsiveness of device under test and only have it alert when something is wrong ?
I hate tests which are in 99.999% of cases just to inform all is ok.
I only want to know when it is NOT ok.
Then I want to see it. Preferably via mail.
Make them check on each other, so you know as well when the controller is out
OK, so the plan is, without having to educate anyone, to say “can you look at and tell me if it’s flashing”. The reason being the ethernet LEDs on some devices appear to be fed from the switch chip, not the CPU, so the link LEDs can still flash without CPU involvement. The lack of flash therefore narrows it down to this CPU issue without guessing.
We have devices that are on remote sites and don’t talk to us at all (and in fact don’t talk to the internet), so having on-site visual debug would be pleasant.
Anyway, that aside, just a way of toggling the LED without making a config change would be great as we have other system states that can be shown via flash code and indeed we used to have a reasonably comprehensive script that would do that easily. Writing bytes to flash storage just to blink an LED seems a bit silly.
I suppose you could use interface activity in /system/led and ping to do some. If you created something like a VETH only for this purpose, and pinged that IP in netwatch ICMP monitor… you might be able to mimic a blink by changing the frequency of the ping. Basically a loopback interface, just for LED. The purpose of the VETH is only to have a be able use activity monitor in LED, so likely want to isolate it firewall. Since your not explicitly setting the LED on/off in config, should not be a lot of flash writes.
I presume that when you configure the LED for “interface activity” on your internet port, that even when the actual port LED would be hardware controlled, this simulated activity LED is still being software controlled and would stop blinking when the processor crashes…
Maybe it still blinks when the processor has halted in the main program but still services interrupts?
Anyway, when this power supply problem is regular enough that you ask for this feature, it may be better to do some proactive remediation…
(i.e. swap the power supplies)
Yes, writing to flash just to save LED state is quite silly. I think this should be optional and have it’s own parameter (“save=yes” or something like that). In most cases when you are toggling a LED from a script, you are doing that to show some current state and having it saved is actually bad (you may have LED show VPN is connected, and you don’t want that saved so on reboot router starts with LED OFF again). So yes, please make some changes to this command Mikrotik…
Tend to agree that additional writes may not be that significant…but also agree ideally you’d be able to set the user/etc leds without using the flash. So some “save=no” seems a reasonable feature request.
