Description of problem:
The way counting of services is implemented for distros with systemd (such as RHEL >=7) makes it possible to count _links_ as individual services. This leads to a situation where a link and the actual *.service file that is target of such link are counted as two distinct services.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Have a RHV as infrastructure provider. Have a VM on that provider with RHEL >=7.
2. SSH into your RHEL VM. Make sure that there is at least one link in /etc/systemd/system that points to some .service file in /usr/lib/systemd/system. In my example, let's take a look at this one:
# ls -l /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service
lrwxrwxrwx. 1 root root 46 Sep 5 2016 /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
3. Go to CFME UI and perform SSA on your VM. You can see the attached evm.log for my case. Wait for SSA to finish.
4. Go to VM's detail page in CFME UI. Click Configuration -> Init processes.
5. Now try to search for the link path. In my case, it was /etc/systemd/system/dbus-org.freedesktop.NetworkManager.service. I can locate that path among "Init processes"
6. Then try to look for path that the link is pointing to. In my case it was /usr/lib/systemd/system/NetworkManager.service. I can locate that entry in "Init processes" as well.
Both link and its actual target are included among "Init processes" even though that is actually only one service.
I would expect only unique service entries to be included there. Links should not be accounted for.
If you take a look at this module (https://github.com/ManageIQ/manageiq-smartstate/blob/4a746f3552bf35a0514920d79f8b5a46fba2a50a/lib/metadata/linux/LinuxSystemd.rb) you can see that gathering of services during SSA of VM is done by counting numbers of files with .service externsion as far as I can understand. I am just wondering why don't we use command 'systemctl list-unit-files --type=service' there, which I believe is already doing that for us.
I found about this bug while inspecting VM with RHEL7.3, but I believe this is completely independent of specific RHEL version as long as that RHEL is using systemd.
New commit detected on ManageIQ/manageiq-smartstate/master:
Author: hsong-rh <firstname.lastname@example.org>
AuthorDate: Thu May 17 15:47:12 2018 -0400
Commit: hsong-rh <email@example.com>
CommitDate: Thu May 17 15:47:12 2018 -0400
Fix to remove duplicated records in services list after SSA
lib/metadata/linux/LinuxSystemd.rb | 10 +
1 file changed, 10 insertions(+)
(In reply to CFME Bot from comment #4)
> New commit detected on ManageIQ/manageiq-smartstate/master:
> commit 79087ebda6f000bb8e5c3da6173f74e419885343
> Author: hsong-rh <firstname.lastname@example.org>
> AuthorDate: Thu May 17 15:47:12 2018 -0400
> Commit: hsong-rh <email@example.com>
> CommitDate: Thu May 17 15:47:12 2018 -0400
> Fix to remove duplicated records in services list after SSA
> lib/metadata/linux/LinuxSystemd.rb | 10 +
> 1 file changed, 10 insertions(+)
I am not sure about the proposed solution. Let's think about a scenario in which user links their own service by using this:
Then even though such service is started after boot, it would be disregarded by SSA.
Our SSA works not only for running VMs, but also for those images/templates. This means:
1. We cannot run any system commands to query services;
2. We cannot parse the whole file system to filter out services, for performance reason;
So currently SSA only lists those services located in the default system directories.
Aren't links skipped only if we also see the target of the link?
"Link a unit file that is not in the unit file search paths into the unit file search path"
So, if the target isn't in the unit file search path, and the link is, we will count it.
(In reply to Rich Oliveri from comment #7)
> Aren't links skipped only if we also see the target of the link?
> "Link a unit file that is not in the unit file search paths into the unit
> file search path"
> So, if the target isn't in the unit file search path, and the link is, we
> will count it.
If that is the case, then it's of course good. But I am not sure about if target of the link is considered at all. I am however not skilled in Ruby. Is that the way it works, Hui?
Yes, Jan. All the links in the unit file search path will be counted.
I followed reproduction steps and verified that links like that are not counted any more. I also created symlink in /usr/lib/systemd/system on tested VM like this:
ln -sf sshd.service something.service
I ran SSA again and made sure that symlink something.service has not been accounted for.
Verified on version: 220.127.116.11
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.