v1.5.15rc3 Bug Reports and Comments

[RebusCom]

RebusCom,

The fixes present in this rc address several general stability issue's.
If you can try this one out and let us know if you still see the problem, that would be helpful.

I don't see chains of switches linked together with RSTP (for our redundant links) spontaneously hard rebooting simultaneously across the network (cycling POE in the process for even more disruption) as a general stability issue. Is it safe to assume from your response that no cause has been identified or specifically addressed?

It's an uncommon occurrence (three times for us) so there's no way to know really if it's been fixed. It's just a ticking time bomb that is highly disruptive.

We haven't been bit by it since 2022 so I think I'll wait until 1.5.15 is fully released. I've been holding at 1.5.8 mostly due to the memory leak issue and it's 1.5.8 that's had the reboot issue so it's been a pick your poison...

[sirhc]

v1.5.8 is pretty old and has known issues some bad like memory holes.

RSTP is CPU required do if memory fills up and CPU spikes it could cause RSTP issues where it thinks a link is down as it is slop to get control packets.

I am not sure why you won't upgrade and see.

1.5.15 is about to re released which is just 1.5.15rc3

[troy]

Not so much a bug report, but a request... is it too late to add a snippet to /usr/bin/monitor to check memory usage for vtss_appl in the same way you're checking for shellinabox? Love to see this in the next release.

I can do this myself, but patching everything after every update is a pain.

Code: Select all

if [ `ps ax |grep vtss_appl |cut -b14-20|sort -nr|head -n 1` -gt 50000 ]; then
 logger -t monitor "restarting vtss_appl"
 /etc/init.d/vtss_appl restart
 fi


Not sure this is 100% sufficient though. This morning, even after restarting, one of the old threads persisted and had to be killed manually.

Thanks for your consideration!

[oeyre]

1.5.15 is about to re released which is just 1.5.15rc3

When are you expecting to release?

[sakita]

Is 1.5.15 final being released are there other updates being added? (e.g. Troy's script suggestion posted above).

I've been running 1.5.15rc3 in test and one production location with no issues noted...

[bipbaep]

Very quiet from Netonix as usual...

[gilljr]

In January, it was said that the release candidate was going to become 1.5.15 soon. It is the middle of April with zero comments in 3 months (a QTR). I wish milestones and other information would be presented. The way information is shared makes me want to run away rather than further invest in the product. I am sure I am not alone in that feeling.

[Stephen]

Not so much a bug report, but a request... is it too late to add a snippet to /usr/bin/monitor to check memory usage for vtss_appl in the same way you're checking for shellinabox? Love to see this in the next release.

I can do this myself, but patching everything after every update is a pain.

Code: Select all

if [ `ps ax |grep vtss_appl |cut -b14-20|sort -nr|head -n 1` -gt 50000 ]; then
 logger -t monitor "restarting vtss_appl"
 /etc/init.d/vtss_appl restart
 fi


Not sure this is 100% sufficient though. This morning, even after restarting, one of the old threads persisted and had to be killed manually.

Thanks for your consideration!

Just a quick note, there have been internal memory monitoring feature's added to try and handle issue's when vtss_appl grows. However, being that it is a core process that interface's with the switchcore. Restarting it like this will cause dropped frame's in certain situation's (for example, if you have any LAG's present on your system, because once it restarts vtss_appl will restart the LAG).

With that in mind, the internal memory monitoring that has been started in rc1 and refined up to this release attempts use a more fine tuned monitoring method interfacing with internal objects of vtss_appl and other process's in the system to try and handle memory related issue's. However, for known event's that cause leak's (like watchdog's, snmp, etc) those have just been fixed directly. From our own testing and the result's we've heard from the community so far it appears this has been successful.

There have been a few more improvements since then and we agree that more than enough time has passed. We wanted to make sure that we didn't see any core issue's related to the modifications that were done. But now, based on feedback, we are officially releasing 1.5.15.

Just as part of the routine, this forum thread will be locked.

Further discussion for feedback on 1.5.15 can be found here:
viewtopic.php?f=17&t=7996

And of course you can download the firmware here:
viewtopic.php?f=17&t=240

Thanks to everyone for their input.