SaltGUI is reporting minions v 3005.1 as offline
szmolnar opened this issue · 8 comments
Describe the bug
SaltGUI is reporting minion with version 3005.1 as offline
Expected behaviour
Should report minion as online
Screenshots
This is not an issue with saltstack version 3005.1 in general.
I have a test-bench with a VM for each individual saltstack version (but only for Debian), and they all work fine.
Except of course for the saltstack versions that are themselves broken. For the 3xxx versions those are: 3005, 3001.5 and 3000.7.
Can you please switch to the Jobs list and select "Show all jobs".
You should be able to see the commands that SaltGUI is using internally.
for the panel "Minions" that should be test.version and grains.items. a few wheel. commands are also issued, but these are not registered in the jobs list.
do you see any errors in the output of grains.items?
Otherwise, are you able to inspect the developer tools from the browser? SaltGUI uses only salt-api. The REST calls for that should be visible in tab "Network". Regular salt-api calls all have the url /. Look at the "Request" part of each request to see the api-call name and look at the "Response" part to see the result.
This is not an issue with saltstack version 3005.1 in general. I have a test-bench with a VM for each individual saltstack version (but only for Debian), and they all work fine. Except of course for the saltstack versions that are themselves broken. For the 3xxx versions those are: 3005, 3001.5 and 3000.7.
Can you please switch to the Jobs list and select "Show all jobs". You should be able to see the commands that SaltGUI is using internally. for the panel "Minions" that should be
test.versionandgrains.items. a fewwheel.commands are also issued, but these are not registered in the jobs list. do you see any errors in the output ofgrains.items?Otherwise, are you able to inspect the developer tools from the browser? SaltGUI uses only salt-api. The REST calls for that should be visible in tab "Network". Regular salt-api calls all have the url
/. Look at the "Request" part of each request to see the api-call name and look at the "Response" part to see the result.
Thanks for your quick reply!
grains.items and test.version fails for PD999999 device but works ok if I sed it from my server.
'# salt 'PD999999' grains.items
PD999999:
----------
cpu_flags:
- half
- thumb
- fastmult
- vfp
- edsp
- java
- tls
cpu_model:
ARMv6-compatible processor rev 7 (v6l)
cpuarch:
armv6l
cwd:
/
disks:
dns:
----------
domain:
ip4_nameservers:
- 8.8.8.8
- 8.8.4.4
ip6_nameservers:
- 2001:4860:4860::8888
nameservers:
- 8.8.8.8
- 8.8.4.4
- 2001:4860:4860::8888
options:
search:
sortlist:
domain:
efi:
False
efi-secure-boot:
False
fqdn:
PD999999
fqdn_ip4:
fqdn_ip6:
fqdns:
gid:
0
gpus:
groupname:
root
host:
PD999999
hwaddr_interfaces:
----------
eth0:
b8:27:eb:19:7d:73
lo:
00:00:00:00:00:00
id:
PD999999
init:
systemd
ip4_gw:
192.168.5.1
ip4_interfaces:
----------
eth0:
- 192.168.5.162
lo:
- 127.0.0.1
ip6_gw:
False
ip6_interfaces:
----------
eth0:
- fe80::6a9e:e271:c252:af42
lo:
- ::1
ip_gw:
True
ip_interfaces:
----------
eth0:
- 192.168.5.162
- fe80::6a9e:e271:c252:af42
lo:
- 127.0.0.1
- ::1
ipv4:
- 127.0.0.1
- 192.168.5.162
ipv6:
- ::1
- fe80::6a9e:e271:c252:af42
kernel:
Linux
kernelparams:
|_
- coherent_pool
- 1M
|_
- bcm2708_fb.fbwidth
- 592
|_
- bcm2708_fb.fbheight
- 448
|_
- bcm2708_fb.fbswap
- 1
|_
- smsc95xx.macaddr
- B8:27:EB:19:7D:73
|_
- vc_mem.mem_base
- 0x1ec00000
|_
- vc_mem.mem_size
- 0x20000000
|_
- console
- ttyAMA0,115200
|_
- console
- tty1
|_
- root
- None
|_
- rootfstype
- ext4
|_
- elevator
- deadline
|_
- fsck.repair
- yes
|_
- rootwait
- None
|_
- quiet
- None
|_
- splash
- None
|_
- plymouth.ignore-serial-consoles
- None
kernelrelease:
4.19.97+
kernelversion:
#1294 Thu Jan 30 13:10:54 GMT 2020
locale_info:
----------
defaultencoding:
UTF-8
defaultlanguage:
en_GB
detectedencoding:
UTF-8
timezone:
GMT
localhost:
PD999999
lsb_distrib_codename:
buster
lsb_distrib_description:
Raspbian GNU/Linux 10 (buster)
lsb_distrib_id:
Raspbian
lsb_distrib_release:
10
machine_id:
8fca3bfa67ec46c1ba6182fac3b04168
master:
smartmeter.negzrt.hu
mem_total:
432
nodename:
PD999999
num_cpus:
1
num_gpus:
0
os:
Raspbian
os_family:
Debian
osarch:
armhf
oscodename:
buster
osfinger:
Raspbian-10
osfullname:
Raspbian
osmajorrelease:
10
osrelease:
10
osrelease_info:
- 10
path:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
pid:
1945
ps:
ps -efHww
pythonexecutable:
/usr/bin/python3
pythonpath:
- /usr/bin
- /usr/lib/python37.zip
- /usr/lib/python3.7
- /usr/lib/python3.7/lib-dynload
- /usr/local/lib/python3.7/dist-packages
- /usr/lib/python3/dist-packages
pythonversion:
- 3
- 7
- 3
- final
- 0
saltpath:
/usr/lib/python3/dist-packages/salt
saltversion:
3005.1
saltversioninfo:
- 3005
- 1
server_id:
146219906
shell:
/bin/sh
ssds:
- mmcblk0
state:
02d31c32-76f2-4d92-8df9-b63444886e0e
swap_total:
0
systemd:
----------
features:
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid
version:
241
systempath:
- /usr/local/sbin
- /usr/local/bin
- /usr/sbin
- /usr/bin
- /sbin
- /bin
transactional:
False
uid:
0
username:
root
virtual:
physical
zfs_feature_flags:
False
zfs_support:
False
zmqversion:
4.3.1
'
As you see, PD999999 did not actually answer the grains,items or the test.version calls issued by SaltGUI.
The "Manual Run" screen does not interpret any result. So any potential mistake from the main screen cannot be present on ManualRun.
It may be that the RaspberryPi is too slow to answer the multiple requests.
Is there anything visible in the minion log from PD999999 ?
As you see, PD999999 did not actually answer the
grains,itemsor thetest.versioncalls issued by SaltGUI. The "Manual Run" screen does not interpret any result. So any potential mistake from the main screen cannot be present on ManualRun. It may be that the RaspberryPi is too slow to answer the multiple requests. Is there anything visible in the minion log from PD999999 ?
Yep, that's right but also I need to mention that same commands are working just fine if I send those from the master command line (GUI runs on the same server).
I can't see any problems in the minion log.
can you please repeat those salt commands, but now using salt --async and started from a script, so that they run more-or-less in parallel?
and actually, the following functions are executed on the main screen (listed here in salt-command equivalent):
sudo salt --async "master" saltutil.wheel minions.connected
sudo salt --async "master" saltutil.wheel key.list_all
sudo salt --async "minion" grains.items
sudo salt --async "master" saltutil.wheel key.list_all
sudo salt --async "master" saltutil.runner manage.versions
sudo salt --async "master" saltutil.runner jobs.active
sudo salt --async "master" saltutil.runner jobs.list_jobs
sudo salt --async "minion" test.version
sudo salt --async "minion" saltutil.running
best when the script contains all these.
and then look for the results using the Job page of SaltGUI, because async commands have no output.