Submitting a PR for check_reload_status

luckman212

edit: for visibility, updating this top post:

I put a downloadable check_reload_status-0.0.18.pkg together and wrapped it all up with the source and a bunch of notes at https://github.com/luckman212/check-reload-status

Before submitting a PR upstream, I'm looking for a few more testers!

So, as part of my debugging the RRD backend failures on 26.07 (which led to my rrd.inc patch that's looking good so far) I also encountered a CPU-eating bug with check_reload_status that probably dates back decades (see old redmines #14891 and #2555).

I have compiled, validated, and stress-tested a patch that's been running on my system for about 3 days now. I haven't been able to make it crash or hang the CPU

I'd like to submit a redmine and a PR with some writeup about this, but when I went to get started on that, I was confused. The pfsense/FreeBSD-ports repo that I would expect to submit to hasn't seen a commit in >6 months. It seems completely and utterly abandoned and dead.

Is that still the right place to send stuff like this? Has Netgate taken all development offline and out of sight? I hope that isn't true, if it is it's quite discouraging.

bmeeks

Neither the pfSense/pfSense nor the pfSense/FreeBSD-ports public GitHub repos have seen any activity for more than 6 months. In addition, the most recent RELEASE branch showing in both repos is RELENG_2_7_2. That is now two releases behind the current 2.9.0 CE branch.

luckman212

So, what is one to do?

bmeeks

I honestly don't know. It becomes quite difficult to create new, or maintain existing, packages if you can't have a "truly native" build environment. It can work sometimes, but now without the most recent code changes that have gotten into CE since 2.7.2, you could quite easily create a regression trying to build with the outdated GiHub public repos.

And obviously this makes patch contributions from users very problematic because how can they be easily merged when the public branch they are based upon is so far out of date with the actual private Netgate branch?

luckman212

sorry to ping @jimp @cmcdonald but that was suggested by @stephenw10

…any thoughts on this would be appreciated.

jwt

@luckman212 already internally discussed, and @cmcdonald is going to take a look.

Thanks for the work

luckman212

@jwt Ok, thanks, but what about the check_reload_status patch? Should I just submit the PR against the code that's up there?

jwt

@luckman212 could, yeah.

The PHP has a lot of change occurring due to nexus.
There are also (largely unannounced) plans to reconvert CE and Plus.

luckman212

@jwt Alright - I didn't touch any PHP code - it's all C code straight from FreeBSD-ports for check_reload_status which I don't think has been looked at in years. It's soon to blow the victory horn but so far it seems to have fixed the spinlocks that I was hitting on my system. Interesting about CE/Plus convergence. Hope to hear more on that real soon now.

luckman212

I put a downloadable check_reload_status-0.0.18.pkg together and wrapped it all up with the source and a bunch of notes at https://github.com/luckman212/check-reload-status

Before submitting an actual PR I'm looking for a few more testers!

Gertjan

@luckman212

I've read your https://github.com/luckman212/check-reload-status and did all the steps.
What you've told in the readme and what I saw during install was identical.
I use a pfSense 26.07 on a 4100.
Now I'm running your version.

[26.07-RELEASE][root@pfSense.bhf.tld]/root: ls -al /usr/local/sbin/check_reload_status
-r-xr-xr-x  1 root wheel 36176 Sep 10 00:23 /usr/local/sbin/check_reload_status*

It's smaller as the original, Netgate's check_reload_status :

[26.07-RELEASE][root@pfSense.bhf.tld]/root: ll /usr/local/sbin/check_reload_status.orig
-r-xr-xr-x  1 root wheel 55144 Sep 10 08:35 /usr/local/sbin/check_reload_status.orig*

So far, 10 minutes in, I'm good.

The 'bad' news : I was never plagued with any of the issues that made you create this version.
I'll do some reboots et later on, and report back if I find 'something'.

Btw : big for the presentation of https://github.com/luckman212/check-reload-status

FireOdo

@Gertjan said in Submitting a PR for check_reload_status:

The 'bad' news : I was never plagued with any of the issues that made you create this version.

Thats the case for me too, and I'm running pfsense (CE) on this machine since ver. 2.4.5.p1 ... and never had issues with check_reload_status!

Thanks for your good work!
FireOdo

luckman212

@FireOdo and @Gertjan thank you both for testing this. If you weren't having issues before, then I'd appreciate if you could test a few scenarios manually:

a full reboot of your pfSense - make sure everything comes up normally
unplug your primary WAN cable, wait 10 seconds (or more) and then reconnect it - make sure your gateways recover back to ONLINE in the expected time
if you have multi-WAN, disconnect your primary WAN and make sure routing adjusts properly and recovers when you plug it back in

FireOdo

@luckman212 said in Submitting a PR for check_reload_status:

Hi,

a full reboot of your pfSense - make sure everything comes up normally

Everything came up as expected.

unplug your primary WAN cable, wait 10 seconds (or more) and then reconnect it - make sure your gateways recover back to ONLINE in the expected time

Yes, gateway back in expected time.

if you have multi-WAN, disconnect your primary WAN and make sure routing adjusts properly and recovers when you plug it back in

No multi-Wan here ...

So - GO from here!

Edit: The files in /usr/local/sbin "fcgicli" and "pfSctl" are different in size compared to the originals.

Regards,
FireOdo