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

unbound: Fails to start because systemd-resolved is already running #1778

Open
mathieumd opened this issue Jul 23, 2021 · 1 comment · May be fixed by #2477
Open

unbound: Fails to start because systemd-resolved is already running #1778

mathieumd opened this issue Jul 23, 2021 · 1 comment · May be fixed by #2477
Labels
bug something is not working as expected priority: medium tag: DNS tag: good first issue work suitable for new contributors
Milestone

Comments

@mathieumd
Copy link
Contributor

Running the role debops.unbound on an Ubuntu 20.04 fails during the handler:

[...]
RUNNING HANDLER [debops.debops.global_handlers : Check unbound configuration and reload] ****************************************************************************************************************************
changed: [dns-resolver-test1]

RUNNING HANDLER [debops.debops.global_handlers : Reload unbound] ****************************************************************************************************************************************************
fatal: [dns-resolver-test1]: FAILED! => {"changed": false, "msg": "Unable to start service unbound: Job for unbound.service failed because the control process exited with error code.\nSee \"systemctl status unbound.service\" and \"journalctl -xe\" for details.\n"}

And indeed, Unbound can't bind on ports UDP/TCP 53 because systemd-resolve is still running:

root@dns-resolver-test1:~# ss -natup |grep 53
udp     UNCONN   0        0          127.0.0.53%lo:53            0.0.0.0:*       users:(("systemd-resolve",pid=40179,fd=12))                                    
tcp     LISTEN   0        4096       127.0.0.53%lo:53            0.0.0.0:*       users:(("systemd-resolve",pid=40179,fd=13))                                    

root@dns-resolver-test1:~# journalctl -xe -u unbound
[...]
Jul 23 09:54:35 dns-resolver-test1 unbound[146845]: [1627026875] unbound[146845:0] error: can't bind socket: Address already in use for 0.0.0.0 port 53
Jul 23 09:54:35 dns-resolver-test1 unbound[146845]: [1627026875] unbound[146845:0] fatal error: could not open ports
Jul 23 09:54:35 dns-resolver-test1 systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
[...]

Does I do something wrong? Or does the role should include some way to check port availability, and if they aren't, first stop and disable running process using these ports?

Adding tasks to stop and disable systemd-resolved in a pre_tasks section in the playbook is not a good solution because between the execution of these tasks and the role's, the host would fail DNS resolution, which could have dangerous consequences.

PS: Of course, manually stopping and disabling systemd-resolved works:

root@dns-resolver-test1:~# systemctl stop systemd-resolved.service 
root@dns-resolver-test1:~# systemctl disable systemd-resolved.service 
Removed /etc/systemd/system/dbus-org.freedesktop.resolve1.service.
Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
root@dns-resolver-test1:~# systemctl start unbound
root@dns-resolver-test1:~# ss -natup |grep 53
udp     UNCONN   0        0                0.0.0.0:53            0.0.0.0:*       users:(("unbound",pid=147942,fd=3))                                            
tcp     LISTEN   0        256              0.0.0.0:53            0.0.0.0:*       users:(("unbound",pid=147942,fd=4))                                            
tcp     LISTEN   0        256            127.0.0.1:8953          0.0.0.0:*       users:(("unbound",pid=147942,fd=8))                                            
@imrejonk
Copy link
Contributor

imrejonk commented Nov 4, 2021

The debops.unbound role should stop and disable the systemd-resolved service. We're not doing much testing on Ubuntu (DebOps targets Debian Stable), so this issue has slipped in unnoticed.

This is actually quite easy to fix, the role just needs a single task at the beginning that stops and disables the systemd-resolved service. Would you like to try a pull request for this?

@imrejonk imrejonk added bug something is not working as expected priority: medium tag: DNS tag: good first issue work suitable for new contributors labels Nov 4, 2021
@drybjed drybjed added this to the DebOps v3.2.0 milestone Aug 11, 2022
@4ijlnu 4ijlnu linked a pull request Mar 4, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something is not working as expected priority: medium tag: DNS tag: good first issue work suitable for new contributors
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants