Who Maintains this Package/How Do I File a Bug Report
-
@stephenw10 said in Who Maintains this Package/How Do I File a Bug Report:
Open a bug report here: https://redmine.pfsense.org/projects/pfsense-packages
Include steps to replicate it. Link back to here if you like.
It's pretty easy to make a pull request for a one line change like that. You can do it all from inside the github web interface.
Steve
OK, I took my best shot at creating the bug report:
https://redmine.pfsense.org/issues/11098
and I attached my best attempt at a fix (only change is line 57)Now what?
Sorry I know nothing about github, and I don't have a non-production system for testing, so my changes hasn't even been syntax checked.
-
That bug report looks fine. jimp has corrected the project and category.
Now we, or someone else, verify the issue and test the fix. Status changes to 'confirmed'.
Then create an actual patch and file a pull request in github (or our internal gitlab server).
That gets reviewed and if no changes are required it gets pulled in and a new package is built.
That becomes available on the package repo.
This is not a hardware issue so you should be able to test it pretty easily in a VM.
Steve
-
I can't replicate this. How exactly did you configure it?
I'm testing it with:
And it completes OK. The backup file is omitted.
Steve
-
Mmm, tried a bunch of things here and can't reproduce. The backup file is omitted from the backup every time.
What exactly was the error you saw here?
Why do you think it's trying to recursively backup itself?
Steve
-
@stephenw10 said in Who Maintains this Package/How Do I File a Bug Report:
Mmm, tried a bunch of things here and can't reproduce. The backup file is omitted from the backup every time.
What exactly was the error you saw here?
Why do you think it's trying to recursively backup itself?
Steve
Your configuration is correct. I experienced this problem a while back (2.3 or 2.4), and gave up on using the package. When I ran it with /root, it generated a infinite size tar that only stopped when all space was gone.
I didn't see any sign of changes so I just assumed the problem still existed. As I mentioned earlier, I have no way to test other than my production firewall.
Maybe I had/have had a recursive link that caused the problem. I'm so very sorry for wasting your time, it appears that you should close the case.
-
Ah, OK. Then, yeah, test the current package version in 2.4.5p1 if you can.
Excluding the backup file specifically doesn't seem like a bad idea though. The pull request is already in so it will likely be included. You may have hit some edge case that this will prevent.
Steve
-
@stephenw10 said in Who Maintains this Package/How Do I File a Bug Report:
Ah, OK. Then, yeah, test the current package version in 2.4.5p1 if you can.
Excluding the backup file specifically doesn't seem like a bad idea though. The pull request is already in so it will likely be included. You may have hit some edge case that this will prevent.
Steve
Thanks Steve, I'll give it a try when I get a window that I can afford to have the firewall crash. I was wondering if it would be safe to kill the tar job if I run into a problem?
I don't have much experience with FreeBSD other than what little bit I have to do at the command line with pfSense/FreeNAS. As a developer do you know if tar has built in protection to prevent a recursive backup?
-
If it gets stuck creating an ever larger file then killing the tar job should be safe enough. The alternative is the not kill it and it will fill the drive with all the problems that brings!
I always test in a VM first. Restoring a snapshot is very easy.
I cannot tell you what prevents it including that file currently, just that it didn't include it in any test that we did. It does fail if you try to backup
/(the entire filesystem) but it fails because you hit the 512MB limit on the php process running it. My own coding skills are....limited!But as I say adding that exclude switch seems like a good idea anyway. I can only help if there is some edge case that would otherwise cause recursion.
Steve
-
@stephenw10 said in Who Maintains this Package/How Do I File a Bug Report:
If it gets stuck creating an aver larger file then killing the tar job should be safe enough. The alternative is the not kill it and it will fill the drive with all the problems that brings!
I always test in a VM first. Restoring a snapshot is very easy.
I cannot tell you what prevents it including that file currently, just that it didn't include it in any test that we did. It does fail if you try to backup
/(the entire filesystem) but it fails because you hit the 512MB limit on the php process running it. My own coding skills are....limited!But as I say adding that exclude switch seems like a good idea anyway. I can only help if there is some edge case that would otherwise cause recursion.
Steve
Looking at the code, unless tar has built-in recursion protection (which is possible), I don't understand why it isn't causing problems.VM is clearly the way to go, I'm just not in a position to set one up now.
-
VBox on a desktop works well for a test like this. I used it for years until I got Proxmox setup.
Steve
