-
Couldn't load subscription status.
- Fork 2
Description
For several processes on my RHEL 7.3 server, goss seems to misrecord the statuses of processes...
As a test, I pipe every process in ps into a goss add process command...
for p in $(ps -ef | grep -v '\[' | cut -b49- | cut -d" " -f1 | cut -d: -f1 | rev | cut -d/ -f1 | rev |sort -u); do ../goss a process ${p} doneApart from the fluff (CMD from ps header, and ps, cut, rev, sort used in the command above), one would expect all these processes to be actual running processes. Yet, goss reports several of them as NOT running.
If I take just systemd processes as an example:
ps -ef | grep systemd root 1 0 0 May21 ? 00:00:51 /usr/lib/systemd/systemd --switched-root --system --deserialize 21 root 898 1 0 May21 ? 00:01:01 /usr/lib/systemd/systemd-journald root 932 1 0 May21 ? 00:00:00 /usr/lib/systemd/systemd-udevd dbus 2353 1 0 May21 ? 00:00:23 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root 2383 1 0 May21 ? 00:00:08 /usr/lib/systemd/systemd-logindWe see 4 processes all running since May 21. If we examine the goss.yaml file we see this:
grep -A1 systemd goss.yaml systemd: running: true systemd-journald: running: false systemd-logind: running: true systemd-udevd: running: true3 of the 4 are listed as running, but even though systemd-journald is running, it is reported as false...
Whatever is happening is consistent, in the sense that validation will pass confirming "systemd-journald" is not running when goss re-executes.
There are a few other processes (excluding ps, cut, rev, sort from the command that fed goss) from a vendor product on my system that similarly report as running false when they are actually running...
Any idea what is happening to cause this strange behavior?
[This is using v0.3.7 AMD64]
Imported from goss-org/goss#451