Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNSCrypt-Proxy logs no longer available in WebGUI #2440

Closed
Aergan opened this issue Jun 23, 2021 · 24 comments · Fixed by #2467
Closed

DNSCrypt-Proxy logs no longer available in WebGUI #2440

Aergan opened this issue Jun 23, 2021 · 24 comments · Fixed by #2467
Assignees
Labels
bug Production bug

Comments

@Aergan
Copy link

Aergan commented Jun 23, 2021

After upgrading to 21.1.7 (and the 21.1.7_1 hotfix), sadly logs are no longer showing in the WebGUI for the DNSCrypt-Proxy (1.8_1)

Service is still operational and still working, just logs are absent from WebGUI.

OPNsense 21.1.7_1-amd64
FreeBSD 12.1-RELEASE-p18-HBSD
OpenSSL 1.1.1k 25 Mar 2021
Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz (2 cores)

@fichtner fichtner added the bug Production bug label Jun 23, 2021
@fichtner
Copy link
Member

use_syslog = false

Since logs are not redirected through syslog it's not unusual for this to break eventually. I have assigned the maintainer.

I'm not sure how this worked before, maybe only when CLOG is enabled?

Cheers,
Franco

@mimugmail
Copy link
Member

Maybe because of Phalcon4? The files on the system get updated.

@fichtner
Copy link
Member

Maybe phalcon strips the "-" from the action function name, but in that case we will never be able to guess the files on the disk.

@mimugmail
Copy link
Member

Removing "-" fixes it, I'm on it ..

@L1ghtn1ng
Copy link
Contributor

I'm hitting this as well, just noticed when trying to see what is getting blocked on the DNS

@L1ghtn1ng
Copy link
Contributor

Also this was down to phalcon4 as did not have this issue till it got upgraded

@Alien-hide
Copy link

Removing "-" fixes it, I'm on it ..

Can you describe in detail what and where to change?

@L1ghtn1ng
Copy link
Contributor

@mimugmail any update on this?

@upended
Copy link

upended commented Jul 2, 2021

Also experiencing this issue, is there an update on the fix?

@mimugmail
Copy link
Member

Not yet. Just tail the files via CLI to troubleshoot problems. They are only empty via GUI

@upended
Copy link

upended commented Jul 6, 2021

I have come across what appears to be a related issue. When using FW live view, and selecting "Lookup Host names" the entire website will crash become unresponsive. I have tested this in different way and found that no matter how the report is filtered (or not use any filter). If using 25 entries, the page is still usable for a few seconds, but then crashes. Using more entries has crashed the site faster.

The only way I have been able to recover (re-gain) access to the website is by using /usr/local/etc/rc.restart_webgui (Note: this is the first time I have come across this issue and did not experience it with the previous version 21.1.6. skipped 21.1.7)

To re-iterate, the crash happens when attempting to resolve the addresses. When using top, I can see dnscrypt-proxy climb towards the top (with very little CPU utilization) and then drop lower. I have not been able to determine the exact cause. The log files, back-end, general, nor web-gui showed any indication of the cause.

Can the users who are using DNS-Crypt please verify if they are experiencing this problem alongside the logging issue.

@upended
Copy link

upended commented Jul 6, 2021

Found a second possibly related issue. Interfaces:Diagnostic:DNS Lookup, does not produce any information when attempting to lookup. The page remains the same. The browsers' tab shows activity (waiting a response from server) but once it finishes, there is no data or error message. Nothing different that what was used to submit the lookup.

@Schenslo
Copy link

Schenslo commented Jul 9, 2021

I use OPNsense 21.1.5-amd64 on virtual machine to protect my network from my home, upgraded to version 21.1.7 and dnscrypt log stopped working. I returned to the previous version and upgraded to version 21.1.8 and the problem persists, again I returned to opnsense version 21.1.5-amd64 and later updated it -- Google Translater.

@adub08
Copy link

adub08 commented Jul 15, 2021

I've got the same issue, currently running OPNsense 21.1.8_1. I've got DNSCrypt-Proxy bound to port 5300 both ipv4 & ipv6, with forwarding from unbound. No logs since one of the recent updates.

@daverowlandson
Copy link

I also have this same issue, system is fully up to date. Happened after the 2nd to last update. Any workaround other than using the console? I used the GUI to view the logs frequently... Thanks.

@upended
Copy link

upended commented Jul 29, 2021

Cleared all logs, same result. Updated to 21.1.9 did not correct issue. Upgraded to 21.7 did not correct issue. Logs are still effected.

Are the fixes tested prior to release? This is not the first time I have come across a patch not working for the first attempt.

@mimugmail
Copy link
Member

The patch is not merged yet, why should an update fix it. Just execute the link command and thats it :)

@upended
Copy link

upended commented Jul 29, 2021

In the pull request, it states
"It's not directly related to operational issues so I would say this has to wait for 21.1.9."

Going back to the pull request I see now there is additional information which was not present the last time I had looked at it, (prior to 2 days ago).

@fichtner
Copy link
Member

fichtner commented Jul 29, 2021

If you want to coordinate a release like 21.7 just let me know so I can complain about things more on GitHub that I don’t like. ;)

In a seriousness, go to the shell and see the log. Please please please there are hundreds of more important issues right now and this fix will eventually make it into 21.7.x.

I need to do a code review, because I’m a little surprised that the fix is to set a symlink to a directory but that could potentially fail for users of clog.

So the question is: have YOU tested it? Does it work in all cases? If the answer is yes then we can go ahead.

@upended
Copy link

upended commented Jul 30, 2021

Yes I have installed the fix manually has instructed in your pull request. As far as testing, I have rebooted the FW, cleared the logs, restarted the service and rebooted again. The issue still exists on the FW.

I also pointed out in previous posts, it appears other areas are being effected. I had asked other to help test this issue as to confirm my finding (A minor lookup issue, and a second one which crashes the website. Copied below).

I have come across what appears to be a related issue. When using FW live view, and selecting "Lookup Host names" the entire website will crash become unresponsive. I have tested this in different way and found that no matter how the report is filtered (or not use any filter). If using 25 entries, the page is still usable for a few seconds, but then crashes. Using more entries has crashed the site faster.

The only way I have been able to recover (re-gain) access to the website is by using /usr/local/etc/rc.restart_webgui (Note: this is the first time I have come across this issue and did not experience it with the previous version 21.1.6. skipped 21.1.7)

To re-iterate, the crash happens when attempting to resolve the addresses. When using top, I can see dnscrypt-proxy climb towards the top (with very little CPU utilization) and then drop lower. I have not been able to determine the exact cause. The log files, back-end, general, nor web-gui showed any indication of the cause.

Can the users who are using DNS-Crypt please verify if they are experiencing this problem alongside the logging issue.

With respect to there being other issues, I do understand and agree. Case in point, I had found a legitimate bug where the VLAN MTU for interfaces were not being save as configured and it was acknowledge to be so. However, the issues was not resolved, nor marked as a bug as to capture more attention as requested(#4032).

Then there was another bug I found where, the ticket was closed and not reopened when requested as to allow time for testing. The original fix did not work and I had requested the ticket be reopened for proper tested which was denied (#4988). In that case the issue was resolved. In these experiences, you can see my statements are from someone who is working with the opnsense and attempting to help make better software. There is reason for my complaints not just from a whim but rather the previous experiences I have had trying to help.

@L1ghtn1ng
Copy link
Contributor

L1ghtn1ng commented Jul 30, 2021 via email

@upended
Copy link

upended commented Jul 30, 2021

I do not understand "as was getting moaned at by my partner to fix it quickly".

My posts stating I may have found other issues asked the community for testing/verification. I don't understand what your retort is aiming at.

@L1ghtn1ng
Copy link
Contributor

L1ghtn1ng commented Jul 30, 2021 via email

@upended
Copy link

upended commented Jul 30, 2021

I explained I had an issue which may be related. I wanted the community to know / test as other can be easily impacted which is why I did not ask any opnsense contributors to help or troubleshoot. Also, if this issue was another result from the main problem, you would want to know.

I also stated I had fixed the crash by restarting the service. Meaning the service was running again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Production bug
Development

Successfully merging a pull request may close this issue.

9 participants