Bug #16419
closed
Relayd has a wrong host for database, it should use localhost on normal root servers
Added by Tobias Ell almost 5 years ago.
Updated over 4 years ago.
Category:
System techniques
Description
Hello,
yesterday I upgraded our test instance of rudder server to 6.0.0 .
I now have the problem that relayd stops working. When I try to restart it won't,
because the url for database contains the fully-qualified domain name, but the database
only listens on 127.0.0.1 .
When I change that url to 127.0.0.1, I can start relayd but after a while it will stop again.
The url will point to FQDN again. Some process changes main.conf but without a logfile I am unable to
debug the problem.
I have not found information about turning on logging for relayd - is it possible to have a logfile?
Maybe I made a mistake on upgrading - I only updated the rpm packets.
In the documentation I didn't find any specific actions to take on upgrade.
Thanks for your help
Tobias
Sorry - forgot to mention that I upgraded from 5.0.15
- Subject changed from relayd exits to Relayd has a wrong host for database, it should use localhost on normal root servers
- Category set to System techniques
- Target version set to 6.0.1
- Tracker changed from Question to Bug
- Priority set to 0
- Name check set to To do
- Fix check set to To do
Thanks for reporting this!
It looks like a bug in the system roles defined in the system techniques. It should indeed use localhost on a normal root server.
The host is changed by the agent at each run, which breaks relayd. Relayd logs are currently only stored in journald (acessible with `journalctl -u rudder-relayd`, we need to add a rsyslog config to log it along with our other log files).
- Target version changed from 6.0.1 to 6.0.2
- Target version changed from 6.0.2 to 6.0.3
I just installed 6.0.2 and it seems to work now - database host is localhost and stays that way, even after an agent run.
- Target version changed from 6.0.3 to 6.0.4
- Target version changed from 6.0.4 to 6.0.5
- Target version changed from 6.0.5 to 6.0.6
- Target version changed from 6.0.6 to 6.0.7
- Target version changed from 6.0.7 to 6.0.8
- Status changed from New to Resolved
We didn't reproduced that, and since Tobias said it now works for him, I'm closing that ticket. Feel free to reopen and open a new one if the problem comes back.
Also available in: Atom
PDF