Issues on cron updates

chrcoluk

1 - IPBL lists failing to download, my educated guess is that pfblockerng processes a unbound restart after downloading dnsbl, and then tries to download IPBL before unbound is up and responsive again.
2 - On last update unbound was left completely down, this was in the resolver log.

Jan 5 23:47:39	unbound	29826:0	error: cannot chdir to directory: (No such file or directory)
Jan 5 23:47:40	unbound	29826:0	fatal error: Could not read config file: /unbound.conf

Possible causes?

Again just guessing but.

1 - It tried to start too soon before config's dynamically generated.
2 - I have a modified services.inc to stop unbound been restarted on every wan6 dhcp renewal, the pfblockerng code however appears to not rely on the code I modified.

When I manually checked the unbound config it existed and wasnt corrupted, I was also able to start it fine from the gui.

RonpfS

Jan 5 23:47:39	unbound	29826:0	error: cannot chdir to directory: (No such file or directory)

This error has been present for a while, doesn't seems to impair unbound on my system. https://forum.pfsense.org/index.php?topic=120338

Jan 5 23:47:40	unbound	29826:0	fatal error: Could not read config file: /unbound.conf

It looks like it tries to load /unbound.conf instead of /var/unbound/unbound.conf

chrcoluk

I fixed

file pfblockerng.inc in /usr/local/pkg/pfblockerng

it was not setting chroot path correctly.

I changed start of line 1406 from

$chroot_cmd = "/usr/sbin/chroot -u unbound -g unbound / /usr/local/sbin/unbound-control

to

$chroot_cmd = "/usr/sbin/chroot -u unbound -g unbound /var/unbound/ /usr/local/sbin/unbound-control

so yes you are correct :)

I am guessing the reason this has been a non issue is that pfblockerng also causes a filter reload which will make pfsense by itself restart unbound.

BBcan177

Try the following command from the shell:

/usr/sbin/chroot -u unbound -g unbound / /usr/local/sbin/unbound-control -c /var/unbound/unbound.conf status

The code change you indicate above will error with:

chroot: /usr/local/sbin/unbound-control: No such file or directory

chrcoluk

command works, so chroot is supposed to be / but instead the bug is the config path alone is set incorrectly?

so my line 1406 is now

$chroot_cmd = "/usr/sbin/chroot -u unbound -g unbound / /usr/local/sbin/unbound-control -c {$g['unbound_chroot_path']}var/unbound/unbound.conf";

dont know why you had a variable to set the config as surely the path for unbound.conf is same on every pfsense box anyway?

Also if unbound is setup properly the unbound-control shouldnt need the config specifying on the command line, there is remote-control configuration supported in unbound although I know this is a pfsense issue rather than pfblockerng, as the core pfsense unbound config doesnt configure remote-control for unbound-control, neither does it properly use the chroot function of unbound.

chrcoluk

right neither of my changes are a fix.

unbound-control status works fine.

unbound-control reload reports ok but actually crashes the daemon and the log shows the unable to reload /unbound.conf.

So when I thought I fixed it, all that happened was the command failed to run and because unbound didnt actually crash it all seemed ok but no reload actually happened. I will keep debugging.

chrcoluk

Right finally got there.

The reload crashing is due to improper configuration by pfsense, unbound has to be started with the unbound.conf outside of the chroot, and then unbound will handle the changeover to the root path, when this is done then reload works properly. To fix this requires some work on core pfsense code.

So I implemented a alternate fix for pfblockerng.

My fix will shutdown unbound with unbound-control stop
wait 1 second
Then start it again

I tested with force DNSBL RELOAD in the gui and it does work.

I am attaching the modified file so you can examine and change as you feel fit, hopefully you will use the changed code.

output of relevant part of log looks like this now.

------------------------------------------
Assembling database... completed
Validating database... completed [ 01/06/17 14:24:28 ]
Restarting Unbound..... completed
DNSBL update [ 402834 | PASSED  ]... completed [ 01/06/17 14:24:43 ]
------------------------------------------

and in resolver log at same time

Jan 6 14:24:41	unbound	58955:0	info: start of service (unbound 1.6.0).

pfblockerng.inc.txt

pfcode

@chrcoluk:

Right finally got there.

The reload crashing is due to improper configuration by pfsense, unbound has to be started with the unbound.conf outside of the chroot, and then unbound will handle the changeover to the root path, when this is done then reload works properly. To fix this requires some work on core pfsense code.

So I implemented a alternate fix for pfblockerng.

My fix will shutdown unbound with unbound-control stop
wait 1 second
Then start it again

I tested with force DNSBL RELOAD in the gui and it does work.

I am attaching the modified file so you can examine and change as you feel fit, hopefully you will use the changed code.

output of relevant part of log looks like this now.
------------------------------------------
Assembling database... completed
Validating database... completed [ 01/06/17 14:24:28 ]
Restarting Unbound..... completed
DNSBL update [ 402834 | PASSED  ]... completed [ 01/06/17 14:24:43 ]
------------------------------------------
and in resolver log at same time
Jan 6 14:24:41	unbound	58955:0	info: start of service (unbound 1.6.0).

Why don't your discuss this with BBCan17, He is very nice to talk with.

chrcoluk

isnt that what i am doing here? or do you mean in private.

chrcoluk

no issues on the daily update cron with the modified code.

bole5

I am experiencing exactly the same issue. Oddly enough I also run on Braswell N3150 (Zotac CI323 Nano). Your fix worked for me too.

RonpfS

@bole5:

I am experiencing exactly the same issue. Oddly enough I also run on Braswell N3150 (Zotac CI323 Nano). Your fix worked for me too.

Is the fix still needed as per https://forum.pfsense.org/index.php?topic=125773.msg694952#msg694952

@bole5:

My problem is now solved after following advice from BBcan177.
It turns out that all includes in unbound.conf options need to point to the same folder: /var/unbound.

I had following in my configuration:

My domain overrides

server:include: /usr/local/etc/unbound/se-servers.conf

All I needed to do is to change the /usr/local/etc/unbound to /var/unbound, and unbound stopped crashing on "reload".

My domain overrides

server:include: /var/unbound//se-servers.conf

Thank you very much BBcan177 for this great package!

bole5

Yes. That fixed this problem for me. If your problem is not caused by the similar issue you can always modify pfblockerng.inc script and replace "reload" with stop, sleep and run sequence.

chrcoluk

that solution does make sense actually. :)

BBcan177

@chrcoluk:

that solution does make sense actually. :)

@chrcoluk, not sure if this issue if resolved for you? Are you still needing to modify the code?

chrcoluk

bbcan17 yep, I looked into the solution but the problem is pfsense itself adds an include pointing to a config in /etc, so I would have to mod the pfsense code to remove the mod on pfblockerng defeating the purpose of removing the mod.

I am planning to do a pull request to pfsense to make that include inside the chroot which if we are right will then solve the reload problem with pfblockerng.

chrcoluk

actually I see all the pfsense includes are using /var/unbound it was only my own which I have now moved.

I will test reload later today, and if that works then revert the pfblockerng code on my box to see if the cron's are good.

treeol

Hi there

Just registered to post my conclusion.

I had the same issue with my pfsense box v. 2.3.3.

Unbound-service was restarting very frequently, unbound worked, but due to the restart i had sometimes gaps where in some special cases services broke down / where not able to synchronize etc.

It was caused by dhcp which tried to register new leases or entries (not 100% what it exactly wanted to register) but i see a lot of dhcpv6 log-entries.

At the end i figured out that on my WAN interface that the configuration type of ipv6 was dhcp, after i switched it to none, all problems disappeared.

Why this configuration exactly caused this problem, not sure at this moment, i'm anyway not using actively ipv6.

I will post more information if i have them.

Hopefully this helps.

Cheers, treeol