[BUG] Salt-minion is not connecting to the Salt master at boot time
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 15.7k
- Forks
- 5.6k
- Avg merge
- 2d 44m
- Merged PRs (30d)
- 80
Description
see: https://bugzilla.redhat.com/show_bug.cgi?id=2015117
Description
Salt-minion is not connecting to the Salt master at boot time and
remains unresponsive until the daemon is restarted.
The systemd unit for salt-minion says "After=network.target" but not
"After=network-online.target". So the daemon is started in parallel
with the process which negotiates the network (which is managed by
NetworkManager and is configured to use DHCP) and comes up before the
network is ready.
"systemctl status salt-minion" says this:
Oct 18 12:53:05 tw01 systemd[1]: Starting The Salt Minion...
Oct 18 12:53:05 tw01 systemd[1]: Started The Salt Minion.
Oct 18 12:53:06 tw01 salt-minion[2875]: [ERROR ] DNS lookup or connection check of 'salt' failed.
Oct 18 12:53:06 tw01 salt-minion[2875]: [ERROR ] Master hostname: 'salt' not found or not responsive. Retrying in 30 seconds
...but the current time is 13:20 and this "retry in 30 seconds" never
happened.
If I now restart the service while the system is online, it initialises
successfully.
Version-Release number of selected component (if applicable):
salt-minion-3003.3-1.fc34.noarch
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting the salt-minion systemd unit and the boot ordering described in the issue; use systemctl status salt-minion to observe startup behavior. Reproduce the failure with a DHCP-managed network, then verify that the service waits for the network to be online and connects to the Salt master at boot without a manual restart.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, python
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100