nailgun agent with multipath stops working

@Andrey: Could you please provide more debug information?

The agent works in the next way - it finds the server which it needs to connect to, then sleeps for a random period of time, then executes ohai, then parses the data from its output, sends the info to the server and exits. In my case the agent hangs on the ohai step. Ohai in its turn opens all the plugins it has, one of them is "filesystem.rb", which executes a set of commands collecting the data about all filesystems at the moment. The process "blsid -s TYPE" hangs and the agent's process never finishes its job, so the node appears as "Offline" in the Fuel UI.
In order to resolve the current issue, I had to restart multipathd process so that it releases all non-existing devices, after that it becomes possible to kill those blkid processes as well.
Once I removed the plugin from ohai directory, the agent started to operate properly.

@Andrey: Thank you for the quick update.

With EMC + multipath the same shi^W uninterruptible sleep (I/O) on blkid -s TYPE (UUID/LABEL).

>> ohai/plugins/linux/filesystem.rb:
...
# Gather more filesystem types via libuuid, even devices that's aren't mounted
popen4("blkid -s TYPE") do |pid, stdin, stdout, stderr|
...
end

# Gather device UUIDs via libuuid
popen4("blkid -s UUID") do |pid, stdin, stdout, stderr|
...
end

# Gather device labels via libuuid
popen4("blkid -s LABEL") do |pid, stdin, stdout, stderr|
...
end

Commenting out the above code is wrapped up an issue.

Workaround: https://bugs.launchpad.net/fuel/+bug/1405265/comments/2
Can be moving to 8.0

We passed SCF in 8.0. Moving the bug to 9.0.

What resolved this?

Moved to 10.0, because review I didn't find + Andrey G. did provide additional information.
We should recheck it in new release.

looks like duplicate of https://bugs.launchpad.net/fuel/+bug/1396086

Marking as Fix Committed. QA team, please verify that the issue is not reproducible any more.

Still experiencing the same issue on MOS 9.1 + EMC + multipath.

Is there any possibility to backport it to previous versions of MOS? The customers are experiencing the same issue om MOS 7.0

Team this bug seems to be critical since there are about 30000 "blkid -s" processes that consume CPU and memory resources on a compute node.

Anatolii, please don't change the original milestone of the bug, this makes reporting inefficient and adds a lot of confusion.

Denis, one more customer has the same issue on MOS 7.0
He has more that 27000 "blkid -s TYPE" processes on his node.
Is it possible to create backport for MOS 7.0?