I urgently need help. After last update the system stops. I manually rebooted my system. But during reboot, I got the following error:
unbound-control error: connection refused for 127.0.0.1:8953.
As a result, I can’t access the WEB interface and openvpn dosn’n work., what ist pretty disastrous.
What can I do, to make the port 8953 work?
With kind regards
Michael Buballa
this might help:
I searched for 8953:
https://community.ipfire.org/search?q=8953%20order%3Alatest
1 Like
What version did you update from and to?
also, what do you get when you see what is using that port? Run lsof -i tcp:8953 on the root terminal to see what it is.
it should look like this:
[root@pwrtower ~]# lsof -i tcp:8953
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
unbound 2045 nobody 5u IPv4 5267 0t0 TCP localhost.localdomain:ub-dns-control (LISTEN)
what I would try is run setup, change the hostname and see if this resets the unbound.conf file.
I personally don’t recommend updating but instead download new versions from the web site and install. The only updates that seem to work all the time is the ones that you get when you switch distributions to experimental.
8953 is the command line management for ubound. It can be changed if you want with the config statement control-port: 1234 in the remote-control section of unbound.conf . Which will get you going, but you need to refresh the DNS configuration and probably have to regenerate certificates too.
The standard stable update has worked for me every core update for at least the last 3 years, probably longer.
So i think your statement is incorrect. There may be corner case situations where things happen but the number raised in the forum compared to all the users updating that never flag an issue on the forum means those are the exception and not the rule.
It would be good if those users with those corner cases ran the Testing release.
Incidentally, there is no experimental repository. There us the stable, testing and unstable repos.
Unstable is for the devs doing testing on changes before they get to testing stage.
6 Likes
Hallo,
thank you for your help. I am using IPFire for a very long time, I think more than 10 years. It was the first time, I got that trouble.
I didn’t understand, why I should run the ‘Testing release’. Why do you think, it would help me right now?
With kind regards
MB
Hallo DM,
I do not know the version I updated from, maybe 187.
I tried the command you told me: " lsof -i tcp:8953"
It happened completly nothing, an empty line occured! Sorry.
I Think, I will copy the backup directory to an USB Stick, download a new IPFire Installation-iso and install the last stabel IPFire version to my machine. After
that I will use the last backup to restore the last running configuration.
Thank you for your help.
2 Likes
I was not replying to yourself but to @dr_techno who made the comment that the only releases that worked consistently were the experimental ones and not the stable ones.
I should have made my reply specifically to him as I am now making this reply to yourself (@mbuballa )
My apologies for any confusion caused by my post.
2 Likes
I should rephrase it that In the last year of Linux Main patches that some broke functionality, then fixed again its better to download the working iso from the site, then update the distro in ipfire to testing for the latest.
Its not a big deal, but Ubuntu experienced this when everything went 64 bit and some updates worked while other people the updates didn’t work or broke parts of it. And they have 35 programmers just for updates so if they had issues making update scripts I imagine lesser amount of people will have greater difficulty doing this same task.
I’m not knocking anyone’s ability, its just people should know if a lot of things are changed externally that is incorporated in the next version, sometimes its difficult to make a clean update. Especially if its a core item like Iptables.
Then you are in one of the linux main patches that effects 30% of the machines out there. That is why I recommended reloading and then updating to testing and Kernel 6.12.13 because of all the hardware patches that were done.
I am going to assume after April they are going to incorporate the latest version of the LTS in stable and this will not be an issue anymore.
IPFire uses the LTS!
2 Likes
Since you are so many cores behind
a fresh install is probably your best bet.
I find that if you stay current on updates there are fewer update problems.
So Best practice I would say befor a update is
backup and download backup to PC.
Download ISO from IPFire web site.
then update.
Prepare for the worst
Re installation takes very little time if all else fails.
and install backups
2 Likes
but it is way behind.
In my testing version of IPFire, the Kernel is 6.12.13 which was 6.12.13 rc up to Jan. where 6.13.2rc took its place in main and 6.13.7 LTS is the current release.
In main expiramental, my Linux main dev debug machine is at 6.14.6.
I know it takes time and I mentioned last year Main was going through growing pains that effected other distros and in this one its using a lot of modules that had fixes applied and that is not counting other things that changed in other software like OpenVPN.
try the command
unbound-anchor -a /var/lib/unbound/root.key
And
/etc/init.d/unbound restart
2 Likes
Dear Dave,
thank you for your comprehensive help. As the machine, containing firewall, is rather old (it is running for more than 15 years, everey day and every night) I think, it is a good time for upgrading the harware. I hope, that will solve my problems.
Well age has nothing to do with it, but I am beginning to suspect that there is a group of ethernet drivers that needs to be gone over and since its coming up here, Linux Main needs to assemble a debug group and those people need to get over the drama and work (long story).
What is the network card/interface you are having issues with?
Hallo Dave,
I’m using different network cards:
2 X TP-Link TG-3269 Ver 3.2 & 3.3
and a
2 Port Intel LAN Card D33682
I’m sorry, but I really don’t know which of them made the trouble.
Well I haven’t had any reports with that intel card, but the tplink cards use a realtek RTL8169SC chip that they never gave anyone a good 64 bit source, as a result these cards don’t work (or if they do they don’t work well) in anyone’s OS including windows 10. Windows 8 was the last os that worked but that was a 32 bit driver.