What happened?
When running salt-call --local state.highstate queue=True without any minion present, it used to be the case that concurrent salt-calls would queue among themselves.
However, since #68694 was implemented (3006.21), queue=True now silently assumes that a minion is running. If one is not, then any job that queues itself by writing to /var/cache/salt/minion/state_queue/ becomes a no-op as nothing will ever pick it up. Worse, the presence of this queue file will convince all subsequent queue=True jobs to immediately give up, write their own queue file, and exit. This effectively permanently disables salt as soon as two parallel jobs ever collide for the first time, assuming all jobs use queue=True.
Doing queue=<int> for some sensible upper bound seems to be a partial workaround as this restores the old in-process queuing behaviour, but this still hangs infinitely if any queue files already exist.
Ideally, queue=True should avoid delegating to a daemon that does not exist, and fall back to the old behaviour. Right now, this is a regression for minion-less setups.
Type of salt install
Official rpm
Major version
3006.x
What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)
rhel-8
salt --versions-report output
Salt Version:
Salt: 3006.21
Python Version:
Python: 3.10.19 (main, Feb 5 2026, 07:05:38) [GCC 11.2.0]
Dependency Versions:
cffi: 2.0.0
cherrypy: 18.10.0
cryptography: 42.0.5
dateutil: 2.8.1
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.6
libgit2: Not Installed
looseversion: 1.0.2
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.2
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 24.0
pycparser: 2.21
pycrypto: Not Installed
pycryptodome: 3.19.1
pygit2: Not Installed
python-gnupg: 0.4.8
PyYAML: 6.0.1
PyZMQ: 23.2.0
relenv: 0.22.3
smmap: Not Installed
timelib: 0.3.0
Tornado: 4.5.3
ZMQ: 4.3.4
System Versions:
dist: ahv 10.3.1.9
locale: utf-8
machine: x86_64
release: 6.6.106-10.3.1.9s1c2r5.el8.x86_64
system: Linux
version: Nutanix AHV 10.3.1.9
What happened?
When running
salt-call --local state.highstate queue=Truewithout any minion present, it used to be the case that concurrentsalt-calls would queue among themselves.However, since #68694 was implemented (3006.21),
queue=Truenow silently assumes that a minion is running. If one is not, then any job that queues itself by writing to/var/cache/salt/minion/state_queue/becomes a no-op as nothing will ever pick it up. Worse, the presence of this queue file will convince all subsequentqueue=Truejobs to immediately give up, write their own queue file, and exit. This effectively permanently disables salt as soon as two parallel jobs ever collide for the first time, assuming all jobs usequeue=True.Doing
queue=<int>for some sensible upper bound seems to be a partial workaround as this restores the old in-process queuing behaviour, but this still hangs infinitely if any queue files already exist.Ideally,
queue=Trueshould avoid delegating to a daemon that does not exist, and fall back to the old behaviour. Right now, this is a regression for minion-less setups.Type of salt install
Official rpm
Major version
3006.x
What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)
rhel-8
salt --versions-report output
Salt Version: Salt: 3006.21 Python Version: Python: 3.10.19 (main, Feb 5 2026, 07:05:38) [GCC 11.2.0] Dependency Versions: cffi: 2.0.0 cherrypy: 18.10.0 cryptography: 42.0.5 dateutil: 2.8.1 docker-py: Not Installed gitdb: Not Installed gitpython: Not Installed Jinja2: 3.1.6 libgit2: Not Installed looseversion: 1.0.2 M2Crypto: Not Installed Mako: Not Installed msgpack: 1.0.2 msgpack-pure: Not Installed mysql-python: Not Installed packaging: 24.0 pycparser: 2.21 pycrypto: Not Installed pycryptodome: 3.19.1 pygit2: Not Installed python-gnupg: 0.4.8 PyYAML: 6.0.1 PyZMQ: 23.2.0 relenv: 0.22.3 smmap: Not Installed timelib: 0.3.0 Tornado: 4.5.3 ZMQ: 4.3.4 System Versions: dist: ahv 10.3.1.9 locale: utf-8 machine: x86_64 release: 6.6.106-10.3.1.9s1c2r5.el8.x86_64 system: Linux version: Nutanix AHV 10.3.1.9