Failed to create client object: Daemon not running
Closed this issue · 10 comments
As the title says, not sure what I'm doing wrong. This is my first time. Do note:
- Dropbear (app log): "fails"
- VNC (app log): "The X session exited with status 127! Killing Xtigertvnc process ID 29839".
- Pi-hole diagnosis (pi-hole log): "Long-term load (15min avg) larger than number of processors: 28.0 > 8
This may slow down DNS resolution and can cause bottlenecks."
To test, I added the everything list from the Blocklist Project, updated gravity, changed my phone's wifi connection's dns addresses to both pi-hole's and tried visiting https://nyaa.si using Chrome for Android and nyaa still loaded. Certain the domains were added, however, no clients are connected to the pi-hole. While I'm able to connect to the dashboard on a PC, the filtering doesn't seem to be properly working for me.
Let me know if you need anything else.
Hi, what is the make and model of your device?
Oppo A12 CPH2083. Btw, filtering now works. Turned off private DNS and set both DNS to the same one Pi-Hole is running on, and it worked but the errors above still stand.
EDIT: Spoke too soon. Not correctly working with Chrome on Android. Again, https://nyaa.si gets through on refresh of the blocked page. So, it will fail at first (sometimes it just goes through) and then a refresh will let it get through and is not even logging the site:
This issue is not specific to Pi-hole running on Android, but If I was to guess I'd suggest turning off IPv6 DHCP on your router.
See here for some other ideas on how to troubleshoot: https://www.reddit.com/r/pihole/comments/qr1txw/at_a_loss_about_android_chrome_not_using_pihole/
Hello, thanks for your response. I did try that (see screenshot) and is still having issues though ports 53 (regular DNS) and 853 (DoT) are left unblocked/unredirected because I can't find a setting block ports. A little help would be nice if you don't mind.
Also have DoH/VPN/TOR/Proxy Bypass list on my Pi-Hole's adlist but doesn't seem to work or I'm not doing it correctly.
Found it. Blocking ports 53 (TCP/UDP) and 853 (TCP) for all IPs except the PiHole in addition to changing both the Primary and Secondary DNS servers to the PiHole's and disabling the DHCPv6 server did the trick.
Hopefully, dropbear failing to start doesn't affect any functionality or decrease security. Yet to figure out how it affects my installation.
Anyway, for the EG8145V5 router, here's the config in case someone may find it useful in the future:
Are you able to RDP into the instance instead of SSH?
If so, you can edit Dropbear's configuration file to use a different port.
The high load average is normal to see on some Android devices and is only a cosmetic issue, see here: #84
Haven't tried SSH into the pihole. I'm monitoring through an app (DroidHole) or just configuring by accessing pi.hole/admin.
I'm able to RDP because I see the login screen but after entering the credentials, the session just crashes. I did redeploy it but it was already problematic prior because:
- random things fail in the console but not all at the same time - dropbear, lighttpd, vnc
dropbear ... failed
lighttpd ... failed
/home/android/.vnc/xstartup: 1: exec: startlxde: not found
==============================================================
Session startup via '/home/android/.vnc/xstartup' exited with status 127
Maybe try somethinng simple first, e.g.,
tigervncserver -xstartup /usr/bin/xterm
The X session exited with status 127!
Killing Xtigervnc process ID 8934... success
fail
- rdp crashes after logging in
- when pi-hole is started, it was no longer showing that part where it shows the system info and pi-hole/web/FTL versions
After redeployment, no new password was provided and the 3 issues persisted. I may need to uninstall Pi-hole for Android completely and reinstall the apk before redeploying. Will reboot first to see if that fixes no. 3 at least. EDIT: No, rebooting doesn't fix no. 3, vnc still exits and its process gets terminated
Agree... Uninstall the APK, reboot, re-install and create a New Deployment. It should give you a new password.
If you still have issues try the 32-bit image to see if that behaves any differently.
This worked and I was able to install and PIXEL desktop (audio works), would be great to have the readme reflect the updated commands.
- Are you going to investigate on why dropbear, lighttpd, vnc randomly fails or is any of them failing to start not a huge security concern?
- Is it normal to see "passwords do not match" in the logs after installing PIXEL desktop? What can be done to prevent the "Passwords don't match" error?
## graphics/vnc : do_start
:: Starting graphics/vnc ...
You will require a password to access your desktops.
Passwords don't match - try again
getpass error: Inappropriate ioctl for device
Password:Verify:Password:Verify:fail
- Is it fine that I'm getting certificate errors "The server name on the certificate is incorrect." and "The certificate is not from a trusted certifying authority." when RDP'ing? Can something like this or this solve the certicate errors? If so, will you incorporate it so that Pi Deploy automatically does generate LetsEncrypt and auto-renews, if possible at all?
- Even if "Lock screen", "Lock WiFi" and "Wake lock" are all enabled and Pi Deploy is set to Run in the Background, Pi Deploy still gets killed by Android. Whenever Pi Deploy gets killed and I launch Pi Deploy, the console says the "container is not mounted" if I press Stop but Pi-hole is still running in the background because pi.hole/admin is still accessible.
- After installing PIXEL desktop, I keep getting the below. Are they safe to ignore?
lighttpd ... 2024-05-06 19:02:42:(network.c.537) can't bind to socket: [::]:80: Address already in use
failed!
fail
cron ... cron: can't lock /var/run/crond.pid, otherpid may be 6538: Resource temporarily unavailable
done
I don't understand why VNC is trying to start, that's not even enabled or configured in the installer.
None of the 'errors' you mention is a security problem.
Regarding the container being killed, Google for "prevent oom killer android". None of my lab devices have this problem but it could be an issue with some devices. If the container is randomly killed, you will need to reboot the device for the container to properly come back up.